NPR 7120.5D NASA Space Flight Program and Project Management Requirements

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

P.2 APPLICABILITY

a. This NPR applies to NASA Headquarters and NASA Centers, including Component Facilities and the Jet Propulsion Laboratory, and contractors/service providers to the extent specified in their contracts with NASA.

b. This NPR applies to all current and future 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, and ground systems that are in direct support of space flight operations). This NPR also applies to reimbursable space flight programs/projects performed for non-NASA sponsors. For existing programs and projects, the requirements of this document are applicable to the program/project’s extant phase as of the effective date of this NPR and to phases yet to be completed.

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

P.3 AUTHORITY

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

P.4 APPLICABLE DOCUMENTS

P.5 MEASUREMENT/VERIFICATION

Compliance with this document is verified by submission to cognizant NASA officials, at key decision points, of the gate products identified in this document.

P.6 CANCELLATION

NPR 7120.5C, NASA Program and Project Management Processes and Requirements, dated March, 2005, is cancelled for space flight programs and projects (as defined in P.2), but remains in effect for all other programs and projects.

The NASA Interim Directive (NM 7120-40) to NPR 7120.5C, NASA Program and Project Management Processes and Requirements, dated March 6, 2006, is cancelled for space flight programs and projects (as defined in P.2), but remains in effect for all other programs and projects.

CHAPTER 1. Introduction

1.1 Background

1.1.1 This document establishes the process by which NASA will formulate and implement space flight programs and projects consistent with the governance model contained in NPD1000.0, NASA Strategic Management and Governance Handbook. 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 is intended to establish a standard of uniformity in the management of such programs and projects.

1.1.2 Central to building this cohesive management process is the introduction of NASA space flight program and project life cycles, and the identification of the Key Decision Points (KDPs) within these life cycles. This document also outlines program/project decision processes and summarizes the roles and responsibilities of key personnel responsible for NASA program and project management: the Agency Program Management Council (PMC), the Mission Directorates, the Centers,² program managers, and project managers. It further identifies and summarizes the technical authority process as it applies to program and project management,³ and codifies the top-level management requirements for safe and successful program/project formulation and implementation.

1.1.3 This document distinguishes between programmatic requirements, on the one hand, and management process requirements, on the other. Both categories of requirements must ultimately be satisfied in program and project formulation and implementation. Programmatic requirements focus on the space flight products to be developed and delivered, and specifically relate to the goals and objectives of a particular NASA program or project. These requirements flow down from the Agency's strategic planning process. Table 1-1 shows this flow-down from Agency needs, goals, and objectives, described in the NASA Strategic Plan, to programs and projects.

1.1.4 Management process requirements 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, Mission Directorates, and Mission Support Offices, and by Center organizations. Management process requirements may respond to Federal statute, regulation, treaty, or executive order. They are normally documented in the following:

a. NASA Policy Directive (NPD) - NPDs are policy statements that describe what is required by NASA management to achieve NASA's vision, mission, and external mandates and who is responsible for carrying out those requirements.

b. NASA Procedural Requirements (NPR) - NPRs provide Agency-mandatory instructions and requirements to implement NASA policy as delineated in an associated NPD.

c. Center Policy Directive (CPD) - CPDs define Center-specific policy requirements and responsibilities that apply only to the issuing Center and operations performed by NASA personnel at that Center (and must comply with requirements delineated in associated NPDs and NPRs).

d. Center Procedural Requirements (CPR) - CPRs establish Center-specific procedural requirements and responsibilities to implement the policies and procedural requirements defined in related NPDs, NPRs, or CPDs. CPRs apply only to the issuing Center and operations performed by NASA personnel at that Center.

e. Mission Directorate Requirements - Programmatic requirements contained in Mission Directorate documentation that apply to program and project office personnel located at NASA Centers.

1.1.5 This revision of NPR 7120.5 is part of a realignment of governing documents within NASA designed to increase accountability and general clarity in the flow-down of management process requirements. Figure 1-1 shows the document hierarchy from NPD 1000.0 through program and project plans. The figure identifies the four types of management process requirements that flow down to these plans: engineering, program/project management, safety and mission assurance (SMA), and Mission Support Office (MSO) functional requirements. These terms are defined in Appendix A.

1.2 Overview of Management Process

1.2.1 Although program and project management based on life cycles, KDPs, and evolving products during each life-cycle phase are emphasized in this document, these are embedded in NASA's four-part process for managing programs and projects consisting of:

a. Formulation - the identification of how the program or project supports the Agency's strategic needs, goals, and objectives; 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.

b. Approval (for Implementation) - the 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.

c. 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 strategic needs, goals, and objectives.

d. Evaluation - the continual, independent (i.e., unbiased and outside the advocacy chain of the program/project) evaluation of the performance of a program or project and incorporation of the evaluation findings to ensure adequacy of planning and execution according to approved plans.

1.2.2 The management process at NASA reflects NASA's core values, which are Safety, Teamwork, Integrity, and Mission Success. NASA Mission Directorates, Centers, and program/project managers, in conceiving and executing their projects, must adhere to these core values, which are illustrated here for emphasis:

a. NASA's constant attention to safety is the cornerstone upon which we build mission success. We are committed, individually and as a team, to protecting the safety and health of the public, our team members, and those assets that the Nation entrusts to us.

b. NASA's most powerful tool for achieving mission success is a multi-disciplinary team of competent people who employ best-practice processes. The Agency will build high-performing teams that are committed to continuous learning, trust, and openness to innovation and new ideas.

c. NASA is committed to an environment of trust, built upon honesty, ethical behavior, respect, and candor. Building trust through ethical conduct as individuals and as an organization is a necessary component of mission success.

d. NASA's reason for being is to conduct successful space missions on behalf of this Nation. We undertake missions to explore, discover, and learn. And, we believe that mission success is the natural consequence of an uncompromising commitment to safety, teamwork, and integrity.

1.3 Document Structure

1.3.1 The remainder of this document is organized as follows: Chapter 2 defines the life cycles for NASA space flight programs and projects; Chapter 3 defines the roles and responsibilities of program/project team members and their interrelationships; and Chapter 4 provides the management requirements on programs and projects by life-cycle phase and specifies the gate products required to transition between phases. Chapters 2 and 3 are written in the indicative mood (to affirm statements of fact) because they describe how NASA does program/project work. Chapter 4 is written using verifiable "shall" statements that define the requirements that the program/project must meet.

1.3.2 Appendices C through G contain templates for key management documents and additional information regarding specific management products, e.g., the WBS. See NASA's POLARIS website at https://polaris.nasa.gov for an electronic version of the NPR 7120.5D templates. POLARIS also provides a searchable and sortable database of NPR 7120.5 requirements, and interactive program and project life-cycle charts with links to guidance on reviews.⁴

1.3.3 Reference documents relevant to program and project management activities are cited in Appendix H. A limited index to subjects in this document appears as Appendix I.

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

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

2.1 Defining Programs and Projects

2.1.1 Space flight programs and projects are often the most visible and complex of NASA's strategic investments. These 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. 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 defines a strategic direction that the Agency has identified as needed to implement Agency goals and objectives.

b. Project - 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 needs.

2.1.2 NASA's strategic acquisition planning and authorization is a continuous process requiring the earliest possible informed decisions to ensure programs and projects have the proper budget authorization and Agency commitment. To facilitate this decision process, three discrete acquisition events are required: the Acquisition Strategy Planning (ASP) meeting that provides the forum for senior Agency management to review major acquisitions before authorizing budget expenditures; the Acquisition Strategy Meeting (ASM) that examines the Agency's acquisition approach (e.g., internal make-or-buy, Center assignments, etc.); and the Procurement Strategy Meeting ⁵ (PSM) that approves the procurement approach for each procurement. The ASP meeting and ASM occur during the program and project formulation and approval processes. The ASP meeting is used to approve programs and projects for formulation. The ASM is program- or project-specific and is more detailed than the ASP meeting. The PSM is project- or contract-specific and is developed by the Project Manager, supported by the Contracting Officer, and approved as prescribed in the NASA FAR Supplement (NFS). These events are part of the normal program and project formulation and implementation activities described in the following paragraphs and chapters.

2.1.3 Within NASA, 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 changes, a Mission Directorate must occasionally re-baseline 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 at the Agency's strategic acquisition planning meetings. 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 that may be employed:

a. Single-project programs (e.g., James Webb Space Telescope Program) tend to have long development and/or operational lifetimes, represent a large investment of Agency resources in one program/project, and have contributions to that program/project from multiple organizations/agencies.

b. Uncoupled programs (e.g., Discovery Program) are implemented under a broad scientific theme and/or a common program implementation concept, such as providing frequent flight opportunities for cost-capped projects selected through Announcements of Opportunity or NASA Research Announcements. Each such project is independent of the other projects within the program.

c. Loosely coupled programs (e.g., Mars Exploration Program or Lunar Precursor and Robotic Program) address specific scientific or exploration 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.

d. Tightly coupled programs (e.g., Constellation Program) have multiple projects that execute portions of a mission or missions. 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.

2.1.4 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 will be used in the remainder of this document. Project categorization defines Agency expectations of project managers by determining both the oversight council and the specific approval requirements. Projects are either Category 1, 2, or 3 and are assigned to a category based initially on (1) the project life-cycle cost (LCC) estimate, the use of nuclear power sources, and whether or not the system being developed is for human space flight; and (2) 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 final project categorization. The Office of the Chief Engineer (OCE) is responsible for the official listing of NASA programs and projects and their categorization⁶. For purposes of project categorization, the project life-cycle cost estimate includes Phases A through F, all WBS Level 2 elements (see Appendix G), and is measured in real-year (nominal) dollars.

2.1.5 When projects are initiated, they are assigned to a NASA Center by the MDAA in two general manners as part of the strategic acquisition 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 is with the concurrence of the NASA AA. For Category 2 and 3 projects within tightly coupled programs, the assignment may be recommended by the Program Manager with the concurrence of the MDAA. Once assigned, projects may be performed wholly in-house, by government-industry-academia teams, or nearly completely under contract to industry.

2.1.6 Figure 2-2 is a summary of the NASA life cycles for space flight programs and projects and provides an overview of their interrelated life cycle management processes with pointers for key events to sections in this document where more information is provided.

2.2 Program Life Cycle

2.2.1 As a strategic management structure, the program construct is extremely important within NASA. Programs provide the critically important linkage between the Agency's ambitious needs, goals, and objectives and the projects that are the specific means for achieving them. Although programs vary significantly in scope, complexity, cost, and criticality, within NASA they have a generic life-cycle management process that is divided into two distinct phases:

a. Formulation -Pre-Program Acquisition, in which a technical approach is derived from an Analysis of Alternatives (AoA); program requirements are developed and allocated to initial projects; project pre-formulation is initiated; organizational structures are developed and work assignments initiated; program acquisition strategies are defined and approved; interfaces to other programs are developed; required annual funding levels are established, initial cost estimates are derived and a program budget is approved; a plan for implementation is designed and management systems put in place; and formal program documentation is approved, all consistent with the NASA Strategic Plan and other higher-level requirements.

b. Implementation -Program Acquisition, Operations and Sustainment, in which constituent projects are initiated through direct assignment or competitive process (e.g., RFP, AO) and their formulation, approval, implementation, integration, operation, and ultimate decommissioning are constantly monitored; the program is adjusted as resources and requirements change. For tightly coupled programs, the implementation phase will coincide with the project life cycle to ensure that the program and all its projects are properly integrated, including proper interface definition and resource allocation across all internal projects and with external programs and organizations.

2.2.2 To formalize the management process, the program life cycle is established in Figure 2-3. This figure is used to illustrate:

b. Program life-cycle gates and major events, including Key Decision Points (KDPs) (see Section 2.4); and

2.2.2.1 The formulation phase for all program types is the same, involving one or more program reviews, followed by KDP I, where a decision is made in regards to program approval to begin implementation. As shown in Figure 2-3, the program life cycle has two different implementation paths, depending on program type. Each implementation path has different types of major reviews. For uncoupled and loosely coupled programs, the implementation phase only requires Program Status Reviews (PSRs)/Program Implementation Reviews⁸ (PIRs) to assess the program's performance and authorize its continuation at biennial KDPs.

2.2.2.2 Single-project and tightly coupled programs are more complex. For single-project programs, the implementation phase program reviews shown in Figure 2-3 are synonymous (not duplicative) with the project reviews in the project life cycle (see Figure 2-4 in Section 2.3) through Phase D. Once in operations, these programs have biennial KDPs preceded by attendant PSRs/PIRs. Tightly coupled programs during implementation have program reviews tied to the project reviews to ensure the proper integration of projects into the larger system. Once in operations, tightly coupled programs also have biennial PSRs/PIRs/KDPs to assess the program's performance and authorize its continuation.

2.2.3 Program formulation and implementation require the preparation and approval of three key documents - a program Formulation Authorization Document (FAD), a Program Commitment Agreement (PCA), and a Program Plan — each of which is now described.

2.2.3.1 To initiate planning for individual programs, a Mission Directorate prepares a program FAD following an ASP meeting. The program FAD authorizes a Program Manager to initiate the planning of a new program, and to perform the Analysis of Alternatives (AoA) required to formulate a sound Program Plan that contains project elements, requirements, schedules, risk assessments, and budgets. The FAD template is found in Appendix C. Because the creation of a new program represents a major commitment of the Agency and may require coordination with OMB and/or the Congress, the FAD requires the approval of the MDAA. The program FAD contains a statement of purpose for the proposed program and defines its relationship to the Agency's strategic goals and objectives; establishes the scope of work to be accomplished; provides initial constraints (including resources and schedule) and proposed program participants within and external to NASA (including international partnerships); and defines the approach and resources required to conduct program formulation.

2.2.3.2 The Program Commitment Agreement (PCA) is the agreement between the MDAA and the NASA AA (Decision Authority) that authorizes transition from formulation to implementation (KDP I). The PCA is prepared by the Mission Directorate with support from the Program Manager, as requested. The PCA documents Agency requirements, program objectives, management and technical approach and associated architecture, technical performance, schedule, cost, safety and risk factors, internal and external agreements, independent reviews, and all attendant top-level program requirements. A PCA can be considered an executive summary of the Program Plan and is updated and approved during the program life cycle, as appropriate. At a minimum, a significant change in program content, including the addition or deletion of a constituent project, warrants a change in the PCA. Changes to the PCA must remain consistent with the NASA Strategic Plan, higher-level architectures, and budget authority. The content of the initial PCA baselined at KDP I reflects the maturity of the program at that point in time and includes acknowledgment of those areas (such as schedule and cost) that cannot be defined without further development. The PCA is updated for subsequent KDPs and re-baselined as the program matures. The PCA template is found in Appendix D.

2.2.3.3 The Program Plan is an agreement between the MDAA (who has approval authority for the plan), the Center Director(s), and the Program Manager that documents at a high level the program's objectives and requirements, scope, implementation approach, interfaces with other programs, the environment within which the program operates, budget by fiscal year, and the commitments of the program. The Program Plan is prepared by the Program Manager with the support of program personnel. Implementation of a program, project, or task at a NASA Center is performed in accordance with the Program Plan and consistent with that Center's best practices, as negotiated and documented in the Program Plan. The agreements between the Program Manager and Center Directors of participating NASA Centers are documented in the Program Plan along with the Program Manager's approach to ensuring that interfaces do not increase risk to mission success. Program Plan concurrence by the participating NASA Center Directors demonstrates their commitment to support the program in terms of Center resources needed by the program.

2.2.3.3.1 The Program Plan is used by the governing PMC in the review process to determine if the program is fulfilling its agreements. The draft Program Plan is reviewed at KDP 0 (when required) and approved at KDP I. It is updated and approved during the program life cycle, as appropriate, similar to PCA updates. The content of the initial Program Plan baselined at KDP I reflects the maturity of the program at that point in time and acknowledges those areas (such as schedule and cost) that cannot be fully defined without further development. The Program Plan is updated for subsequent KDPs and re-baselined, if necessary, as the program matures.

2.2.3.3.2 The Program Plan details how the program will be managed, and contains the list of specific projects (updated as needed) that are officially approved as part of the program and, therefore, subject to the requirements on projects in this document. The Program Plan also documents the high-level program requirements, including performance, safety and programmatic requirements, correlated to Agency and Mission Directorate strategic objectives. These requirements are documented in the Program Plan, in a subsequent appendix, or in a separate, configuration-controlled program requirements document. The Program Plan template is found in Appendix E.

2.3 Project Life Cycle

2.3.1 For NASA space flight projects, the NASA life-cycle phases of formulation and implementation are divided into incremental pieces that allow managers to assess management and technical progress. The NASA Project Life Cycle is shown in Figure 2-4. The phases are separated by major reviews and KDPs. In practice, however, the activities described for each phase below are not always exclusively carried out in that phase; their timing will depend on the particular schedule requirements of the project. For example, some projects procure long-lead flight hardware in Phase B to enable them to achieve their launch dates.

2.3.1.1 Project formulation consists of two sequential phases, traditionally denoted as Phases A (Concept & Technology Development) and B (Preliminary Design & Technology Completion). The primary activities in these phases are to develop and define the project requirements and cost/schedule basis and to design a plan for implementation (including an acquisition strategy, contractor selection, and long-lead procurement). While not formally a part of formulation, some formulation-type activities will naturally occur as part of earlier advanced studies. These fall into a part of the project life cycle known as Pre-Phase A (Concept Studies).

2.3.1.2 Project implementation consists of Phases C, D, E, and F. Approval marks the transition from Phase B of formulation to Phase C of implementation. During Phases C (Final Design and Fabrication) and D (System Assembly, Integration and Test, and Launch), the primary activities are developmental in nature, including acquisition contract execution. Phase C includes the fabrication and testing of components, assemblies, and subsystems. All activities are executed as per the Project Plan developed during formulation. The transition from Phase C to Phase D is uniquely a "soft gate," in which the project may initiate Phase D work immediately upon completion of the Phase C work products, absent a notice of discontinuance by the Program Manager (rather than waiting for affirmative direction from the Program Manager to begin Phase D). The start of Phase E (Operations and Sustainment) marks the transition from system development and acquisition activities to primarily systems operations and sustainment activities. In Phase F (Closeout), project systems are taken out of service and safely disposed, although scientific and other analyses might still continue under project funding. Independent evaluation activities occur throughout all phases.

2.3.2 To initiate a new project, a Mission Directorate, working through a program office, usually provides a small amount of discretionary resources for concept studies (i.e., Pre-Phase A). These pre-formulation activities involve design reference mission analysis, feasibility studies, technology needs analyses, and analyses of alternatives that should be performed before a specific project concept emerges. These trade studies are not considered part of formal project planning since there is no certainty that a specific project proposal will emerge.

2.3.2.1 An MDAA has the authority to initiate a project and begin formulation activities. To effect a project's official entry into formulation, the Program Manager prepares a draft project FAD or equivalent (such as a Program Plan section, MDAA letter selecting a specific AO proposal, or a Program Directive that is used in the Space Station and Shuttle Programs). Following an ASP meeting, the updated project FAD is forwarded to the MDAA for final signature. Once the MDAA signs the project FAD, a project formally enters formulation.

2.3.2.2 Some Mission Directorates have chosen to establish several new space flight programs that use a one or two-step Announcement of Opportunity (AO) process to initiate projects. In a one-step AO process, projects are competed and selected for implementation in a single step. In two-step competitions, several projects may be selected in Step 1 and given time to mature their concepts in a funded Phase A before the Step 2 down-selection to one or more projects for further formulation. Program resources are invested (following Step 1 selections) to bring these projects to a state in which their science content, cost, schedule, technical performance, project implementation strategies, safety and mission assurance strategies, and management approach can be better judged.⁹ These projects are often referred to as competed or "AO-driven."

2.3.3 The Project Manager supports, as requested, the Mission Directorate and Program Manager in the development of program-level documentation and flows information down into project-level documentation. If requested by the Program Manager, the Project Manager assists in preparing a revised PCA and/or Program Plan. The Project Manager also supports, as requested, generation of the program requirements on the project and their formal documentation in the Program Plan (or as an appendix to the Program Plan). After the program requirements on the project are established, the Project Manager and the project team develop technical approaches and management plans to implement the requirements; these products are formally documented in the Project Plan. The Project Manager is then responsible for the evolution of the project concept and ultimate project success.

2.3.4 NASA places significant emphasis on project formulation because adequate preparation of project concepts and plans is vital to success. During formulation, the project establishes performance metrics, explores the full range of implementation options, defines an affordable project concept to meet requirements specified in the Program Plan, develops needed technologies, and develops and documents the Project Plan. Formulation is an iterative set of activities rather than discrete linear steps. System engineering plays a major role during formulation, exercising an iterative set of activities as described in NPR 7123.1, NASA Systems Engineering Processes and Requirements. Activities include developing the system architecture and system design; flowing down requirements to the system/subsystem level; establishing the internal management control functions that will be used throughout the life of the project; assessing the technology requirements and developing the plans for achieving them; identifying options for partnering and commercialization; performing life-cycle cost (LCC) and mission effectiveness analyses for concepts deemed to have a high degree of technical and operational feasibility; and identifying margins and reserves consistent with project risk. Formulation continues with interactive execution of its activities, normally concurrently, until formulation output products, like the Project Plan, have matured and are acceptable to the Program Manager, Center Director, and MDAA.

2.3.4.1 The Project Plan is an agreement among the Program Manager, participating Center Director(s), the Project Manager, and for AO-driven missions, the Principal Investigator (PI). (The MDAA may be added to the signature list for the plan at his/her discretion.) The Project Plan is prepared by the Project Manager with the support of the project team. It defines, at a high level, the project's objectives, technical and management approach, the environment within which the project operates, and the commitments of the project to the program. The Project Plan is required by the governing PMC and is used in the review process to determine if the project is fulfilling its agreements. The Project Plan must be consistent with the Program Plan. The Project Plan is updated and approved during the project life cycle if warranted by changes in the stated commitments or program requirements on the project.

2.3.4.2 The Project Plan is the key document that captures formulation results. Larger and more complex projects may find it necessary or desirable to write separate control plans to convey project approaches and strategies. In these cases, the Project Plan summarizes the key elements of such separate plans. In smaller projects, separate and detailed control plans may not be needed to document project approaches, and the Project Plan itself serves as the single source for such information. The Project Plan template is found in Appendix F.

2.4 Program and Project Oversight and Approval

2.4.1 This section describes NASA's oversight approach for programs and projects, and defines Key Decision Points (KDPs), when approval is given or denied, and identifies the Decision Authority (DA), the responsible official who provides that approval or disapproval.

2.4.2 The DA is the Agency's responsible individual who authorizes the transition at a KDP to the next life-cycle phase for a program/project. For programs and Category 1 projects, the DA is the NASA Associate Administrator (AA). For Category 1 projects, this authority may be delegated to the MDAA. For Category 2 and 3 projects, the DA is the MDAA. This authority may also be delegated to a lower level. The delegation of authority for projects is documented in the PCA.

2.4.3 To ensure the appropriate level of management oversight, NASA has established two levels of Program Management Councils (PMCs)- the Agency PMC and Mission Directorate PMCs. The PMCs have the responsibility of periodically evaluating the cost, schedule, risk, technical performance, and content of a program or project under its purview. The evaluation focuses on whether the program or project is meeting its commitments to the Agency. Each program and project has a governing PMC, which acts as the highest PMC for that program or project. For all programs, the governing PMC is the Agency PMC; for projects, the governing PMC is determined by the established project category. Table 2-2 shows the relationship between programs and projects (by category) and the PMCs.

2.4.3.1 The Agency PMC is the governing PMC for all programs and Category 1 projects. In that capacity, it evaluates them immediately prior to KDPs and then recommends approval or disapproval to the Decision Authority regarding entrance to the next life-cycle phase. The Agency PMC also performs program oversight during implementation by means of Quarterly Status Reports (QSRs) provided by the cognizant MDAA, and biennial Program Implementation Reviews (PIRs).

2.4.3.2 A Mission Directorate PMC (MDPMC) 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 Agency PMC. For Category 2 and 3 projects, the MDPMC serves as the governing PMC and recommends approval or disapproval to the DA regarding entry to the next phase. For Category 3 projects, the DA may designate a division within the Mission Directorate or Program Office as the governing authority, and may even delegate decision authority to the chairperson of the designated governing board. Such designations and delegations are described in the relevant Program Plan.

2.4.4 Oversight of programs and projects is also performed by a Center Management Council (CMC), which evaluates all program and project work (regardless of category) executed at that Center. The CMC evaluation focuses on whether Center engineering, SMA, and management best practices (i.e., resources, procurement, institutional) are being followed by the program/project under review, and whether Center resources can support program/project requirements. The CMC also assesses program and project risk and evaluates the performance of activities to identify trends and provide technical guidance to the Agency and affected programs and projects. The CMC provides its findings and recommendations to Program/Project Managers and to the appropriate PMCs regarding the technical and management viability of the program/project prior to KDPs.¹⁰ For tightly coupled programs, the MDAA, Center Director(s), and NASA Chief Engineer establish the program approach for the CMC-equivalent process and documents the approach in the Program Plan.

2.4.5 A KDP is an event where the Decision Authority determines the readiness of a program/project to progress to the next phase of the life cycle. As such, KDPs serve as gates through which programs and projects must pass. KDPs associated with programs are enumerated with numerals, starting with zero; KDPs associated with projects are labeled with capital letters, the letter corresponding to the project phase that will be entered after successfully passing through the gate. Within each phase, the KDP is preceded by one or more reviews, including the governing PMC review. These reviews enable a disciplined approach to assessing programs and projects. Allowances are made within a phase for the differences between human and robotic space flight programs and projects, but phases always end with the KDP. The potential outcomes at a KDP include:

c. Disapproval for continuation to the next KDP. In such cases, follow-up actions may include a request for more information and/or a delta independent review; a request for a Termination Review for the program or the project (Phases B, C, D, and E only); direction to continue in the current phase; or re-direction of the program/project.

2.4.6 To support the decision process, appropriate supporting materials are submitted to the Decision Authority. These materials include:

g. Program/project documents (FAD, Program Plan, PCA, Project Plan, or updates) that are ready for signature and agreements (MOUs, MOAs, waivers, etc.).

2.4.7 The Decision Authority makes his/her decision by considering a number of factors, including continued relevance to Agency strategic needs, goals, and objectives; continued cost affordability with respect to the Agency's resources; the viability and the readiness to proceed to the next phase; and remaining program or project risk (cost, schedule, technical, management, programmatic, and safety).

2.4.8 To complete formal actions at a KDP, the Decision Authority makes and documents the decision and its basis (including materials presented, major issues, options, and open action items) and archives the documents. Following the decision, the Decision Authority signs the required agreement(s) if no changes are required; if changes are required, the agreement(s) are revised, all necessary signatures obtained, and the agreement(s) resubmitted to the Decision Authority for final signature. Appeals must go to the next higher Decision Authority.

2.5 Program and Project Reviews

2.5.1 The program and project reviews identified in the life cycles are essential elements of conducting, managing, evaluating, and approving space flight programs/projects. In preparation for these reviews, programs and projects conduct internal reviews to initially establish and then manage the program/project baseline. These internal reviews are the decisional meetings wherein the program/projects solidify their plans, technical approaches, and programmatic commitments. This is accomplished as part of the normal systems engineering work processes of the program/project as defined in NPR 7123.1, NASA Systems Engineering Processes and Requirements. Major technical and programmatic requirements are assessed along with the system design and other implementation plans. Major technical and programmatic performance metrics are reported and assessed against predictions.

2.5.2 At the completion of the internal technical and programmatic reviews described in paragraph 2.5.1, an independent life-cycle review is conducted by a Standing Review Board (SRB).¹¹ The independent life-cycle review is conducted under documented Agency and Center review processes. Programs and projects are required to document in their Program and Project Plans their approach to conducting program/project internal reviews and how they will support the independent life-cycle reviews. Consistent with these processes and plans, the Terms of Reference (ToR) for each independent life-cycle review are jointly developed and approved/concurred by the respective individuals in Table 2-3.

2.5.2.1 The independent life-cycle review is convened by the same individuals (see Table 2-3) who develop the ToR to objectively assess the program/project's progress against the Program/Project Plan; its readiness to proceed to the next phase; compliance with NPR 7120.5 requirements; and for projects, the adequacy and credibility of the Integrated Baseline (at PDR and later). For the program and project reviews leading to program and project approval- P/SRR (PPAR) and P/SDR (PAR) for programs, and SRR/SDR/MDR (PNAR) and PDR (NAR) for Projects - a more integrated technical and programmatic review and evaluation is conducted, using the following criteria:¹²

a. Alignment with and contributing to Agency needs, goals, and objectives, and the adequacy of requirements flow-down from those.

b. Adequacy of technical approach, as defined by NPR 7123.1 entrance and success criteria.

d. Adequacy of estimated costs (total and by fiscal year), including Independent Cost Analyses (ICAs) and Independent Cost Estimates (ICEs), against approved budget resources.

2.5.2.2 The SRB's role¹³ is advisory to the program/project and the convening authorities and does not have authority over any program/project content. Its review provides expert assessment of the technical and programmatic approach, risk posture, and progress against the program/project baseline. When appropriate, it may offer recommendations to improve performance and/or reduce risk. Its outputs are briefed to the program/project under review prior to being reported to the next higher level of management. Required ICAs/ICEs will be reconciled internally within the SRB and with the program/project prior to the PMC review.

2.5.2.3 The SRB has a single chairperson and a NASA¹⁴ Review Manager (RM). The chairperson and the RM are approved/concurred by the same individuals who convened the independent life-cycle review (see Table 2-3). The RM for programs, Category 1 projects, and Category 2 projects that are $250M and above is assigned by the Associate Administrator for PA&E; the RM for Category 2 projects below $250M and Category 3 projects is assigned by the Technical Authority. The chairperson, with support from the RM, organizes the review board, and submits the names of proposed board members to the same individuals who convened the independent life-cycle review for approval/ concurrence.

2.5.2.4 The SRB remains intact, with the goal of having the same core membership for the duration of the program or project, although it may be augmented over time with specialized reviewers as needed. Board members must be independent of the program and project, and some members must be independent of the program's or project's participating Centers. Board members are chosen based on their management, technical, safety and mission assurance expertise, their objectivity, and their ability to make a broad assessment of the implementation of the program/project that employs numerous engineering and other disciplines. For programs, board members responsible for the Independent Cost Analysis (ICA) are provided by the Independent Program Assessment Office (IPAO). For Category 1 and 2 projects, board members responsible for the Independent Cost Estimate (ICE) are also provided by the IPAO. For Category 3 projects, board members responsible for the ICE may be provided by the IPAO, the Center Systems Management Office (SMO), or Center systems management function, as appropriate.

2.5.2.5 The RM actively supports each program/project independent life-cycle review by assisting the SRB chairperson, DA, MDAA (if not the DA), and TA in preparing the ToR; preparing team nomination letters; interfacing with the Program/Project Manager; managing review team administrative functions; ensuring that documented Agency and Center review policies and practices are followed; ensuring that Review Item Discrepancies (RIDs) and Requests for Action (RFAs) are tracked and closed; documenting and distributing SRB findings and recommendations; and preparing management briefings and reports.

2.5.2.6 Following each review, the SRB issues a board report within 30 days or as specified in the ToR for the review, and each such report is submitted to the relevant individuals (e.g., Decision Authority, MDAA, Program Manager, Project Manager, Technical Authority, Associate Administrator for PA&E, and participating Center Director(s)), along with recommended actions. Dissenting opinions are documented in the board report. The program/project assesses and dispositions the findings and recommendations of the SRB. Once program/project internal reviews and the SRB independent life-cycle review are complete, the life-cycle review milestone is considered complete.

2.5.2.7 For independent life-cycle reviews that do not directly precede a KDP (e.g., CDR), the CMC findings and recommendations, Program/Project Manager recommendations, and the SRB report are presented to the Mission Directorate PMC. At the discretion of the NASA AA, these review results for programs and Category 1 projects may be further reported to the Agency PMC.

2.5.2.8 A summary of the review process discussed above is shown in Figure 2-5. See Tables 2-4, 2-5, and 2-6 for a brief description of acquisition, program, and project reviews, respectively, with the caveat that not all reviews are applicable to every program and project.

2.5.2.9 The SRB is used for all independent life-cycle reviews shown on the program and project life cycles with the following exceptions:

c. The FRR and PFAR for tightly coupled programs at the discretion of the MDAA. (Rather than utilizing a complete independent review board for these flight and mission operations reviews, the program SRB chair and project SRB chairs that are part of the mission are included as advisory members to the flight and mission operations review boards. The SRB input is provided during the board meeting.)

d. For human space flight, the PLAR and CERR, which are conducted by the Mission Management Team (MMT).

2.5.3 The Office of the Administrator, MDAA, or the Technical Authority may also convene special reviews as they determine the need. Circumstances that may warrant special reviews include variances with respect to technical, cost, or schedule requirements, inability to develop an enabling technology, or some unanticipated change to the program or project baseline. 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 MDAA or the Technical Authority provides the chair of the review with the ToR for the special review. 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.5.4 NASA HQ SMA also has a Programmatic Audit and Review (PA&R) process described in NPR 8705.6, Safety and Mission Assurance Audits, Reviews, and Assessments. That process provides independent compliance verification for the applicable NASA SMA process and technical requirements within the program/project safety and mission assurance plan, the program baseline requirements set, and appropriate contract documentation. Program/Project Managers directly support the PA&R process (either Headquarters-led or Center-led) by providing logistics and resource support required for the successful execution of and response to PA&R process activities. They also coordinate with Center SMA and Center procurement officials to ensure that contracts provide for adequate contractor support for all PA&R activities, and they direct and authorize program/project contractors to support PA&R process activities.

2.5.5 If the Decision Authority is considering the termination of a program or a project in Phases B, C, D, or E, then a special termination KDP may be initiated. Circumstances such as the anticipated inability of the program or project to meet its commitments, an unanticipated change in Agency strategic planning, or an unanticipated change in the NASA budget may be instrumental in triggering a termination KDP. For Category 2 and 3 projects, the Decision Authority notifies the NASA Associate Administrator at least 45 days (Category 2 projects) or 21 days (Category 3 projects) in advance of a termination KDP; for programs and Category 1 projects, the MDAA provides recommendations to the Decision Authority on the need for a termination KDP. The Decision Authority commissions an independent assessment, and following its completion, the governing PMC holds a Termination Review. For operating missions, terminations are handled in accordance with NPD 8010.3, Notification of Intent to Decommission or Terminate Operating Space Missions and Terminate Missions.

2.5.6 At the Termination Review, the program and the project teams present status, including any material requested by the Decision Authority. A Center assessment is presented as the Technical Authority (see Section 3.4) at the program or project level, or an OCE assessment is presented as the Technical Authority for tightly coupled programs with multiple Centers implementing the projects. Appropriate support organizations are represented (e.g., procurement, external affairs, legislative affairs, and public affairs), as needed. The decision and basis of decision are fully documented and reviewed with the NASA Associate Administrator prior to final implementation.

CHAPTER 3. Program and Project Management Roles and Responsibilities

3.1 Overview of Roles and Responsibilities

3.1.1 This chapter defines the roles and responsibilities of the key officials in the program/ project management process. Terms such as approval and concurrence, used in connection with these roles and responsibilities, are defined in Appendix A.

3.1.2 The roles and responsibilities of senior NASA management, along with fundamental principles of governance, are defined in NPD 1000.0, the NASA Strategic Management and Governance Handbook, and further outlined in NPD 1000.3, The NASA Organization. The key roles and responsibilities specific to program and projects consistent with NPD 1000.0 can be summarized as follows:

a. NASA Administrator - approves assignment of programs and Category 1 projects to Centers.

b. NASA Associate Administrator - is responsible for the technical and programmatic integration of programs at the Agency level, chairing the Agency PMC, serving as KDP Decision Authority for programs and Category 1 projects, and approving the PCA.

c. Associate Administrator, PA&E - is responsible for independent assessment of programs, Category 1 and 2 projects, and other projects as assigned in the areas of cost and management systems; conducting special studies; developing the Agency's Annual Performance Plans and Strategic Plan; and providing strategic guidance recommendations.

d. Chief Engineer - establishes policy, oversight, and assessment of the NASA engineering and program/project management process; implements the engineering technical authority process; 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; directs the NASA Engineering and Safety Center (NESC), and directs programs/projects to respond to requests from the NESC for data and information needed to make independent technical assessments and to respond to these assessments.

e. Chief Safety and Mission Assurance Officer - assures 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, and quality policies and procedures; serves as principal advisor to the Administrator and other senior officials on Agency-wide safety, reliability, maintainability, and quality assurance matters; performs independent program and project compliance verification audits; and implements the SMA technical authority process.

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

g. Chief Financial Officer - is responsible for ensuring that financial records and reports accurately reflect the status of all program and project capital acquisitions, including property, plant, and equipment (PP&E), and for the necessary controls to support such activities.

h. Mission Directorate Associate Administrator - is primarily responsible for managing programs within the Mission Directorate; recommends the assignment of programs and Category 1 projects to Centers; assigns Category 2 and 3 projects to Centers; serves as the KDP Decision Authority for Category 2 and 3 projects; and has responsibility for all program requirements, including budgets, schedules, and the high-level programmatic requirements levied on projects within the Mission Directorate. The MDAA may designate a Program Director or Program Executive to support the MDAA and the Program Manager in defining, integrating, and assessing program/project activities and to provide policy direction and guidance to the program/project.

i. Center Director - is responsible for establishing, developing, and maintaining the institutional capabilities (processes and procedures, human capital, facilities, and infrastructure) required for the execution of programs and projects, including the system of checks and balances to ensure the technical integrity of programs and projects assigned to the Center.

j. Program Manager - is responsible for the formulation and implementation of the program per the governing agreement with the sponsoring Mission Directorate.

k. Project Manager - is responsible for the formulation and implementation of the project per the governing agreement with the Program Manager.

l. Mission Support Office Assistant Administrators - establish policy and procedures for the oversight and assessment of their particular functional area (e.g., procurement).

3.1.3 The Project Manager reports to the Program Manager and both are supported by one or more NASA Centers (with facilities and experts from line or functional organizations). Each, however, is responsible and accountable for the safety, technical integrity, performance, and mission success of the program or project, while also meeting programmatic (cost and schedule) commitments. Accomplishing this requires a breadth of skills, so he/she must be knowledgeable about governing laws, acquisition regulations, policies affecting program and project safety, training of direct-report personnel, risk management, environmental management, resource management, program and project-unique test facilities, software management, responding to external requests for audits (e.g., OMB), protecting intellectual property and technology, and other aspects of program and project management.

3.2 Specific Roles and Responsibilities

3.2.1 Table 3-1, Roles and Responsibilities Relationships Matrix, provides a summary of the roles and responsibilities for the key program/project management officials. The table is informational only and is not intended to specify, levy, or remove requirements. As such, implementation of the specific roles and responsibilities is determined on a case-by-case basis and is documented in the Program or Project Plan.

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

3.2.2 It is important for the Program Manager and Project Manager to coordinate early and throughout the project life cycle with mission support organizations at NASA Headquarters and the implementing Centers. These mission support organizations include legal, procurement, security, finance, export control, human resources, public affairs, international affairs, property, facilities, environmental, aircraft operations, IT security, planetary protection, and others. They provide essential expertise and assure compliance with relevant laws, treaties, executive orders, and regulations.

3.3 Process for Handling Dissenting Opinions

3.3.1 NASA teams must have full and open discussions with all facts made available in order 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.

3.3.2 Unresolved issues of any nature (e.g., programmatic, safety, engineering, acquisition, accounting, etc.) within a team should be quickly elevated to achieve resolution at the appropriate level. At the discretion of the dissenting person(s), a decision may be appealed to the next higher level of management for resolution. Dissenting opinions raised by a Technical Authority (TA) are handled by the process set forth in Section 3.4.

3.3.3 When appropriate, the concern is documented by including agreed-to facts, discussion of the differing positions with rationale and impacts and the parties recommendations, approved by the representative of each view, concurred by affected parties, and provided to program/project management and the appropriate TA with notification to the second higher level of management. In cases of urgency, an oral presentation (including the information stated above) with all affected organizations in attendance and with advance notification to the second higher level of management may be utilized with documentation follow-up.

3.3.4 Management's decision/action on the memorandum (or oral presentation) is documented and provided to the dissenter and to the notified managers and becomes part of the program/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.4 Technical Authority

3.4.1 The NASA governance model prescribes a management structure that employs checks and balances between key organizations to ensure that decisions have the benefit of different points of view and are not made in isolation. Consequently, NASA has adopted two basic authority processes: the programmatic authority process and the technical authority process. The programmatic authority process is largely described by the roles and responsibilities of the NASA AA, MDAAs, and program and project managers in Sections 3.1 and 3.2. This section describes the technical authority process.

3.4.1.1 The technical authority process provides for the selection of individuals at different levels of responsibility who provide an independent view of matters within their respective areas of expertise. In this document, the term Technical Authority is used to refer to such an individual, but is also used (without capitalization) to refer to elements of the technical authority process. There are three distinct types of Technical Authorities (TAs): Engineering TAs, SMA TAs, and Health and Medical TAs, each of whom is discussed in this section. A key aspect of the technical authority process is that the TAs are funded independently of the program/project. In the technical authority process, their responsibilities include:

a. Approving changes to, and waivers of all TA-owned requirements. The TA is responsible for assuring that changes to and waivers of technical requirements are submitted to and acted on by the appropriate level of TA.

b. Serving as members of program/project control boards, change boards, and internal review boards.

3.4.1.2 The day-to-day involvement of the TAs in program/project activities as members of the program/project's control, change, and internal review boards should ensure that any significant views from TAs will be available to the program/project in a timely manner and should be handled during the normal program/project processes. The ultimate responsibility for program/project success in conformance with governing requirements remains the responsibility of the Program/Project Manager.

3.4.1.3 Infrequent circumstances may arise when a Technical Authority or the Program/Project Manager may disagree on a proposed programmatic or technical action and judge that the issue rises to a level of significance that the next higher level of management should be involved. In such circumstances:

a. The Program/Project Manager (or Chair of the controlling board) has the authority to make a decision while resolution is attempted at the next higher level of Programmatic and Technical Authority.

b. Resolution should occur prior to implementation whenever possible. However, the Program/Project Manager may proceed at risk in parallel with pursuit of resolution if they deem it in the best interest of the program/project. In such circumstances, the next higher level of Programmatic and Technical Authority would be informed of the decision to proceed at risk.

c. Resolution should be attempted at successively higher levels of Programmatic Authority and Technical Authority until resolved. Final appeals are made to the Office of the Administrator.

3.4.2 The Engineering Technical Authority establishes and is responsible for the engineering design processes, specifications, rules, best practices, etc., necessary to fulfill programmatic mission performance requirements. Engineering technical authority responsibilities originate with the NASA Administrator and are formally delegated to the NASA Chief Engineer. Specific engineering technical authority responsibilities may then be formally delegated from the NASA Chief Engineer to Center, program, project, and system-level Engineering Technical Authorities.

3.4.2.1 The NASA Chief Engineer provides overall leadership of the engineering technical authority process for space flight programs/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 Engineering Technical Authorities on programs and Category 1 projects and is notified of the appointment of other Engineering Technical Authorities. The NASA Chief Engineer hears appeals of the Engineering Technical Authority's decisions when they cannot be resolved at lower levels.

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

a. Center Director (CD) - The CD (or the Center Engineering Director, or designee) is the Center Engineering Technical Authority responsible for Center engineering design processes, specifications, rules, best practices, etc., necessary to fulfill mission performance requirements for projects or major systems implemented by the Center. (The CD may delegate Center engineering technical authority implementation responsibility to an individual in the Center' engineering leadership.) The Center Engineering Technical Authority approves waivers and changes in Center requirements. The CD appoints, with the approval of the NASA Chief Engineer, individuals for the position of Center Engineering Director (or equivalent) and for the Engineering Technical Authority positions down to and including Program Chief Engineers and Category 1 Project Chief Engineers (or equivalents).¹⁵ The CD appoints Category 2 and 3 Project Chief Engineers and Lead Discipline Engineers. (On some programs and projects, the program- and project-level Engineering Technical Authority may also serve as the program/project Systems Engineering Manager or Systems Engineering and Integration Manager; in these instances, the Program/Project Manager concurs on the appointment of the Engineering Technical Authorities.)

b. Program/Project Chief Engineer (PCE) - The PCE (or equivalent as per footnote below) is the Engineering Technical Authority for the program/project and is the single point of contact for the engineering technical authority process within the program/project. In executing this role, the PCE works with the Center Engineering Director(s) (or designees), as necessary, to ensure the engineering technical authority direction provided to the program/project reflects the view of the Center engineering community (or NASA engineering community, where appropriate). When there are disagreements between the PCE and the engineering community, resolution is sought at the next higher level of the Center Engineering Technical Authority in accordance with Section 3.3. To ensure independence, the PCE is assigned to the program/project, but is organizationally in the Center Engineering Directorate. The PCE is responsible for assuring that changes to, and waivers of, engineering requirements are submitted to, and acted upon by, the appropriate level of Engineering Technical Authority. At the level of delegated engineering technical authority responsibility, the PCE serves as a member of program/project control boards/change boards (or equivalent), and thereby concurs in the establishment of changes to, and waivers of, engineering requirements at this level. The PCE also serves as a member of internal review boards at the level of delegated engineering technical authority responsibility.

c. Lead Discipline Engineer (LDE) - The LDE is a senior technical engineer in a specific discipline who is designated as the Engineering Technical Authority for that discipline at the Center. To ensure independence, the LDE is organizationally separate from the program/project. The LDE assists the program/project through direct involvement with working-level engineers to identify engineering requirements 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.4.2.3 Although a limited number of individuals make up the Engineering Technical Authorities, their work is enabled by the contributions of the program/project's working-level engineers and other supporting personnel (e.g., contracting officers).The working-level engineers are funded by the program/project and consequently may not serve in an Engineering Technical Authority 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 hardware/software that conforms 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.4.3 The SMA Technical Authority establishes and is responsible for the SMA design processes, specifications, rules, best practices, etc., necessary to fulfill programmatic mission performance requirements.

3.4.3.1 For tightly coupled programs, SMA Technical Authority starts with the NASA Chief SMA Officer and flows to the Center SMA Director and Chief Safety Officer. For other programs, SMA Technical Authority starts with the NASA Chief SMA Officer and flows down to the Center SMA Director, and then to the Program SMA Lead. For projects, SMA Technical Authority originates with the NASA Chief SMA Officer and flows down to the Center Director, and then to the Center SMA Director, and from there, to the Project SMA Lead. To ensure independence, SMA Technical Authority personnel are organizationally separate from the program/project.

3.4.3.2 The Center SMA Director is responsible for establishing and maintaining institutional SMA policies and practices, consistent with Agency policies and standards. The Center SMA Director is also responsible for assuring that the program/project complies with both the program/project and Center SMA requirements. The program/project SMA Plan, which describes how the program/project will comply with these requirements, is part of the Program/Project Plan.

3.4.4 The Health and Medical Technical Authority is the NASA Chief Health and Medical Officer (CHMO).The Center Chief Medical Officer is responsible for assuring that the program/project complies with health and medical requirements through the process specified in the Center Health and Medical Authority (HMA) implementation plan, which is compliant with NPD 8900.5, NASA Health and Medical Policy for Human Space Flight Exploration, and NID, NM 1240-41, NASA Health and Medical Authority. The CHMO hears appeals of HMA decisions when issues cannot be resolved below the Agency level.

3.4.5 Program/project internal control boards, change boards, and review boards (or their equivalents) are fundamental to program/project management. These boards comply with the following:

a. The Program/Project Manager (or formally designated representative) chairs each board.

b. The Technical Authorities (engineering, SMA and, where appropriate, health and medical) are represented on the boards.

3.5 Center Reimbursable Work

3.5.1 A Center negotiating reimbursable work for another agency must propose NPR 7120.5D as the basis by which it will perform the work. If the sponsoring agency does not want NPR 7120.5D requirements (or a subset of those requirements) to be followed, then the inter-agency MOU/MOA or the contract must 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 must obtain a formal waiver by the NASA CE for those NPR 7120.5D requirements that are not to be followed, or the Agency will direct the Center not to accept the work.

3.6 Waiver Approval Authority

3.6.1 Waivers to NPR 7120.5D requirements may be granted by the officials shown in Table 3-2.

3.6.2 Requests for waivers to NPR 7120.5D requirements are documented and submitted for approval using the NPR 7120.5D Waiver Form below. (The form is available electronically on the POLARIS website at https://polaris.nasa.gov.) Prior to the KPD I for programs (KDP II for single-project programs) and KDP C for projects, these requests may be documented and attached to a single waiver to assure proper routing and control. Waivers impacting formulation or requiring long lead time may be submitted individually early in formulation. Following KDP I for programs (KDP II for single-project programs) and KDP C for projects, waivers must be submitted individually to the appropriate authority.

3.6.3 Evaluation and disposition of all other requirements change requests and waivers (including waivers of Agency-level requirements and standards) must comply with the following:

a. The organizations and the organizational levels that agreed to the establishment of a requirement must agree to the change or waiver of that requirement, unless this has been formally delegated elsewhere.

b. The next higher programmatic authority and Technical Authority are informed in a timely manner of change requests or waivers that could affect that level.

CHAPTER 4. Program and Project Requirements by Phase

4.1 Programs -- Formulation Phase

4.1.1 Purpose: The purpose of program formulation activities is to establish a cost-effective program that is demonstrably capable of meeting Agency and Mission Directorate goals and objectives. The program Formulation Authorization Document (FAD) authorizes a Program Manager to initiate the planning of a new program and to perform the analyses required to formulate a sound Program Plan. Major reviews leading to approval at KDP I are the Acquisition Strategy Meeting (ASM), the Program/System Requirements Review (P/SRR), the Program/System Definition Review (P/SDR)/ Program Approval Review (PAR), and the governing PMC review. In addition, at the discretion of the DA, a Preliminary Program Approval Review (PPAR) leading up to a KDP 0 may be required to ensure major issues are understood and resolved prior to KDP I. A summary of the required gate products is provided in Table 4-1.

4.1.2 Requirements: During program formulation, the Program Manager and the program team; shall:

(1) Plan, prepare for, and support the Acquisition Strategy Meeting (ASM) prior to partnership commitments and obtain the ASM minutes.

(2) Support the MDAA in developing and obtaining approval of the FAD, PCA, and appropriate annual budget submissions.

(3) Prepare and obtain approval of the Program Plan that follows the template in Appendix E. (See Table 4-2 for a list of required Program Plan Control Plans and their required maturity.)

(4) Support the MDAA and the NASA HQ Office of External Relations in obtaining approved interagency and international agreements (including the planning and negotiation of agreements and recommendations on joint participation; in reviews, integration and test, and risk management).

(5) Document the traceability of program requirements on individual projects to Agency needs, goals, and objectives, as described in the NASA Strategic Plan.

(6) Initiate the development of technologies that cut across multiple projects within the program.

(7) Prior to the program life-cycle formulation reviews shown in Figure 2-3, conduct internal reviews in accordance with NPR 7123.1, Center practices, and the requirements of this document.

(8) Plan, prepare for, and support the program life-cycle formulation reviews shown in Figure 2-3 in accordance with NPR 7123.1, Center practices, and the requirements of this document.

(9) If required by the DA, obtain KDP 0 readiness products as shown in Table 4-1.

(10) If required by the DA, plan, prepare for, and support the governing PMC review prior to KDP 0.

b. For single-project and tightly coupled programs - implement the requirements in paragraphs 4.3.2 and 4.4.2 (Pre-Phase A and Phase A) with the following stipulations:

(1) In single-project programs, the Project Plan may serve as the Program Plan, and KDP 0 (if required by the DA) and KDP I serve in lieu of KDP A and KDP B, respectively. In keeping with this, single-project programs are approved for implementation at KDP II. (At the discretion of the MDAA, there may also be a Project Plan separate from the Program Plan. In either case, all content required in Program and Project Plan templates must be included.)

(2) In tightly coupled programs, separate Project Plans are prepared for projects during their formulation. The Program Manager may allocate portions of the Program Plan to these individual Project Plans.

4.2 Programs - Implementation Phase

4.2.1 Purpose: During implementation, the Program Manager works with the MDAA and the constituent projects to execute the Program Plan in a cost-effective manner. Program reviews ensure that the program continues to contribute to Agency and Mission Directorate goals and objectives within funding constraints. A summary of the required gate products is provided in Table 4-1.

4.2.2 Requirements: During program implementation, the Program Manager and the program team shall:

(3) Update the baseline Program Plan at KDP II and other KDPs, as appropriate. See Table 4-2 for a list of required Program Plan Control Plans and their required maturity.

(4) Support the MDAA and the NASA HQ Office of External Relations in obtaining updated interagency and international agreements (including the planning and negotiation of updated agreements and recommendations on joint participation; in reviews, integration and test, and risk management).

(5) Conduct planning, program-level systems engineering, and integration, as appropriate, to support the MDAA in initiating the project selection process.

(6) Support the MDAA in the selection of projects, either assigned or through a competitive process.

(8) Prior to the program life-cycle implementation reviews shown in Figure 2-3, conduct internal reviews in accordance with NPR 7123.1, Center practices, and the requirements of this document.

(9) Plan, prepare for, and support the program life-cycle implementation reviews shown in Figure 2-3 in accordance with NPR 7123.1, Center practices, and the requirements of this document.

(10) Maintain programmatic and technical oversight of the projects within the program and report their status periodically.

(11) Review and approve annual project budget submission inputs and prepare annual program budget submissions.

(12) Continue to develop technologies that cut across multiple projects within the program.

(14) Conduct program-level completion activities for each project in accordance with the project life cycle for Phase F (see paragraph 4.9.2).

(1) For KDP II, implement the requirements in paragraph 4.5.2 (Phase B) in the manner documented in the Program Plan (except those requirements allocated to specific projects and documented in their Project Plans).

(2) For KDP III, implement the requirements in paragraph 4.6.2 (Phase C) in the manner documented in the Program Plan (except those requirements allocated to specific projects and documented in their Project Plans).

(3) For KDP IV, implement the requirements of paragraph 4.7.2 (Phase D) in the manner documented in the Program Plan (except those requirements allocated to specific projects and documented in their Project Plans).

(4) For KDP V, implement the requirements of paragraph 4.8.2 (Phase E) in the manner documented in the Program Plan (except those requirements allocated to specific projects and documented in their Project Plans).

4.3 Projects - Pre-Phase A

4.3.1 Purpose: During Pre-Phase A, a pre-project team studies a broad range of mission concepts that contribute to program and Mission Directorate goals and objectives. These advanced studies, along with interactions with customers and other potential stakeholders, help the team to identify promising mission concept(s) and draft project-level requirements. The team also identifies potential technology needs (based on the best mission concepts) and assesses the gaps between such needs and current and planned technology readiness levels. These activities are focused toward a Mission Concept Review and KDP A. A summary of the required gate products for this phase is provided in Table 4-3.

4.3.2 Requirements: During Pre-Phase A, the pre-project manager and team shall:

(2) Support the Program Manager and the MDAA in the development of the draft program requirements on the project.

(2) Prior to the project independent life-cycle reviews shown in Figure 2-4 for this phase, conduct internal reviews in accordance with NPR 7123.1, Center practices, and the requirements of this document.

(3) Plan, prepare for, and support the project independent life-cycle reviews shown in Figure 2-4 for this phase in accordance with NPR 7123.1, Center practices, and the requirements of this document.

1) Develop and document a draft Integrated Baseline for all work to be performed by the project that includes the following:

(i) A high-level Work Breakdown Structure (WBS) consistent with the NASA standard space flight project WBS (Appendix G), a schedule, and a rough-order-of-magnitude cost estimate and cost range.

(ii) An assessment of potential technology needs versus current and planned technology readiness levels, as well as potential opportunities to use commercial, academic, and other government agency sources of technology.

(iii) An assessment of potential infrastructure and workforce needs versus current plans, as well as opportunities to use infrastructure and workforce in other government agencies, industry, academia, and international organizations.

(v) Identification of conceptual acquisition strategies for proposed major procurements.

4.4 Projects - Phase A

4.4.1 Purpose: During Phase A, a project team is formed to fully develop a baseline mission concept and begin or assume responsibility for the development of needed technologies. This work, along with interactions with customers and other potential stakeholders, helps with the baselining of a mission concept and the program requirements on the project. These activities are focused toward System Requirements Review (SRR) and System Definition Review (SDR/PNAR) (or Mission Definition Review (MDR/PNAR)). The SRR and SDR/PNAR (or MDR/PNAR) process culminates in KDP B. A summary of the required gate products for this phase is provided in Table 4-3.

4.4.2 Requirements: During Phase A, the Project Manager and project team shall:¹⁶

(1) Support the Program Manager and the MDAA in the development of the baseline program requirements on the project.¹⁷

(2) Plan, prepare for, and support the Acquisition Strategy Meeting (ASM) prior to partnership agreements and obtain the ASM minutes.

(3) Support the Program Manager, the MDAA, and the NASA HQ Office of External Relations in initiating interagency and international agreements (including the planning and negotiation of agreements and recommendations on joint participation in reviews, integration and test, and risk management).

(2) Develop and document a baseline mission concept (including key risk drivers and mitigation options and mission descope options).

(5) Develop an initial orbital debris assessment in accordance with NASA Safety Standard 1740.14, Guidelines and Assessment Procedures for Limiting Orbital Debris.

(6) Prior to the project independent life-cycle reviews shown in Figure 2-4 for this phase, conduct internal reviews in accordance with NPR 7123.1, Center practices, and the requirements of this document.

(7) Plan, prepare for, and support the project independent life-cycle reviews shown in Figure 2-4 for this phase in accordance with NPR 7123.1, Center practices, and the requirements of this document.

(2) Prepare a preliminary Project Plan that follows the template in Appendix F. See Table 4-4 for a list of the Control Plans and their required maturity by phase.

(3) For contracts requiring Earned Value Management (EVM) (see Appendix F, paragraph 3.1.c(6)), conduct required Integrated Baseline Reviews (IBRs).

(4) For Category 1 and 2 projects, develop 60 days prior to KDP B a preliminary Cost Analysis Data Requirement (CADRe) that is based on the project's technical baseline/mission concept and consistent with the NASA Cost Estimating Handbook.¹⁸ (Note: For competed projects, the requirement for a preliminary CADRe is met by the submission of a copy of the winning proposal and concept study report.)

(5) Develop and document a preliminary Integrated Baseline for all work to be performed by the project, noting the following:

(i) The project's preliminary Integrated Baseline is consistent with the NASA standard space flight project WBS (see Appendix G) and has an associated WBS dictionary.

(ii) The project's preliminary Integrated Baseline includes a preliminary integrated master schedule, preliminary life-cycle cost estimate, workforce estimates, and the project's technical baseline/mission concept, all consistent with the program requirements levied on the project.

(iii) The preliminary life-cycle cost estimate is based on the project's technical baseline/mission concept and preliminary integrated master schedule.

(iv) The preliminary life-cycle cost estimate uses the latest available full-cost accounting initiative guidance and practices.

(v) The preliminary life-cycle cost estimate includes reserves, along with the level of confidence estimate provided by the reserves based on a cost-risk analysis.

(vi) The preliminary life-cycle cost estimate is time-phased by Government Fiscal Year (GFY) to WBS Level 2.

(6) Complete a preliminary business case analysis for infrastructure for each proposed project real property infrastructure investment consistent with NPD 8820.2, Design and Construction of Facilities and NPR 8820.2, Facility Project Implementation Guide, and for the acquisition of new aircraft consistent with NPR 7900.3, NASA Aircraft Operations Management.¹⁹

(7) Work with the appropriate NASA Headquarters offices to initiate the development of MOUs/MOAs with external partners, as needed.

(8) Obtain a planetary protection certification for the mission (if required) in accordance with NPD 8020.7, Biological Contamination Control for Outbound and Inbound Planetary Spacecraft, and NPR 8020.12, Planetary Protection Provisions for Robotic Extraterrestrial Missions.

(9) Develop a Nuclear Safety Launch Approval Plan (for missions with nuclear materials) in accordance with NPR 8715.3, NASA General Safety Program Requirements.

(11) Prepare for approval by the Program Manager a list of long-lead procurements that need to be procured in Phase B.

(12) In accordance with NPR 2190.1, NASA Export Control Program, support the appropriate NASA export control officials to identify and assess export-controlled technical data that potentially will be provided to foreign partners and the approval requirements for release of that data, all as a part of developing the project's Export Control Plan.

(13) In coordination with the OCFO, complete the Alternative Future Use Questionnaire (Form NF 1739), Section A, to determine the appropriate accounting treatment of capital assets. Once completed, forward the questionnaire to the OCFO, Property Branch. (Note: The questionnaire can be found in NASA's Electronics Forms Database.)

(2) Plan, prepare for, and support the governing PMC review prior to KDP B. (Note: This does not apply to competed missions.)

4.5 Projects - Phase B

4.5.1 Purpose: During Phase B, the project team completes its preliminary design and technology development. These activities are focused toward completing the Project Plan and Preliminary Design Review (PDR)/Non-Advocate Review (NAR). The PDR/NAR process culminates in KDP C. A summary of the required gate products for this phase is provided in Table 4-3.

4.5.2 Requirements: During Phase B, the Project Manager and the project team shall:

(2) Complete the environmental planning process as explained in NPR 8580.1, Implementing the National Environmental Policy Act, and Executive Order 12114. (Note: For certain projects utilizing nuclear power sources, completion of the environmental planning process can be extended, with the approval of the DA, into Phase C, but must be completed by the project CDR.)

(3) In coordination with the Program Manager, the MDAA, and the NASA HQ Office of External Relations, support the development of baseline external agreements, such as interagency and international agreements (including the planning and negotiation of agreements and recommendations on joint participation in reviews, integration and test, and risk management).

(4) Coordinate with the Space Operations Mission Directorate (SOMD) if the project involves space transportation services or launch services, in compliance with NPD 8610.7, Launch Services Risk Mitigation Policy for NASA-Owned and/or NASA-Sponsored Payloads/Missions, and NPD 8610.12, Office of Space Operations (OSO) Space Transportation Services for NASA and NASA-Sponsored Payloads.

(2) Baseline the system-level requirements and develop the subsystem and lower-level technical requirements leading to the PDR baseline.

(3) Develop a set of system and associated subsystem preliminary designs, including interface definitions, and document this work in a preliminary design report.

(4) As part of baselining the interface control documents, document compliance with NPD 8010.2, Use of the SI (Metric) System of Measurement in NASA Programs, and/or obtain any necessary waivers.

(6) Complete development of mission-critical or enabling technology, as needed, with demonstrated evidence of required technology qualification (i.e., component and/or breadboard validation in the relevant environment) or execute off-ramps (i.e., substitution of more mature or proven technologies) and document this work in a technology readiness assessment report.

(7) Plan and execute long-lead procurements in accordance with the Acquisition Plan. (Note: Long-lead procurements can only be initiated in Phase B when specifically approved by the MDAA.)

(10) Develop a preliminary orbital debris assessment in accordance with NASA Safety Standard 1740.14.

(11) Develop and document a preliminary Missile System Pre-Launch Safety Package (MSPSP) in accordance with NASA-STD-8719.8, Expendable Launch Vehicle Payload Safety Review Process Standard, June 1998, and Air Force Space Command Manual 91-710, Range Safety User Requirements, Vol. 3. (Note: The latest release is dated July 1, 2004.)

(12) Prior to the project life-cycle reviews shown in Figure 2-4 for this phase, conduct internal reviews in accordance with NPR 7123.1, Center practices, and the requirements of this document.

(13) Plan, prepare for, and support the project life-cycle reviews shown in Figure 2-4 for this phase in accordance with NPR 7123.1, Center practices, and the requirements of this document.

(1) Complete and obtain approval of the Project Plan that follows the template in Appendix F. See Table 4-4 for a list of the Control Plans and their required maturity by phase.

(2) For contracts requiring Earned Value Management (EVM) (see Appendix F, paragraph 3.1.c(6)), conduct required Integrated Baseline Reviews (IBRs).

(3) For Category 1 and 2 projects, develop 60 days prior to KDP C a baseline CADRe that is based on the PDR-technical baseline and consistent with the NASA Cost Estimating Handbook.

(4) Prepare and finalize Phase C/D work agreements. (Note: Prior to approval to proceed, Phase C/D contracts' work scope and cost/price can be negotiated but not executed. Once the project has been approved and funding is available, the negotiated contracts can be executed, assuming nothing material has changed.)

(5) Develop, document, and maintain a project Integrated Baseline for all work performed by the project noting the following:

(i) The project's Integrated Baseline is consistent with the NASA standard space flight project WBS (see Appendix G) and has an associated WBS dictionary.

(ii) The project's Integrated Baseline includes the integrated master schedule, baseline life-cycle cost estimate, workforce estimates, and the PDR-technical baseline, all consistent with the program requirements levied on the project.

(iii) The baseline life-cycle cost estimate is based on the PDR-technical baseline and integrated master schedule and is expected to include a review of the entire scope of work with a series of in-depth assessments of selected critical work elements of the WBS prior to and following the project's PDR/NAR preceding KDP C. (Note: The CADRe is updated to reflect changes.)

(iv) The baseline life-cycle cost estimate uses the latest available full-cost accounting initiative guidance and practices.

(v) The baseline life-cycle cost estimate includes reserves, along with the level of confidence estimate provided by the reserves based on a cost-risk analysis.

(vi) The baseline life-cycle cost estimate is time-phased by Government Fiscal Year (GFY) to WBS Level 2.

(6) Reconcile (i.e., explain any significant differences) the project's baseline life-cycle cost estimate with the PDR/NAR Independent Cost Estimate.

(7) Complete a business case analysis for infrastructure for each of the project's proposed real property infrastructure investment consistent with NPD 8820.2, Design and Construction of Facilities, and NPR 8820.2, Facility Project Implementation Guide, and for the acquisition of new aircraft consistent with NPR 7900.3, NASA Aircraft Operations Management.²⁰ (Note: Business case analyses require the approval of the MDAA and the Assistant Administrator for Infrastructure and Administration, or designee.)

(8) Develop a baseline planetary protection plan (if required) in accordance with NPD 8020.7, Biological Contamination Control for Outbound and Inbound Planetary Spacecraft, and NPR 8020.12, Planetary Protection Provisions for Robotic Extraterrestrial Missions.

(9) Develop a preliminary Range Safety Risk Management Plan in accordance with NPR 8715.5, Range Safety Program.

(10) In coordination with the OCFO, complete the Alternative Future Use Questionnaire (Form NF 1739), Section B, to identify the acquisition components of the project and to determine the appropriate accounting treatment of the capital acquisitions within the project. Once completed, forward the questionnaire to the OCFO, Property Branch. (Note: The questionnaire can be found in NASA's Electronics Forms Database.)

4.6 Projects - Phase C

4.6.1 Purpose: During Phase C, the project completes the design that meets the detailed requirements and begins fabrication of test and flight article components, assemblies, and subsystems. These activities focus on preparing for the Critical Design Review (CDR) and the System Integration Review (SIR). This phase culminates in KDP D. A summary of the required gate products for this phase is provided in Table 4-3.

4.6.2 Requirements: During Phase C, the Project Manager and the project team shall:

(2) Complete all requisite flight and ground designs/analyses through their respective CDRs in accordance with NPR 7123.1 and document this work in detailed design report(s).

(3) Develop and test all requisite engineering models (brass boards, breadboards, full-up models) sufficiently prior to lower-level CDRs to enable test results to affect detailed designs.

(4) Develop requisite system and subsystem test beds needed for qualification and acceptance testing of flight articles.

(5) Following the appropriate lower-level CDR, initiate fabrication/procurement of flight article components, assemblies, and/or subsystems.

(6) Initiate the qualification and acceptance testing of flight article components, assemblies, and/or subsystems.

(7) Hold peer reviews, as appropriate, prior to major project reviews in accordance with the Project Review Plan.

(8) Develop a baseline orbital debris assessment prior to the project CDR in accordance with NASA Safety Standard 1740.14, Guidelines and Assessment Procedures for Limiting Orbital Debris.

(9) Develop a preliminary Operations Handbook that will be used to support the operations team.

(10) Develop and document a baseline Missile System Pre-Launch Safety Package (MSPSP) by the project-level CDR in accordance with NASA-STD-8719.8, Expendable Launch Vehicle Payload Safety Review Process Standard, June 1998, and Air Force Space Command Manual 91-710, Range Safety User Requirements, Vol. 3. (Note: The latest release is dated July 1, 2004.)

(11) Prior to the project independent life-cycle reviews shown in Figure 2-4 for this phase, conduct internal reviews in accordance with NPR 7123.1, Center practices, and the requirements of this document.

(12) Plan, prepare for, and support the project independent life-cycle reviews shown in Figure 2-4 for this phase in accordance with NPR 7123.1, Center practices, and the requirements of this document.

(13) Following the SIR and/or PRR, (unless otherwise directed by the Program Manager) initiate system assembly and integration and test activities even if KDP D has not occurred.

(1) For Category 1 and 2 projects, update the CADRe consistent with the NASA Cost Estimating Handbook following the project-level CDR.

(3) Maintain the Integrated Baseline under configuration management with traceability to the KDP C-approved baseline.

(5) Develop a baseline Range Safety Risk Management Plan in accordance with NPR 8715.5, Range Safety Program.

(2) For contracts requiring Earned Value Management (EVM) (see Appendix F, paragraph 3.1.c(6)), conduct required Integrated Baseline Reviews (IBRs).

(3) Provide immediate written notice and a recovery plan to the Program Manager and the MDAA if the latest Phase C through D Estimate at Completion (EAC) of the project exceeds by 15% or more the KDP C-approved Integrated Baseline cost for Phases C through D. (Note: Since the Integrated Baseline cost contains project reserves, an EAC exceeding the Integrated Baseline cost presumes that these reserves will be exhausted.)

(4) Provide immediate written notice and a recovery plan to the Program Manager and the MDAA if a milestone listed for Phases C and D on the project life-cycle chart (Figure 2-4) is estimated to be delayed in excess of six months from the date scheduled in the KDP C-approved Integrated Baseline.

(5) If the trigger points in (3) or (4) above are breached and upon written notice from the Program Manager, update the Project Plan per direction received from the Program Manager.

4.7 Projects - Phase D

4.7.1 Purpose: During Phase D, the project performs system assembly, integration, and test. These activities focus on preparing for the Flight Readiness Review (FRR). This phase culminates in KDP E. A summary of the required gate products for this phase is provided in Table 4-3.

4.7.2 Requirements: During Phase D, the Project Manager and the project team shall:

(3) As required by NPR 7123.1, execute and document the results of the project's multi-tiered Verification and Validation (V&V) Plan.

(6) Prepare "as-built" and "as-deployed" hardware and software documentation, including "close-out" photographs.

(7) Complete all operational support and other enabling developments (e.g., facilities, equipment, and updated databases), including a baseline Operations Handbook to support the operations team.

(8) Conduct operational tests and training, including normal and anomalous scenarios.

(9) Prior to the project independent life-cycle reviews shown in Figure 2-4 for this phase, conduct internal reviews in accordance with NPR 7123.1, Center practices, and the requirements of this document.

(10) Plan, prepare for, and support the project independent life-cycle reviews shown in Figure 2-4 for this phase in accordance with NPR 7123.1, Center practices, and the requirements of this document.

(11) Establish and maintain an integrated logistics support (ILS) capability, including spares, ground support equipment, and system maintenance and operating procedures, in accordance with the project's Logistics Plan.

(12) Forty-five (45) days prior to delivery of the spacecraft to the launch facility, update the Missile System Pre-Launch Safety Package (MSPSP) in accordance with NASA-STD-8719.8, Expendable Launch Vehicle Payload Safety Review Process Standard, June 1998, and Air Force Space Command Manual 91-710, Range Safety User Requirements, Vol. 3. (Note: The latest release is dated July 1, 2004.)

(13) Launch and perform system checkout. (Note: The checkout period is specified in the Project Plan.)

(2) For contracts requiring EVM (see Appendix F, paragraph 3.1.c(6)), conduct required Integrated Baseline Reviews (IBRs).

(1) Provide immediate written notice and a recovery plan to the Program Manager and the MDAA if the latest Phase C through D Estimate at Completion (EAC) of the project exceeds by 15% or more the KDP C-approved Integrated Baseline cost for Phases C through D. (Note: Since the Integrated Baseline cost contains project reserves, an EAC exceeding the Integrated Baseline cost presumes that these reserves will be exhausted.)

(2) Provide immediate written notice and a recovery plan to the Program Manager and the MDAA if a milestone listed for Phases C and D on the project life-cycle chart (Figure 2-4) is estimated to be delayed in excess of six months from the date scheduled in the KDP C-approved Integrated Baseline.

(3) If the trigger points in (1) or (2) above are breached and upon written notice from the Program Manager, update the Project Plan per direction received from the Program Manager.

4.8 Projects - Phase E

4.8.1 Purpose: During Phase E, the project implements the Missions Operations Plan developed in previous phases. This phase culminates in KDP F. A summary of the required gate products for this phase is provided in Table 4-3.

4.8.2 Requirements: During Phase E, the Project Manager and the project team shall:

(2) Execute the mission in accordance with the Mission Operations Plan and document this work in a Mission Report.

(3) Prior to the project life-cycle reviews shown in Figure 2-4 for this phase, conduct internal reviews in accordance with NPR 7123.1, Center practices, and the requirements of this document.

(4) Plan, prepare for, and support the project life-cycle reviews shown in Figure 2-4 for this phase in accordance with NPR 7123.1, Center practices, and the requirements of this document.

(5) Monitor system incidents, problems, and anomalies, as well as system margins to ensure that deployed project systems function as intended, and investigate system behavior that is observed to exceed established operational boundaries or expected trends, and implement corrective actions, as necessary.

(6) Provide sustaining engineering, as appropriate, to the mission to enhance efficiency, safety, and accommodate obsolescence.

(7) Capture and archive mission results, including engineering data on system and subsystem performance, in an MDAA-approved data depository.

(1) For Category 1 and 2 projects, update the CADRe consistent with the NASA Cost Estimating Handbook within 180 days after launch.

(2) As directed by the Program Manager, support the development of Project Plan revisions to continue the mission into extended operations beyond the primary mission phase or beyond any extension previously included in the plan.

4.9 Projects - Phase F

4.9.1 Purpose:; During Phase F, the project implements the Systems Decommissioning/ Disposal Plan developed in Phase E, and performs analyses of the returned data and any returned samples.

4.9.2 Requirements: During Phase F, the Project Manager and the project team shall:

(1) Complete analysis and archiving of mission and science data and curation of any returned samples, as well as archiving of project engineering and technical management data and documentation, and lessons learned in accordance with agreements, the Project Plan and Program Plan, and Center and Agency policies.

(2) Prior to the project life-cycle reviews shown in Figure 2-4 for this phase, conduct internal reviews in accordance with NPR 7123.1, Center practices, and the requirements of this document.

(3) Plan, prepare for, and support the project life-cycle reviews shown in Figure 2-4 for this phase in accordance with NPR 7123.1, Center practices, and the requirements of this document.

(4) Implement the Systems Decommissioning/Disposal Plan and safely dispose of project systems.

b. For Category 1 and 2 projects, prepare a final CADRe consistent with the NASA Cost Estimating Handbook.

APPENDIX A. Definitions

Acceptable Risk. The risk that is understood and agreed to by the program/project, governing PMC, Mission Directorate, and other customer(s) such that no further specific mitigating action is required. (Some mitigating actions might have already occurred.)

Acquisition. The acquiring by contract with appropriated funds of supplies or services (including construction) by and for the use of the Federal Government through purchase or lease, whether the supplies or services are already in existence or must be created, developed, demonstrated, and evaluated. Acquisition begins at the point when Agency needs are established and includes the description of requirements to satisfy Agency needs, solicitation and selection of sources, award of contracts, contract financing, contract performance, contract administration, and those technical and management functions directly related to the process of fulfilling Agency needs by contract. (Note: A broader view of the term acquisition is taken at the ASP meeting and ASM.)

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

Aircraft Operations. A mission support organization function that provides both manned and unmanned aircraft, whether U.S. Government owned or chartered, leased, or rented to accomplish work for NASA.

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 (LCC) through a cost analysis. The results of these two analyses are used together to produce a cost-effectiveness comparison that allows decision-makers to assess the relative value or potential programmatic returns of the alternatives. An AoA broadly examines multiple elements of program/ project alternatives (including technical performance, risk, LCC, and programmatic aspects).

Approval (for Implementation). The 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) must be documented.

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

Architectural Control Document (ACD). A configuration-controlled document or series of documents that embodies an Agency mission architecture(s), including the structure, relationships, principles, assumptions, and results of the analysis of alternatives that govern the design 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 Science Requirements. The mission performance requirements necessary to achieve the full science objectives of the mission. (Also see Threshold Science Requirements.)

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

Component Facilities. Complexes that are geographically separated from the NASA Center or institution to which they are assigned.

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

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

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, concurring in SRB membership, and receiving documented results of the review.

Cost Analysis Data Requirement (CADRe). A formal document designed to help managers to understand the cost and cost risk of space flight projects. The CADRe consists of a Part A "Narrative," a Part B "Technical Data" in tabular form, both provided by the program/project to the ICE team. A "Project Life Cycle Cost Estimate," produced by the project team, is appended as Part C, but the ICE team does not see Part C until it has produced its own independent estimate.

Decision Authority. The Agency's responsible individual who authorizes the transition of a program/project to the next life-cycle phase.

Derived Requirements. For a program, requirements that need to be satisfied in order to satisfy the Directorate requirements on the program. For a project, requirements that need to be satisfied in order to satisfy the program requirements on the project.

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

Earned Value Management (EVM). A tool for measuring and assessing project performance through the integration of technical scope with schedule and cost objectives during the execution of the project. EVM provides quantification of technical progress, enabling management to gain insight 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 (i.e., risky WBS elements).

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.

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

Evaluation. The continual, independent (i.e., outside the advocacy chain of the program/project) evaluation of the performance of a program or project and incorporation of the evaluation findings to ensure adequacy of planning and execution according to plan.

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 needs, goals, and objectives; 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 Authorization Document (FAD). The document issued by the MDAA (or MSOD) to authorize the formulation of a program whose goals will fulfill part of the Agency's Strategic Plan, Mission Directorate Strategies, or Mission Support Office Functional Leadership Plans. In addition, a FAD or equivalent is used to authorize the formulation of a project.

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 strategic needs, goals, and objectives.

Independent Cost Analysis (ICA). An independent analysis of program resources (including budget) and financial management associated with the program content over the program's budget horizon, conducted by an impartial body independent from the management or advocacy chain of the program. ICA includes, but is not limited to, the assessment of cost estimates, budgets, and schedules in relation to the program and its constituent projects' technical content, performance, and risk. ICAs may include Independent Cost Estimates (ICE), assessment of resource management, distribution and planning, and verification of cost-estimating methodologies. (ICAs are not life-cycle cost estimates but are assessments of the adequacy of the budget and management practices to accomplish the work scope through the budget horizon; as such, ICAs can be performed for programs/projects when a life-cycle ICE is not warranted.)

Independent Cost Estimate (ICE). An independent project cost estimate prepared by an office or other entity that is not under the supervision, direction, advocacy, or control of the project (or its chain of command) that is responsible for carrying out the development or acquisition of the program/project. An ICE is bounded by the project scope (total life cycle through all phases), schedule, technical content, risk, ground rules, and assumptions and is conducted with objectivity and the preservation of integrity of the cost estimate. ICEs are generally developed using parametric approaches that are tailored to reflect the design, development state, difficulty, and expertise of team members.

Information Technology. Any equipment, or interconnected system(s) of 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, 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.

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

Institutional Requirements. Infrastructure and workforce needed to support programs and projects. Specifically, the human resources, real property, facilities, aircraft, personal property, equipment, information technology resources, and administrative and program support services (e.g., environmental management) required to support programs and projects.

Integrated Baseline. The projects' technical performance baseline/mission content, technology application, and schedule milestones. The integrated baseline also includes the WBS, WBS dictionary, integrated master schedule, life-cycle cost and workforce estimates that are consistent with the program requirements on the project, the projects' CADRe (if applicable), and the technical performance baseline/mission content.

Integrated Baseline Review (IBR). A joint assessment by the offeror/contractor and the Government to verify the technical content and the realism of the related performance budgets, resources, and schedules. It should provide a mutual understanding of the inherent risks in offerors'/contractors' performance plans and the underlying management control systems, and it should formulate a plan to handle these risks.

Integrated Master Schedule. An integrated set of schedule data that reflects the total project scope of work as discrete and measurable tasks/milestones that are time-phased through the use of task durations, interdependencies, and date constraints and is traceable to the WBS.

Key Decision Point (KDP). 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).

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

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

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

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

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

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

Mission Directorate Program Management Council (MDPMC). The senior management group, chaired by an MDAA or designee, responsible for reviewing project formulation performance, recommending approval, and overseeing implementation of Category 2 and 3 projects according to Agency commitments, priorities, and policies.

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

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

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.

Principal Investigator (PI). 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.

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

Procurement Strategy Meeting (PSM). A meeting in which the Program/Project Manager, supported by the contracting officer, seeks Agency approval of the procurement approach (e.g., competition approach, small business goals, and government furnished property).The PSM is normally contract-specific but may address all contracts within a project. PSMs can occur multiple times over the project life cycle, are held prior to release of a solicitation, and are conducted in accordance with the NASA FAR Supplement. (The initial PSM will typically be held between the SDR/MDR/PNAR and the PDR/NAR. The AO process embodies the activities included in a PSM; therefore, a separate PSM is not required for AO-driven projects.)

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 defines a strategic direction that the Agency has identified as critical.

Program Commitment Agreement (PCA). The contract between the Associate Administrator and the cognizant MDAA that authorizes transition from formulation to implementation of a program.

Program Plan. The document that establishes the Programs' 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 Requirements. Requirements set by the Mission Directorate, program, project, and PI, if applicable. These include strategic scientific and exploration requirements, system performance requirements, and schedule, cost, and similar non-technical constraints.

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

Project. A specific investment identified in a Program Planhaving defined requirements, a life-cycle cost, a beginning, and an end. A project yields new or revised products that directly address NASA's strategic needs.

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

Reimbursable Program/Project. A program/project executed at a NASA Center for a sponsor other than NASA.

Risk. The combination of the probability that a program or project will experience an undesired event and the consequences, impact, or severity of the undesired event, were it to occur. The undesired event may come from technical or programmatic sources (e.g., a cost overrun, schedule slippage, safety mishap, health problem, malicious activities, environmental impact, failure to achieve a needed scientific or technological objective, or success criterion). Both the probability and consequences may have associated uncertainties.

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

Risk-Based Acquisition Management. The integration of risk management into the NASA acquisition process.

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

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, which covers physical assets, personnel, IT, communications, and operations.

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

Standing Review Board (SRB). The entity responsible for conducting independent reviews of the program/project per the life-cycle requirements. The SRB is advisory and is chartered to objectively assess the material presented by the program/project at a specific review.

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

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 its planned life within cost and schedule constraints. Systems engineering includes the engineering processes and technical management processes that consider the interface relationships across all elements of the system, other systems, or as a part of a larger system.

Technical Authority. The individual who specifically maintains technical responsibility over establishment of, changes to, and waivers of requirements in a designated area.

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

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

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

Waiver. A documented authorization intentionally releasing a program or project from meeting a requirement.

Work Agreement. The Center form (or equivalent), prepared for each program/project cost account and used to document agreements and commitments for the work to be performed, including scope of work, receivables/deliverables, schedule, budget, and assumptions.

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

APPENDIX B. Acronyms

OSTP Office of Science and Technology Policy (Executive Office of the White House)

APPENDIX C. Formulation Authorization Document Template

C.1 Program FAD Title Page

C.2 Project FAD Title Page

C.3. Program/Project FAD Template

Describe the purpose of the program/project. The program/project purpose must have 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.

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

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.

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 must be co-funded by a different Mission Directorate).

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 must be co-funded by the external participant).

Describe the reviews according to the space flight program and project reviews tables in Chapter 2, required during the formulation phase.

APPENDIX D. Program Commitment Agreement Template

D.1 PCA Title Page

D.2 PCA Template

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.

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.

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 PMC(s) 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.4.

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 needs, goals, and objectives and Agency requirements.

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

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

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

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

Identify the areas of highest risk for the program (covering safety, technical, institutional, cost, or schedule issues) in which failure may result in changes to the program/project baseline cost, schedule, 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.

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.

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.

Specify the type of reviews that will be performed during the life cycle of the program/project.

Identify the discrete set of expected deliverables (outcomes) that flow from the Agency goals and objectives, as defined in the Agency Strategic Plan.

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

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 Figure D-2 and may be supplemented with an attached addendum for each change, describing the change. The PCA should be updated to add approved projects or whenever substantial change makes it necessary.

				Termination	MDAA	Associate Administrator
Date	Event	Change	Addendum	Review Req’d	Signature	Signature
dd/mm/yy	Revalidation	None	N/A	No
dd/mm/yy	Revalidation	None	N/A	No
dd/mm/yy	Approval of new project	Addition of Project N	Ref. #1	No

APPENDIX E. Program Plan Template

E.1 Template Instructions

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 baseline commitments of the program, including identifying the high-level requirements on both the program and each constituent project. Project requirements 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 baseline commitments.

In this Program Plan template, all subordinate plans, collectively called Control Plans, are required. 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, and SEMP are required to be stand-alone plans with summaries and references provided in the Program Plan. 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.

Each section of the Program Plan template is required. If a section is not applicable to a particular program, indicate by stating that 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 must be obtained in accordance with the waiver process for NPR 7120.5D. This waiver approval is documented in Part 4.0, Waivers Log, of the Program Plan

E.2 Program Plan Title Page

E.3 Program Plan Template

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

State program goals and specific objectives, and provide clear traceability to the Agency's Needs, Goals, and Objectives and to Mission Directorate strategic goals and objectives. Program performance goals and their relationship to NASA program goals and objectives set forth in NPD 1001.1, 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.

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 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 NASA and outside NASA. Reference Section 3.4, the Acquisition Plan of this document, or provide the following information here:

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

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

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

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

b. Each Centers' responsibilities, as they relate to their respective requirement allocations referenced in Section 2.1, Requirements Baseline, below.

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

Describe briefly the implementation approach of the program, including 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 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.

a. 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 program to projects.

b 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 programs' 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).

c. 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 baseline science requirements. State each requirement in objective, quantifiable, and verifiable terms. Identify the project's principal schedule milestones, including PDR, 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 either 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).

Present a summary of the program's integrated master schedule (IMS), including all critical milestones, major events, and Agency and program-level reviews throughout the program life cycle. The summary schedule should include the logical relationships (interdependencies) for the critical milestones, major events, program reviews, and critical paths, as appropriate.

Present the program's funding requirements by fiscal year. State the 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. 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.

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.

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:

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

b. 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 goal and threshold values for the performance metrics to be achieved at each KDP, as appropriate; In addition, document the minimum mission success criteria associated with the high-level program requirements that, if not met, trigger consideration of a Termination Review.

c. Describe the program's Earned Value Management System (EVMS), if EVM requirements are to be levied at the program level.

d. Describe any additional specific tools the program will use to implement the program control processes, e.g., the requirements management system, the program scheduling system, the program information management systems.

e. Describe how the program will monitor and control the integrated master schedule (IMS).

f. Describe how the program will utilize its technical, schedule, and cost reserves to control the baseline.

g. Describe how the program plans to report technical, schedule, and cost status to the MDAA, including frequency and the level of detail.

h. Describe how the program will address technical waivers and how dissenting opinions will be handled.

Develop a program SMA Plan. The SMA Plan addresses life-cycle SMA functions and activities. The plan identifies and documents program-specific SMA roles, responsibilities, and relationships. This is accomplished through a program-unique mission assurance process map and matrix developed and maintained by the program with appropriate support and guidance of the Headquarters and/or Center SMA organization.

The Plan reflects a program life-cycle SMA process perspective, addressing areas including: procurement, management, design and engineering, design verification and test, software design, software verification and test, manufacturing, manufacturing verification and test, operations, and pre-flight verification and test.

The Plan also addresses specific critical SMA disciplines including (as a minimum): safety per NPR 8715.3, NASA Safety Manual, and NPR 8705.2, NASA Human Rating Requirements for Spaceflight Systems; quality assurance per NPD 8730.5, NASA Quality Assurance Program Policy; compliance verification, audit, safety and mission assurance reviews, and safety and mission assurance process maps per NPR 8705.6, Safety and Mission Assurance Audits, Reviews, and Assessments; reliability and maintainability per NPD 8720.1B, NASA Reliability and Maintainability (R&M) Program Policy; software safety and assurance per NASA-STD-8719.13, NASA Software Safety Standard; and NASA-STD-8739.8, NASA Software Assurance Standard; quality assurance functions per NPR 8735.2, Management of Government Quality Assurance Functions for NASA Contracts; and other applicable NASA procedural safety and mission success requirements.

Describe how the program will develop and manage a Closed Loop Problem Reporting and Resolution System. Describe how the program develops, tracks, and resolves problems. The process should include a well-defined data collection system and process for hardware and software problem and anomaly reports, problem analysis, and corrective action.

Summarize how the program will implement the NASA continuous risk management process in accordance with NPR 8000.4, Risk Management Procedural Requirements. Include the initial Significant Risk List and appropriate actions to mitigate each risk. Programs with international or other U.S. Government agency contributions must plan for, assess, and report on risks due to international or other government partners and plan for contingencies.

For tightly coupled programs, develop a stand-alone Risk Management Plan and reference the stand-alone Plan here.

The Program Acquisition Plan is developed by the Program Manager, supported by the Office of Procurement, and must be consistent with the results of the ASP meeting and the ASM. It documents an integrated acquisition strategy that enables the program to meet its mission objectives and provides the best value to NASA. In addition, the Acquisition Plan should:

a. Identify all major proposed acquisitions (such as engineering Design study, hardware and software development, and mission and data operations support) in relation to the program WBS. Provide summary information on each such proposed acquisition, including a Contract WBS; major deliverable items; type of procurement (competitive, AO for instruments); type of contract (cost-reimbursable, fixed-price); source (institutional, contractor, other U.S. Government agency, or international organization); procuring activity; and surveillance approach. Identify those major procurements that require a Procurement Strategy Meeting (PSM).

b. Describe completed or planned studies supporting make-or-buy decisions, considering NASA's in-house capabilities and the maintenance of NASA's core competencies, as well as cost and best overall value to NASA.

c. Identify the program's approach to creating Contractor incentives that strengthen safety and Mission assurance.

d. Describe how the program will establish and implement a continuous Risk-Based Acquisition Management (RBAM) process. (See Appendix A for definition.)

e. Describe all agreements, memoranda of understanding, barters, in-kind contributions, and other arrangements for collaborative and/or cooperative relationships. Include partnerships created through mechanisms other than those prescribed in the FAR. List all such agreements (the configuration control numbers and the date signed or projected dates of approval) necessary for program success. Include or reference all agreements concluded with the authority of the Program Manager and reference agreements concluded with the authority of the MDAA and above. Include the following:

(1 NASA agreements, e.g., space ;communications, launch services, inter-Center memoranda of agreement.

Describe the technology assessment, development, management, and acquisition strategies needed to achieve the program's mission objectives.

a. Describe how the program will assess its technology development requirements, including how the program will evaluate the feasibility, availability, readiness, cost, risk, and benefit of the new technologies.

b. Describe how the program will identify opportunities for leveraging ongoing technology efforts.

c. Describe the program's strategy for assuring that there are alternative development paths available if/when technologies do not mature as expected.

d. Describe how the program will remove technology gaps, including maturation, validation, and insertion plans, performance measurement at quantifiable milestones, decision gates, and resources required.

e. Describe briefly how the program will ensure that all planned Technology exchanges, contracts, and partnership agreements comply with all laws and regulations regarding export control and the transfer of sensitive and proprietary information.

f. Describe the program's technology utilization plan that meets the requirements of NPD 7500.2, NASA Technology Commercialization Policy, and NPR 7500.1, NASA Technology Commercialization Process.

Summarize the key elements of the program Systems Engineering Management Plan (SEMP). Include descriptions of the Program's overall approach for systems engineering, to include system design and product realization processes (implementation and/or integration, verification and validation, and transition), as well as the technical management processes.

For tightly coupled programs, develop a stand-alone SEMP that includes the content required by NPR 7123.1, NASA Systems Engineering Processes and Requirements. Reference the stand-alone Plan here.

Summarize the program's approach for conducting a continuum of reviews for the program life cycle, including peer reviews. In accordance with Center best practices, MD review requirements, and the requirements in NPR 7123.1, NASA Systems Engineering Processes and Requirements, provide the names, purposes, content, and timing of the critical milestone reviews.

Explain the reporting requirements for program reviews. Provide the technical, scientific, schedule, cost, and other criteria that will be utilized in the consideration of a Termination Review.

For tightly coupled programs that involve multiple Centers, document the program review requirements on the supporting projects that represent an integrated review process for the various projects and take into consideration the participating Centers' review process best practices.

This section is required only for tightly coupled and single-project programs. For those programs, describe the activities required to perform the mission. Describe how the program will implement the associated facilities, hardware, software, and procedures required to complete the mission. Describe mission operations plans, rules, and constraints. Describe the Mission Operations System (MOS) and Ground Data System (GDS) in the following terms:

b. Procedures to ensure that operations are conducted in a reliable, consistent, and controlled manner using lessons learned during the program and from previous programs.

c. Facilities requirements (offices, conference rooms, operations areas, simulators, and test beds).

d. Hardware (ground-based communications and computing hardware and associated documentation).

Describe the activities to be conducted to comply with NPR 8580.1, Implementing the National Environmental Policy Act and Executive Order 12114

Describe how the program will implement NPD 7500.1B, Program and Project Logistics Policy, including integrated logistics infrastructure for supply support, maintenance, test and support equipment, training, technical documentation, packaging, handling and transportation, and logistics information systems for the life of the program.

Describe how the program will manage the scientific data generated and captured by the operational mission(s) and any samples collected and returned for analysis. Include descriptions of how data will be generated, processed, distributed, analyzed, and archived, as well as how any samples will be collected, stored during the mission, and managed when returned to Earth. The Plan should include definition of data rights and services and access to samples, as appropriate. Explain how the program will accomplish the knowledge capture and information management and disposition requirements in NPD 2200.1, Management of NASA Scientific and Technical Information, NPR 2200.2B, Requirements for Documentation, Approval, and Dissemination of NASA Scientific and Technical Information, NPR 1441.1, Records Retention Schedules, as applicable to program science data.

State futher that the program will adhere to all NASA sample handling, curation, and planetary protection directives and rules, including NPR 8020.12C, Planetary Protection Provisions for Robotic Extraterrestrial Missions.

Describe the configuration management (CM) approach that the program team will implement, consistent with NPR 7123.1. Describe the structure of the CM organization and tools to be used. Describe the methods and procedures to be used for configuration identification, configuration control, interface management, configuration traceability, and configuration status accounting and communications. Describe how CM will be audited and how contractor CM processes will be integrated with the program. Reference the stand-alone program Configuration Management Plan, if applicable.

Describe how the program will manage information throughout its life cycle, including the development and maintenance of an electronic program library. Explain how the program will ensure identification, control, and disposition of program records in accordance with NPD 1440.6, NASA Records Management, and NPR 1441.1, Records Retention Schedules.

Describe the program's approach to knowledge capture, as well as the methods for contributing knowledge to other entities and systems, including compliance with NPD 2200.1, Management of NASA Scientific and Technical Information, and NPR 2200.2B, Requirements for Documentation, Approval, and Dissemination of NASA Scientific and Technical Information.

Describe the program's approach to capturing lessons learned in accordance with NPR 7120.6, Lessons Learned Process.

Describe the program's plans for ensuring security and technology protection, including:

a. Security Requirements: Describe the program' approach for planning and implementing the requirements for information, physical, personnel, industrial, and counterintelligence/counterterrorism security, and for security awareness/education requirements in accordance with NPR 1600.1, Security Program Procedural Requirements, and NPD 1600.2, NASA Security Policy. Include in the plan provisions to protect personnel, facilities, mission-essential infrastructure, and critical program information from potential threats and other vulnerabilities that may be identified during the threat and vulnerability assessment process.

b. Information Technology (IT) Security Requirements: Document the program's approach to implementing IT security requirements in accordance with NPR 2810.1, Security of Information Technology.

c. Emergency Response Requirements: Describe the program's emergency response plan in accordance with NPR 1040.1, NASA Continuity of Operations (COOP) Planning Procedural Requirements, and define the range and scope of potential crises and specific response actions, timing of notifications and actions, and responsibilities of key individuals.

Describe how the program will implement the export control requirements specified in NPR 2190.1, NASA Export Control Program.

Describe planned efforts and activities to improve science literacy by engaging the public in understanding the program, its objectives, and benefits. Summarize plans to develop education activities, services, and products that contribute to our Nation's efforts in achieving excellence in science, technology, engineering, and mathematics (STEM) education or to stimulate interest in STEM through program-related public outreach activities Specifically, address how planned efforts will:

a. Contribute to the development of the STEM workforce in disciplines needed to achieve NASA's strategic goals.

b. Attract and retain students in STEM disciplines through a progression of educational opportunities for students, teachers, and faculty.

c. Build strategic partnerships and linkages between STEM formal and informal education providers that promote STEM literacy and awareness of NASA's mission.

Summarize the plan to flow the Education and Public Outreach (EPO) requirements to projects within the program.

Identify NPR 7120.5D requirements for which a waiver has been requested and approved consistent with program characteristics such as scope, complexity, visibility, cost, safety, and acceptable risk, and provide rationale and approvals.

APPENDIX F. Project Plan Template

F.1 Template Instructions

The Project Plan is an agreement among the Project Manager, Program Manager, Center Director, and as required, the Mission Directorate Associate Administrator (MDAA). Other Center Directors providing a significant contribution to the project also concur with the Project Plan to document their commitment to provide required Center resources. It defines, at a high level, the scope of the project, the implementation approach, the environment within which the project operates, and the baseline commitments of the program and project. The Project Plan is consistent with the Program Plan. The Project Plan is updated and approved during the project life cycle in response to changes in program requirements on the project or the baseline commitments.

In this Project Plan template, all subordinate plans, collectively called Control Plans, are required. They are based on requirements in NASA Policy Directives (NPDs) and NASA Procedural Requirements (NPRs) that affect program/project planning. Certain Control Plans (the SMA Plan, Risk Management Plan, SEMP, and Software Management Plan) are required to be stand-alone plans with summaries and references provided in the Project Plan. The remaining Control Plans can either be part of the Project Plan or separate stand-alone documents referenced in the appropriate part of the Project Plan. In the case of the latter, the Project Plan contains a summary of and reference to the stand-alone document; the approval authority for the stand-alone Control Plan is the Project Manager.

Each section of the Project Plan template is required. If a section is not applicable to a particular project, indicate by stating that in the appropriate section and provide a rationale. If a section is applicable but the project desires to omit the section or parts of a section, then a waiver must be obtained in accordance with the waiver process for NPR 7120.5D. This waiver approval is documented in Part 4.0, Waivers Log, of the Project Plan.

F.2 Project Plan Title Page

F.3 Project Plan Template

Briefly describe the background of the project and its current status, including results of formulation activities, decisions, and documentation. Document the project's category and NASA payload development risk classification (see NPR 8705.4, Risk Classification for NASA Payloads) as stated in the program requirements on the project.

State the specific project objectives and high-level Performance goals levied on the project by the program. Include performance, schedule, cost, and Technology development objectives, as applicable.

Describe briefly the mission and the mission design. Include key characteristics of the mission, such as launch date(s), flight plans, and the key phases and events on the mission timeline, including end of mission. Use drawings, figures, charts, etc., for clarification. Describe planned mission results, data archiving, and reporting.

Provide a brief description of the technical approach, including constituent launch, flight, and ground systems, operations concepts, and logistics concepts. Describe the systems to be developed (hardware and software), legacy systems, system interfaces, and facilities. Identify major constraints affecting system development (e.g., cost, launch window, required launch vehicle, mission planetary environment, fuel/engine design, and international partners.)

1.4 PROJECT AUTHORITY, GOVERNANCE STRUCTURE, MANAGEMENT STRUCTURE AND IMPLEMENTATION APPROACH

Identify the Center where the Project Manager resides. Describe the governance structure based on the project category. Identify the governing PMC responsible for oversight of the project. Describe other Centers' responsibilities, if any. Describe the chain of accountability and decision path that outlines the roles and responsibilities of the Project Manager, Program Manager, Center Director, Principal Investigator, and Project Scientist (as appropriate), and other authorities as required per the project's categorization.

Define the relationships among various elements and organizations within the project structure, including all stakeholders, team members, and supporting organizations. Describe the project's approach for fostering effective upward and downward communication of critical management, technical, risk, and safety information. Describe the process that the project will follow to communicate with the CMC, Center Director, Program Manager, and governing PMC. Describe briefly the process for problem reporting and subsequent decision-making, clearly describing the roles and responsibilities of all organizations. Describe any use of special boards and committees.

Describe the project management structure consistent with the project WBS, including organization and responsibilities, its integration with the parent program management structure, and NASA Center(s) participation. Describe clear lines of authority within the project team and between the project, the program office, the primary Center, the MD, other participating Centers, and other participating organizations. Illustrate the organization graphically.

Describe briefly the implementation approach of the project, including the acquisition strategy (e.g., in-house, NASA Centers, and contractor primes), partners and partner contributions, if appropriate. Describe briefly other program/project dependencies with NASA, other U. S. Government agencies, and international activities, studies, and agreements. Include make-or-buy decision plans and trade studies.

Describe how participating NASA Centers' implementation policies and practices will be utilized in the execution of the project. Document the agreements on the use of implementation policies and practices between the Project Manager and contributing NASA Centers in this section (or in appendices to the document), along with the project's approach to ensuring that interfaces do not increase risk to mission success.

Describe the stakeholders of the project (e.g., PI, Science community, technology community, public, Education community, parent program, and Mission Directorate sponsor) and the process to be used within the project to ensure stakeholder advocacy.

List or reference the requirements levied on the project by the program in the Program Plan and discuss how these are flowed down to lower levels by summarizing the requirements allocation process. Reference requirements documents used by the project.

Provide the project's WBS and WBS dictionary to the Level 2 elements. (See Appendix G.)

Present a summary of the project's integrated master schedule (IMS), including all critical milestones, major events, and Agency and project-level reviews throughout the project life cycle. The summary schedule should include the logical relationships (interdependencies) for the critical milestones, major events, project reviews, and critical paths, as appropriate.

Present the project funding requirements by fiscal year. State the NOA in real-year dollars for all years - prior, current, and remaining. The funding requirements are to be consistent with the project WBS and include funding for all cost elements required by the Agency's full-cost accounting procedures. Provide a breakdown of the project's funding requirements to the WBS Level 2 elements. (See Appendix G.)

Present the project's workforce requirements by fiscal year, consistent with the project funding requirements and WBS. The workforce estimate is to encompass all work required to achieve project objectives. Include the actual full-cost civil service and support contractor workforce by providing organization for any prior fiscal years. Include full-cost civil service and support contractor workforce requirements by providing organization for the current fiscal year and remaining fiscal years.

Describe the project's 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.

Document how the project plans to control project requirements, technical design, schedule, and cost to achieve the program requirements on the project. (If this information is best documented in other control plans, e.g., the Systems Engineering Management Plan, then reference those control plans.) This control plan documents the following:

a. Describe the plan to monitor and control the project requirements, technical design, schedule, and cost of the project to assure the high-level requirements levied on the project are met.

b. Describe the project's performance measures in objective, quantifiable, and measurable terms and document how the measures are traced from the program requirements on the project. In addition, document the minimum mission success criteria associated with the program requirements on the project that, if not met, trigger consideration of a Termination Review.

c. Describe the project's implementation of Earned Value Management (EVM). The following requirements apply:

(1) The project's EVM approach is consistent with the participating Center's best practices.

(2) The Project's EVM approach is in-place by KDP C and implemented in Phase C through KDP E.

(4) As a minimum, EVM principles, as defined by ANSI/EIA-748, Earned Value Management Systems, apply from KDP C through KDP E, if the project's life-cycle cost is at or greater than $20M.

(5) If the project's primary NASA Center has a fully validated Earned Value Management System (EVMS), the project uses that system rather than EVM principles.

(6) For contracts and subcontracts, application of an EVMS is required as follows:

(i) For development or production (including flight and ground support) contracts and subcontracts valued at $20M or more, the contractor EVMS must comply with the guidelines in ANSI/EIA-748.

(ii) For development or production (including flight and ground support) contracts and subcontracts valued at $50M or more, the contractor EVMS has been formally determined compliant with ANSI/EIA-748 by the cognizant Federal contract management agency.

(iii) EVM is not required for grants, non-developmental level-of-effort engineering support services, steady-state operations, basic and applied research, and routine services such as janitorial services or grounds maintenance services; however, application is at the discretion of the Program/Project Manager.

(iv) A Contract Performance Report (CPR), Integrated Master Schedule (IMS), WBS, and WBS dictionary are required whenever EVM is required on contracts and subcontracts.

(v) In accordance with NFS Part 1834, require IBRs through Phase D for contracts requiring EVM. Schedule such reviews not later than 180 calendar days after contract award or the exercise of significant contract options, or not later than 60 calendar days after a significant funding or work scope realignment.

d. Describe any additional specific tools necessary to implement the Project's control processes (e.g., the requirements management system, project scheduling system, project information management systems, budgeting, and cost accounting system).

f. Describe the process for utilizing the project's technical, schedule, and cost reserves to control the baseline.

g. Describe how the project plans to report technical, schedule, and cost status to the Program Manager, including the frequency and level of detail of reporting.

h. Describe the project's internal processes for addressing technical waivers and handling dissenting opinions.

i. Describe the project's descope plans, including key decision dates and savings in cost and schedule and show how the descopes are related to the project's threshold performance requirements.

j. Include a description of the systems engineering organization and structure and how the Project Chief Engineer (PCE) executes the overall systems engineering functions.

Develop a project SMA Plan. The SMA Plan addresses life-cycle SMA functions and activities. The plan identifies and documents project-specific SMA roles, responsibilities, and relationships. This is accomplished through a project-unique mission assurance process map and matrix developed and maintained by the project with appropriate support and guidance of the Headquarters and/or Center- SMA organization.

The plan reflects a project life-cycle SMA process perspective, addressing areas including: procurement, management, design and engineering, design verification and test, software design, software verification and test, manufacturing, manufacturing verification and test, operations, and pre-flight verification and test.

The plan also addresses specific critical SMA disciplines, including (as a minimum): safety per NPR 8715.3, NASA Safety Manual, and NPR 8705.2, NASA Human Rating Requirements for Spaceflight Systems; quality assurance per NPD 8730.5, NASA Quality Assurance Program Policy; compliance verification, audit, safety and mission assurance reviews, and safety and mission assurance process maps per NPR 8705.6, Safety and Mission Assurance Audits, Reviews, and Assessments; reliability and maintainability per NPD 8720.1B, NASA Reliability and Maintainability (R&M) Program Policy; software safety and assurance per NASA-STD-8719.13, NASA Software Safety Standard, and NASA-STD-8739.8, NASA Software Assurance Standard; quality assurance functions per NPR 8735.2, Management of Government Quality Assurance Functions for NASA Contracts; and other applicable NASA procedural safety and mission success requirements.

Describe how the project will develop and manage a Closed Loop Problem Reporting and Resolution System. Describe how the project develops, tracks, and resolves problems. The process should include a well-defined data collection system and process for hardware and software problem and anomaly reports, problem analysis, and corrective action.

Summarize how the project will implement the NASA continuous Risk management process. Include the initial Significant Risk List and appropriate actions to mitigate each risk. Projects with international or other U.S. Government agency contributions must plan for, assess, and report on risks due to international or other government partners and plan for contingencies.

Develop a stand-alone Risk Management Plan that includes the content required by NPR 8000.4, Risk Management Procedural Requirements. Reference the stand-alone Plan here.

The Project Acquisition Plan is developed by the Project Manager, supported by the host Center's Procurement Officer, and must be consistent with the results of the ASP meeting and ASM. It documents an integrated acquisition strategy that enables the project to meet its mission objectives and provides the best value to NASA. In addition, the Acquisition Plan should:

a. Identify all major proposed acquisitions (such as engineering Design study, hardware and software development, and mission and data operations support) in relation to the project WBS. Provide summary information on each such proposed acquisition, including a Contract WBS; major deliverable items; type of procurement (competitive, AO for instruments); type of contract (cost-reimbursable, fixed-price); source (institutional, contractor, other U.S. Government organizations); procuring activity; and surveillance approach. Identify those major procurements that require a Procurement Strategy Meeting (PSM).

c. Identify the project's approach to creating Contractor incentives that strengthen safety and Mission assurance.

d. Describe how the project will establish and implement a continuous Risk-Based Acquisition Management (RBAM) process. (See Appendix A for definition.)

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

(1) NASA agreements, e.g., space communications, launch services, inter-Center memoranda of agreement.

Describe the technology assessment, development, management, and acquisition strategies needed to achieve the project's mission objectives.

a. Describe how the project will assess its technology development requirements, including how the project will evaluate the feasibility, availability, readiness, cost, risk, and benefit of the new technologies.

b. Describe how the project will identify opportunities for leveraging ongoing technology efforts.

c. Describe the project's strategy for assuring that there are alternative development paths available if/when technologies do not mature as expected.

d. Describe how the project will remove technology gaps, including maturation, validation, and insertion plans, performance measurement at quantifiable milestones, decision gates, and resources required.

e. Describe briefly how the project will ensure that all planned technology exchanges, contracts, and partnership agreements comply with all laws and regulations regarding export control and the transfer of sensitive and proprietary information.

Summarize the key elements of the project Systems Engineering Management Plan (SEMP). Include descriptions of the Project's overall approach for systems engineering to include system design and product realization processes (implementation and/or integration, verification and validation, and transition), as well as the technical management processes.

Develop a stand-alone SEMP that includes the content required by NPR 7123.1, NASA Systems Engineering Processes and Requirements. Reference the stand-alone Plan here.

Summarize how the project will develop and/or manage the acquisition of software required to achieve project and mission objectives.

Develop a stand-alone Software Management Plan that includes the content required by NPR 7150.2, Software Engineering Requirements, and NASA Standard 8739.8, Software Assurance Standard. The Plan should be coordinated with the Systems Engineering Management Plan. Reference the stand-alone Plan here.

SSummarize the project's approach for conducting a continuum of reviews for the project life cycle, including peer reviews. In accordance with Center best practices, program review requirements, and the requirements in NPR 7123.1, NASA Systems Engineering Processes and Requirements, provide the names, purposes, content, and timing of the critical milestone reviews.

Explain the reporting requirements for project reviews. Provide the technical, scientific, schedule, cost, and other criteria that will be utilized in the consideration of a Termination Review.

Describe the activities required to perform the mission. Describe how the project will implement the associated facilities, hardware, software, and procedures required to complete the mission. Describe mission operations plans, rules, and constraints. Describe the Mission Operations System (MOS) and Ground Data System (GDS) in the following terms:

b. Procedures to ensure that operations are conducted in a reliable, consistent, and controlled manner using lessons learned during the program and from previous programs.

c. Facilities requirements (offices, conference rooms, operations areas, simulators, and test beds).

d. Hardware (ground-based communications and computing hardware and associated documentation).

Describe the activities to be conducted with support from the cognizant Environmental Management Office (EMO) to comply with NPR 8580.1, Implementing the National Environmental Policy Act and Executive Order 12114. Specifically:

a. Identify all required permits, waivers, documents, approvals, or concurrences required for compliance with applicable Federal, State, Tribal Government, and local environmental regulations.

b. Describe the documentation and schedule of events for complying with these regulations, including identifying any modifications to the Center's Environmental Management System (EMS) that would be required for compliance.

c. Insert into the project schedule the critical milestones associated with complying with these regulations.

Describe how the project will implement NPD 7500.1B, Program and Project Logistics Policy, including integrated logistics infrastructure for supply support, maintenance, test and support equipment, training, technical documentation, packaging, handling and transportation, and logistics information systems for the life of the project.

Describe how the project will manage the scientific data generated and captured by the operational mission(s) and any samples collected and returned for analysis. Include descriptions of how data will be generated, processed, distributed, analyzed, and archived, as well as how any samples will be collected, stored during the mission, and managed when returned to Earth. The Plan should include definition of data rights and services and access to samples, as appropriate. Explain how the project will accomplish the knowledge capture and information management and disposition requirements in NPD 2200.1, Management of NASA Scientific and Technical Information, NPR 2200.2B, Requirements for Documentation, Approval, and Dissemination of NASA Scientific and Technical Information, NPR 1441.1, Records Retention Schedules, as applicable to project science data.

Describe the configuration management (CM) approach that the project team will implement, consistent with NPR 7123.1. Describe the structure of the CM organization and tools to be used. Describe the methods and procedures to be used for configuration identification, configuration control, interface management, configuration traceability, and configuration status accounting and communications. Describe how CM will be audited and how contractor CM processes will be integrated with the project. Reference the stand-alone project Configuration Management Plan, if applicable.

Describe how the project will manage information throughout its life cycle, including the development and maintenance of an electronic program library. Explain how the project will ensure identification, control, and disposition of project records in accordance with NPD 1440.6, NASA Records Management, and NPR 1441.1, Records Retention Schedules.

Describe the project's approach to knowledge capture, as well as the methods for contributing knowledge to other entities and systems, including compliance with NPD 2200.1, Management of NASA Scientific and Technical Information, and NPR 2200.2B, Requirements for Documentation, Approval, and Dissemination of NASA Scientific and Technical Information.

Describe the project's approach to capturing lessons learned in accordance with NPR 7120.6, Lessons Learned Process.

Describe the project's plans for ensuring security and technology protection, including:

a. Security Requirements: Describe the project's approach for planning and implementing the requirements for information, physical, personnel, industrial, and counterintelligence/ counterterrorism security and for security awareness/education requirements in accordance with NPR 1600.1, Security Program Procedural Requirements and NPD 1600.2, NASA Security Policy. Include in the plan provisions to protect personnel, facilities, mission-essential infrastructure, and critical project information from potential threats and other vulnerabilities that may be identified during the threat and vulnerability process.

b. Information Technology (IT) Security Requirements: Document the project's approach to implementing IT security requirements in accordance with NPR 2810.1, Security of Information Technology.

c. Emergency Response Requirements: Describe the project's emergency response plan in accordance with NPR 1040.1, NASA Continuity of Operations (COOP) Planning Procedural Requirements, and define the range and scope of potential crises and specific response actions, timing of notifications and actions, and responsibilities of key individuals.

Describe how the project will implement the export control requirements specified in NPR 2190.1, NASA Export Control Program.

Identify NPR 7120.5D requirements for which a waiver has been requested and approved consistent with project characteristics such as scope, complexity, visibility, cost, safety, and acceptable risk, and provide rationale and approvals.

APPENDIX G. Space Flight Project Work Breakdown Structure (WBS)

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

G.2.1 The WBS standard elements defined in this appendix are only applicable to space flight projects.

G.2.2 The following list of assumptions is provided as background information to assist in the development of the project WBS:

a. The CADRe captures major assembly (one level lower than subsystem) actuals at major milestones (PDR, CDR, etc.).

G.3.1 Purpose: The standardization of WBS elements for space flight projects is being driven by requirements for more effective cost estimating and consistency of project work packages across the Agency. The standard WBS is intended to apply to projects, not programs. There are no program WBS standard requirements due to the variance in structure of the Mission Directorates.

a. The standard space flight project WBS applies to new projects established from June 1, 2005, forward. It is not intended to be applied retroactively to existing projects.

b. The standard space flight project WBS applies to the entire life cycle of the project, including disposal and decommissioning.

c. The standard space flight project WBS applies to both crewed and robotic projects.

d. Space flight projects will use the standard Level 1/2 WBS elements (See Section G.5.). Specifically:

(2) The title of each WBS Level 2 element can be modified to facilitate project-unique titles, but the content of each must remain the same. If the linkage of the project-unique title to the standard title is not intuitive, the project-unique title is cross-referenced to the standard.

(3) If the set of standard WBS Level 2 elements does not comprise an exhaustive set of WBS elements, additional WBS elements may be added horizontally (i.e., at Level 2) as long as their content does not fit into the content of any existing standard WBS elements.

(4) For each standard WBS Level 2 element, the subordinate (children) WBS elements at Level 3 and lower will be determined by the project.

(5) The Level 3 and lower elements can differ from project to project but will include only work that rolls up to the standard WBS Dictionary definition of the Level 2 element. (See Section G.5.)

(6) If there is no work to fit into a standard WBS element, then an inactive placeholder element (and an inactive placeholder financial code) will be established.

(7) A single WBS will be used for both technical/business management and reporting.

(8) The management assigned to each WBS element may differ from project to project.

e. Changes to the standard space flight project WBS will be governed by the waiver approval process in Chapter 3 of this document.

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

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

Element 2 - Systems Engineering: The technical and management efforts of directing and controlling an integrated engineering effort for the project. This element includes the efforts to define the project space flight vehicle(s) and ground system, conducting trade studies, the integrated planning and control of the technical program efforts of design engineering, software engineering, specialty engineering, system architecture development and integrated test planning, system requirements writing, configuration control, technical oversight, control and monitoring of the technical program, and risk management activities. Documentation products include requirements documents, interface control documents (ICDs), Risk Management Plan, and master verification and validation (V&V) plan. Excludes any design engineering costs.

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

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

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

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

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

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

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

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

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

APPENDIX H. References

NASA programs/projects and Centers are required to comply with all applicable Agency directives, not limited to those listed in this Appendix. The directives listed in Section H.1 are those cited in this document. Applicable directives not cited in this document should be identified in Center policies and procedures.

Similarly, not all related references or other resources for program/project management teams are identified. The related references listed in Section H.2 are those cited in this document.

(4) NPR 1040.1, NASA Continuity of Operations (COOP) Planning Procedural Requirements

(11) NPR 2200.2B, Requirements for Documentation, Approval, and Dissemination of NASA Scientific and Technical Information

(23) NPD 8010.3, Notification of Intent to Decommission or Terminate Operating Space Missions and Terminate Missions

(24) NPD 8020.7, Biological Contamination Control for Outbound and Inbound Planetary Spacecraft

(25) NPR 8020.12, Planetary Protection Provisions for Robotic Extraterrestrial Missions

(26) NPR 8580.1, Implementing the National Environmental Policy Act and Executive Order 12114

(27) NPD 8610.7, Launch Services Risk Mitigation Policy for NASA-Owned and/or NASA-Sponsored Payloads/Missions

(28) NPD 8610.12, Office of Space Operations (OSO) Space Transportation Services for NASA and NASA-Sponsored Payloads

(36) NPR 8735.2, Management of Government Quality Assurance Functions for NASA Contracts

(37) NASA Safety Standard 1740.14, Guidelines and Assessment Procedures for Limiting Orbital Debris

(39) NASA Standard 8719.8, Expendable Launch Vehicle Payload Safety Review Process

(2) Air Force Space Command Manual 91-710, Range Safety User Requirements, Vol. 3

APPENDIX I. Index

Announcement of Opportunity ……………………………………………………………………. 19, 47

Approval (for Implementation) ……………………………………………………………... 9, 16, 20, 61

CADRe ……………………………………………………………………………………. 48, 51, 54, 57, 62

Categorization, project ………………………………………………………………………………. 12-13

Center Management Council ………………………………………………………………………. 22, 62

Control plans, program ………………………………………………………………………………..... 44

Control plans, project …………………………………………………………………………………… 60

Decision Authority ………………………………………………………………………………. 21-24, 62

Earned Value Management ……………………………………………………………………. 62, 99-100

Evaluation ……………………………………………………………………………………………... 9, 63

Formulation ……………………………………………………………………………….… 8-9, 16, 20, 63

FAD ……………………………………………………………………………………….. 17, 19, 63, 74-76

Gate products, program ………………………………………………………………………………… 43

Gate products, project …………………………………………………………………………………... 59

Implementation …………………………………………………………………………….…. 9, 16, 20, 63

Implementation Plan, Center …………………………………………………………………………... 39

Independent Cost Analysis ………………………………...…………………………………… 25, 63-64

Independent Cost Estimate ………………………………………………………………………… 25, 64

Integrated Baseline ……………………………………………………………………...…… 48-49, 52, 64

Key Decision Points ……………………………………………………………………... 16, 20, 23-24, 64

Life cycle, program ………………………………………………………………………………….. 15-18

Life cycle, project ……………………………………………………………………………………. 18-21

Life cycle cost estimate …………………………………………………..……………………... 12-13, 64

Loosely coupled program ……………………………………………………………………………… 12

Phases, program …………………………………………………………………………………. 16, 42-46

Phases, project …………………………………………………………………………………… 20, 46-58

Program ……………………………………………………………………………………………… 11, 66

PCA ………………………………………………………………………………………………... 17, 77-80

PMC …………………………………………………………………………………………….………21-22

Program Plan ………………………………………………………………………………17-18, 66, 81-93

Project ………………………………………………………………………………………………… 11, 66

Project Plan ………………………………………………………………………………….. 21, 66, 94-105

Reviews, internal …………………………………………………………………………………….. 24, 27

Reviews, independent life cycle ……………………………………………………………. 24, 27, 30-31

Reviews, special …………………………………………………………………………………………. 28

Reimbursable project ……………………………………………………………………..………39-40, 66

Roles and responsibilities …………………………………………………………………………… 32-35

Single-project program …………………………………………………………………………………. 12

SRB ………………………………………………………………………………………………… 24-27, 67

Technical Authority ……………………………………………………………………………... 36-39, 67

Termination Review ………………………………………………………………………………… 28, 67

Tightly coupled program ………………………………………………………………………………. 12

Uncoupled program …………………………………………………………………………………….. 12

Waivers …………………………………………………………………………………………… 37, 40, 68

WBS …………………………………………………………………………………….. 48, 52, 68, 107-111

		Decision Authority		Technical Authority		Associate Administrator, PA&E
		NASA AA	MDAA	NASA CE	Center Director	Associate Administrator, PA&E
Establish SRB, Develop ToR. Approve Chairperson, RM, and Other Board Members	Programs	Approve	Approve	Approve		Approve
	Category 1 Projects	Approve	Approve	Concur	Approve	Approve
	Category 2 Projects		Approve		Approve	Approve*
	Category 3 Projects		Approve		Approve

Review	Description
Acquisition Strategy Planning (ASP) Meeting*	The ASP meeting is integral to the annual budget submission process. The ASP meeting is structured to allow Agency senior management to review major acquisitions that evolve from Needs, Goals, and Objectives, as well as requirements introduced to the Agency from external sources (e.g., The President's Vision for Space Exploration) and internal sources (e.g., major acquisitions initiated by MDs/MSOs). The purpose of the ASP meeting is to identify and define roles and responsibilities of Mission Directorate(s), Centers, major partnerships, and associated infrastructure (workforce and facilities) with the focus on maintaining ten healthy Centers.
Acquisition Strategy Meeting (ASM)*	The ASM applies to both programs and projects. The ASM should be convened as early as practicable and prior to partnership commitments. The purpose of an ASM is to obtain senior management approval of acquisition strategy (e.g., make-or-buy, Center assignments, and targeted partners) for programs and projects. The ASM meeting also delineates if a Procurement Strategy Meeting (PSM) is required for each acquisition under consideration. The Program ASM may be held in conjunction with the Program/System Requirements Review (P/SRR) but must be held prior to KDP I. The Project ASM may be held in conjunction with the project SRR, but must be held prior to KDP B. The supporting materials for the ASM include appropriate program/project documentation that covers budget, schedule, requirements, and risk.

Review	Description
Program/System Requirements Review (P/SRR)/ Preliminary Program Approval Review (PPAR)	The P/SRR examines the functional and performance requirements defined for the program (and its constituent projects) and ensures that the requirements and the selected concept will satisfy the program and higher-level requirements. It is an internal review. (The SRB may not have been formed.) ROM budgets and schedules are presented. The PPAR is conducted (when requested by the DA) as part of this review to ensure that major issues are understood and resolved early and to provide Agency management with an independent assessment of the readiness of the program to continue with formulation.
Program/System Definition Review (P/SDR)/Program Approval Review (PAR)	The P/SDR examines the proposed program architecture and the flow down to the functional elements of the system. The PAR is conducted as part of this review to provide Agency management with an independent assessment of the readiness of the program to proceed into implementation. The proposed program's objectives and the concept for meeting those objectives are assessed. Key technologies and other risks are identified and assessed. The baseline Program Plan, budgets, and schedules are presented.
Program Status Review (PSR)/ Program Implementation Review (PIR)	PSRs are conducted by the program to examine the program's continuing relevance to the Agency's Strategic Plan, the progress to date against the approved baseline, the implementation plans for current and upcoming work, budget, schedule, and all risks and their mitigation plans. PIRs are conducted as part of this review to provide Agency management with an independent assessment of the readiness of the program to continue with implementation.
Preliminary Design Review (PDR)	The PDR demonstrates that the overall program preliminary design meets all require- ments with acceptable risk and within the cost and schedule constraints and establishes the basis for proceeding with detailed design. It shows that the correct design options have been selected, interfaces have been identified, and verification methods have been described. Full baseline cost and schedules, as well as all risk assessment, management systems, and metrics are presented.
Critical Design Review (CDR)	The CDR demonstrates that the maturity of the program's design is appropriate to support proceeding full-scale fabrication, assembly, integration, and test and that the technical effort is on track to complete the flight and ground system development and mission operations in order to meet overall performance requirements within the identified cost and schedule constraints. Progress against management plans, budget, and schedule, as well as risk assessment, are presented.
System Integration Review (SIR)	The SIR evaluates the readiness of the overall system (all projects working together) to commence integration and test. V&V plans, integration plans, and test plans are reviewed. Test articles (hardware/software), test facilities, support personnel, and test procedures are ready for testing and data acquisition, reduction, and control.
Operations Readiness Review (ORR)	The ORR examines the actual overall system (all projects working together) character-istics and the procedures used in the system or product's operation and ensures that all project and support (flight and ground) hardware, software, personnel, and procedures are ready for operations and that user documentation accurately reflects the deployed state of the entire system.
Safety and Mission Success Review (SMSR)*	SMSRs are conducted prior to launch or other mission critical events/activities by the Chief SMA Officer and Chief Engineer (or senior Center-based SMA and engineering officials) to prepare for SMA and engineering participation in critical program/project reviews/decision forums. The SMA lead and lead PCE are the focal points for planning, coordinating, and providing the program/project elements of these reviews.
Flight Readiness Review (FRR)	The FRR examines tests, demonstrations, analyses, and audits that determine the overall system (all projects working together) readiness for a safe and successful flight/launch and for subsequent flight operations. It also ensures that all flight and ground hardware, software, personnel, and procedures are operationally ready.
Launch Readiness Review (LRR)	Final review prior to actual launch in order to verify that Launch System and Spacecraft/Payloads are ready for launch.
Post-Launch Assessment Review (PLAR)	Assessment of system in-flight performance. For human space flight, the PLAR is performed by the Mission Management Team (MMT).
Critical Events Readiness Review (CERR)	Review to confirm readiness to execute a critical event during flight operations. For human space flight, the CERR is performed by the Mission Management Team (MMT).

Review	Description
Mission Concept Review (MCR)	The MCR affirms the mission need and examines the proposed mission's objectives and the concept for meeting those objectives. Key technologies are identified and assessed. It is an internal review that usually occurs at the cognizant system development organization. (The SRB may not have been formed.) ROM budget and schedules are presented.
System Requirements Review (SRR)	The SRR examines the functional and performance requirements defined for the system and the preliminary Program or Project Plan and ensures that the requirements and the selected concept will satisfy the mission.
Mission Definition Review (MDR) or System Definition Review (SDR)/ Preliminary Non-Advocate Review (PNAR)	The MDR (or SDR) examines the proposed requirements, the mission/system architecture, and the flow down to all functional elements of the system. The PNAR is conducted as part of this review to provide Agency management with an independent assessment of the readiness of the project to proceed to Phase B.
Preliminary Design Review (PDR)/ Non-Advocate Review (NAR)	The PDR demonstrates that the preliminary design meets all system requirements with acceptable risk and within the cost and schedule constraints and establishes the basis for proceeding with detailed design. It shows that the correct design option has been selected, interfaces have been identified, and verification methods have been described. Full baseline cost and schedules, as well as risk assessments, management systems, and metrics are presented. The NAR is conducted as part of this review to provide Agency management with an independent assessment of the readiness of the project to proceed to implementation.
Critical Design Review (CDR)	The CDR demonstrates that the maturity of the design is appropriate to support proceeding with full scale fabrication, assembly, integration, and test, and that the technical effort is on track to complete the flight and ground system development and mission operations in order to meet mission performance requirements within the identified cost and schedule constraints. Progress against management plans, budget, and schedule, as well as risk assessments are presented.
Production Readiness Review (PRR)	The PRR is held for projects developing or acquiring multiple similar or identical flight and/or ground support systems. The purpose of the PRR is to determine the readiness of the system developer(s) to efficiently produce (build, integrate, test, and launch) the required number of systems. The PRR also evaluates how well the production plans address the system's operational support requirements.
System Integration Review (SIR)	The SIR evaluates the readiness of the project to start flight system assembly, test, and launch operations. V&V plans, integration plans, and test plans are reviewed. Test articles (hardware/software), test facilities, support personnel, and test procedures are ready for testing and data acquisition, reduction, and control.
System Acceptance Review (SAR)	The SAR verifies the completeness of the specific end item with respect to the expected maturity level and to assess compliance to stakeholder expectations. The SAR examines the system, its end items and documentation, and test data and analyses that support verification. It also ensures that the system has sufficient technical maturity to authorize its shipment to the designated operational facility or launch site.
Operations Readiness Review (ORR)	The ORR examines the actual system characteristics and the procedures used in the system or product's operation and ensures that all system and support (flight and ground) hardware, software, personnel, and procedures are ready for operations and that user documentation accurately reflects the deployed state of the system.
Safety and Mission Success Review (SMSR)*	SMSRs are conducted prior to launch or other mission-critical events/activities by the Chief SMA Officer and Chief Engineer (or senior Center-based SMA and engineering officials) to prepare for SMA and engineering participation in critical program/project reviews/decision forums. The SMA lead and lead PCE are the focal points for planning, coordinating, and providing the program/project elements of these reviews.
Flight Readiness Review (FRR)	The FRR examines tests, demonstrations, analyses, and audits that determine the system's readiness for a safe and successful flight/launch and for subsequent flight operations. It also ensures that all flight and ground hardware, software, personnel, and procedures are operationally ready.
Launch Readiness Review (LRR) (Launch Vehicle)	Final review prior to actual launch in order to verify that Launch System and Spacecraft/Payloads are ready for launch.
Post-Launch Assessment Review (PLAR)	Assessment of system in-flight performance. For human space flight, the PLAR is performed by the Mission Management Team (MMT).
Critical Event Readiness Review (CERR)	Review to confirm readiness to execute a critical event during flight operations. For human space flight, the CERR is performed by the Mission Management Team (MMT).
Post-Flight Assessment Review (PFAR)	The PFAR is a human space flight review that occurs after a flight mission in order to assess whether mission objectives were met and the status of the returned vehicle.
Decommissioning Review (DR)	The purpose of the DR is to confirm the decision to terminate or decommission the system and assess the readiness for the safe decommissioning and disposal of system assets.

	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

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.5D Effective Date: March 06, 2007 Cancellation Date: March 12, 2007 Responsible Office: KA

NASA Space Flight Program and Project Management Requirements

SPECIAL ATTENTION: ONLY USE NID 7120-97: NASA Space Flight Program and Project Management Requirements, as it is the interim directive to NPR 7120.5D and contains the most recent requirements. !DO NOT USE OTHER LINKS ON THIS PAGE!

Table of Contents

Preface

P.1 PURPOSE