Procedural
Requirements
Effective Date: August 03, 2021
Expiration Date: August 03, 2026
|
|
NASA Procedural Requirements |
NPR 7120.5F Effective Date: August 03, 2021 Expiration Date: August 03, 2026 |
| | TOC | ChangeHistory | Preface | Chapter1 | Chapter2 | Chapter3 | AppendixA | AppendixB | | AppendixC | AppendixD | AppendixE | AppendixF | AppendixG | AppendixH | AppendixI | AppendixJ | ALL | |
H.1.1 The Project Plan is an agreement among the project manager, program manager, Center Director, and 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.
H.1.2 In this Project Plan template, all subordinate plans, collectively called control plans, are required unless they are not applicable or are marked as “Best Practice” in the applicable table in Appendix I (i.e., I-Table). (The expectation is that products marked as “Best Practice” will be developed per the I-Table as part of normal project management activities.) They are based on requirements in NASA Policy Directives (NPDs) and NASA Procedural Requirements (NPRs) that affect program/project planning. If a control plan is not applicable to a particular project, indicate that by stating it is not applicable in the appropriate section and provide a rationale. Control plans can either be a part of the Project Plan or separate stand-alone documents referenced in the appropriate part of the Project Plan. Considerations for determining if a control plan should be a stand-alone document include a requirement that the control plan be stand-alone in the NPR that requires the control plan; differences between when the control plan is baselined and when the Project Plan is baselined; how frequently the control plan will be updated since updates to the Project Plan require signatures; and how long the control plan is. When the control plan is a stand-alone document, the Project Plan contains a reference to the stand-alone document.
H.1.3 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 or deviation needs to be obtained in accordance with the requirement tailoring process for
NPR 7120.5. If the format of the completed Project Plan differs from this template, a cross-reference table indicating where the information for each template paragraph is needs to be provided with the document when it is submitted for MDAA signature. Approvals are documented in Part 4.0, Waivers or Deviations Log, of the Project Plan. In addition, the project’s Compliance Matrix for this NPR is attached to the Project Plan.
H.1.4 The approval signatures of the MDAA, the Center Director, program manager, and project manager certify that the Project Plan implements all the Agency’s applicable institutional requirements or that the authority responsible for those requirements (e.g., Safety and Mission Assurance) have agreed to the modification of those requirements contained in the Project Plan.
H.1.5 Single-project programs may combine the Program and Project Plans into a single document if the MDAA agrees.
H.2 Project Plan Title Page
[Project Name] PROJECT PLAN
[short title or acronym]
1.0 PROJECT OVERVIEW
1.1 Introduction
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.
Specify if there are plans for continuing operations and production, including integration of capability upgrades, with an unspecified Phase E end point.
1.2 Objectives
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. Identify program requirements and constraints on the project. Provide clear traceability to applicable Agency strategic goals.
1.3 Mission Description and Technical Approach
Describe briefly the mission and the mission design. Include mission objectives and goals, mission success criteria, and driving ground rules and assumptions affecting the mission and mission design. Identify 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. For projects that plan continuing operations and production, including integration of capability upgrades, with an unspecified Phase E end point, define the scope of the initial capability. 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 driving technical ground rules and assumptions, and major constraints affecting system development (e.g., cost, launch window, required launch vehicle, mission planetary environment, fuel/engine design, human systems integration, and international partners).
1.4 Project Authority, Governance Structure, Management Structure, and Implementation Approach
Describe the governance structure based on the project category. Specifically identify the Decision Authority and governing PMC responsible for oversight of the project and any delegated Decision Authority and delegated governing PMC, per Section 2.3 of NPR 7120.5, NASA Space Flight Program and Project Management Requirements.
Identify the Center where the project manager resides. 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. (This includes Technical Authorities.) Describe the project’s approach for fostering effective upward and downward communication of critical management, technical, risk, and safety information. (This includes the Formal Dissent process.) Describe the process that the project will follow to communicate with the Center Management Council (CMC) and the Integrated Center Management Council (ICMC) if applicable. 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 Work Breakdown Structure (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 Mission Directorate, other participating Centers, and other participating organizations. Illustrate the organization graphically.
Describe briefly the implementation approach of the project, including any applicable guidance or direction from the Acquisition Strategy Meeting (ASM) review, the acquisition strategy (e.g., in-house, NASA Centers, and contractor primes), partners, and partner contributions, including acquisition approaches such as commercial or other partners that will develop end products that are not owned by NASA but are provided as services to NASA, 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.
Identify and document concurrence for any investments, divestments, acquisition strategies, procurements, agreements, and changes to capability portfolio capability components in accordance with requirements and strategic guidance included in NPR 8600.1, NASA Capability Portfolio Management Requirements. (See Appendix A for definitions of capability portfolio and capability component.)
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.
1.5 Stakeholder Definition
Describe the stakeholders of the project (e.g., principal investigator (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.
2.0 PROJECT BASELINES
Project baselines consist of a set of requirements, cost (including project-held UFE), schedule, and technical content that forms the foundation for program/project execution and reporting done as part of NASA’s performance assessment and governance process. (For more detail, see
NPR 7120.5, Section 2.4, on baseline policy and documentation.)
2.1 Requirements Baseline
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.
2.2 WBS Baseline
Provide the project’s WBS and WBS dictionary to the Level 2 elements in accordance with the standard template below and guidance provided by the NASA Work Breakdown Structure (WBS) Handbook, NASA/SP-2010-3404, which can be found on the OCE tab under the “Other NASA-Level Documents” menu in NODIS. The WBS will support cost and schedule allocation down to a work package level; integrate both government and contracted work; integrate well with the EVMS approach; allow for unambiguous cost reporting; and be designed to allow project managers to monitor and control work package/product deliverable costs and schedule.
Figure H-2 Standard Level 2 WBS Elements for Space Flight Projects
2.3 Schedule Baseline
Present a summary of the project’s IMS, including all critical milestones, major events, life-cycle reviews, and KDPs throughout the project life cycle. The summary of the master schedule should include the logical relationships (interdependencies) for the various project elements and critical paths, as appropriate. Identify driving ground rules, assumptions, and constraints affecting the schedule baseline.
2.4 Resource
Present the project funding requirements by fiscal year. State the New Obligation Authority (NOA) in real-year dollars for all years—prior, current, and remaining. The funding requirements are to be consistent with the 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. Throughout the Implementation Phase, cost and schedule baselines are to be based on and maintained consistent with the approved joint cost and schedule confidence level, as applicable, in accordance with NPD 1000.5 and NPR 7120.5.
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 the organizations providing them for any prior fiscal years. Include full-cost civil service and support contractor workforce requirements by the organizations providing them 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.
Identify driving ground rules, assumptions, and constraints affecting the resource baseline.
2.5 Joint Cost and Schedule Confidence Level
For projects with an estimated life-cycle cost (LCC) initial capability cost greater than $250M, document the project’s joint cost and schedule confidence level approved by the Decision Authority (DA) at KDP C. For projects with an estimated life-cycle cost greater than or equal to $1B, update the joint cost and schedule confidence level at CDR and at KDP D (if applicable).
3.0 PROJECT CONTROL PLANS
3.1 Technical, Schedule, and Cost Control Plan
This control plan documents the following:
Describe the plan to monitor and control the project requirements, technical design, schedule, and cost of the project to ensure that the high-level requirements levied on the project are met. (If this information is best documented in other control plans (e.g., the Systems Engineering Management Plan) then reference those control plans.)
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.
The project also develops and maintains the status of a set of programmatic and technical leading indicators to ensure proper progress and management of the project. Status and trend of leading indicators should be presented at LCRs and KDPs. These leading indicators include:
• Requirement Trends (percent growth, TBD/TBR closures, number of requirement changes).
These indicators are further explained in the NASA Space Flight Program and Project Management Handbook, NASA/SP-20220009501; the NASA Project Planning and Control Handbook, NASA/SP-2016-3424; and the NASA Common Leading Indicators Detailed Reference Guide at https://nodis3.gsfc.nasa.gov/OCE_rep/OCE_list.cfm.
Describe the approach to monitor and control the project's Agency Baseline Commitment (ABC). Describe how the project will periodically report performance. Describe mitigation approach if the project is exceeding the development cost documented in the ABC to take corrective action prior to triggering the 30 percent breach threshold. Describe how the project will support a rebaseline review in the event the Decision Authority directs one.
Describe the project’s implementation of Technical Authority (Engineering, Health and Medical, and Safety and Mission Assurance).
Describe how the project will implement the SI and other systems of measurement and the identification of units of measure in all product documentation. Where full implementation of the SI system of measurement is not practical, hybrid configurations (i.e., a controlled mix of SI and non-SI system elements) may be used to support maximum practical use of SI units for design, development, and operations. Where hybrid configurations are used, describe the specific requirements established to control interfaces between elements using different measurement systems. (See NPR 7120.5, Section 3.7, for SI assessment timing requirement.)
Describe the project’s implementation of Earned Value Management (EVM) including:
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).
Describe the process for monitoring and controlling the IMS.
Describe the process for utilizing the project’s technical and schedule margins and UFE to meet the Management and Commitment Baselines.
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.
Describe the project’s internal processes for addressing technical waivers and deviations and handling Formal Dissents.
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.
Include a description of the systems engineering organization and structure and how the Project Chief Engineer (PCE) executes the overall systems engineering functions.
3.2 Safety and Mission Assurance Plan
Develop a project Safety and Mission Assurance (SMA) Plan as required by NPR 8705.2, Human-Rating Requirements for Space Systems for crewed missions and NPR 8705.4, Risk Classification for NASA Payloads for un-crewed missions and payloads.
The SMA Plan reflects a project life-cycle SMA process perspective, addressing areas including: SMA domain management and SMA domain integration (e.g., for safety, reliability, maintainability, quality, planetary protection, etc.) with other engineering and management functions (e.g., concept and design trade-studies, risk analysis and risk assessments, risk-informed decision making, fault tolerance and contingency planning, knowledge capture, hardware and software design assurance, supply chain risk management and procurement, hardware and software design verification and test, manufacturing process design and control, manufacturing and product quality assurance, system verification and test, pre-flight verification and test, operations, maintenance, logistics planning, maintainability and sustainability, operational reliability and availability, decommissioning, and disposal).
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 problems and anomaly reports, problem analysis, and corrective action.
Identify the project’s approach to flow down requirements as appropriate to external developers and suppliers in acquisitions (e.g., contracts and purchase orders).
Describe how the project will develop, evaluate, and report indications of SMA program maturity and effectiveness at life cycle or other executive reviews, including through the use of metrics and indicators that are not otherwise included in formal life-cycle review deliverables or are not elements of the certification of flight readiness (COFR) process (e.g., satisfactory progress towards human rating).
3.3 Risk Management Plan
Develop a Risk Management Plan that includes the content required by NPR 8000.4, Agency Risk Management Procedural Requirements. Summarize how the project will implement a risk management process (including risk-informed decision making (RIDM) and continuous risk management (CRM) in accordance with NPR 8000.4, Agency Risk Management Procedural Requirements). Include the initial Significant Risk List and appropriate actions to mitigate each risk. Projects with international or other U.S. Government agency contributions need to plan for, assess, and report on risks due to international or other government partners and plan for contingencies.
3.4 Acquisition Strategy
The project Acquisition Strategy is developed by the project manager, supported by the host Center’s Procurement Officer, and needs to be consistent with NPD 1000.5, Policy for NASA Acquisition, the results of the Agency strategic acquisition process, and the ASM. It documents an integrated acquisition strategy that enables the project to meet its mission objectives and provides the best value to NASA. The Acquisition Strategy should include, but is not limited to, the following:
Identify all major proposed acquisitions (such as engineering design study, hardware and software development, mission and data operations support, and sustainment) in relation to the project WBS. Provide summary information on each such proposed acquisition, including a Contract WBS; major deliverable items; recommended 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 PSM.
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.
Describe the supply chain and identify potential critical and single-source suppliers needed to design, develop, produce, support, and, if appropriate, restart an acquisition program or project. The acquisition strategy should promote sufficient program/project stability to encourage industry to invest, plan, and bear their share of risk. Describe the internal and external mechanisms and procedures used to identify, monitor, and mitigate supply chain risks. Include data reporting relationships to allow continuous surveillance of the supply chain that provides for timely notification and mitigation of potential risks. Describe the process for reporting supply chain risks to the program.
Identify the project’s approach to strengthen safety and mission assurance in contracts.
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 and NFS. List all such agreements (the configuration control numbers, the date signed or projected dates of approval, and associated record requirements) 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, and inter-Center memoranda of agreement).
(2) Non-NASA agreements:
(a) Domestic (e.g., U.S. Government agencies).
(b) International (e.g., memoranda of understanding).
Describe intellectual property considerations and goals for advanced technologies to protect core NASA interests during the project life cycle; the process for respecting and protecting privately developed intellectual property; the process for ensuring acquisition strategies, proposals, and contract awards reflect intellectual property considerations established for the project; the approach for ensuring that the intellectual property strategy promotes competition for post-production sustainment/modernization contracts; the approach for seeking flexible and creative solutions to intellectual property issues that meet the desires of the parties and reflect NASA’s investment; the approach for ensuring procurement contracts specify both (1) the delivery of necessary technical data and computer software and (2) the license rights necessary for technical data and computer software; and the approach for ensuring the delivery of technical data and computer software under procurement contracts is marked in accordance with the contract at the time of delivery.
3.5 Technology Development Plan
Describe the technology assessment, development, management, and acquisition strategies (including intellectual property considerations) needed to achieve the project’s mission objectives.
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. The approach should include timely reporting of new technologies to the Center Technology Transfer Office and supporting technology transfer activities as described in NPR 7500.2, NASA Technology Transfer Requirements.
Describe how the project will identify opportunities for leveraging on-going technology efforts.
Describe how the project will transition technologies from the development stage to the manufacturing and production phases. Identify the supply chain needed to manufacture the technology and any costs and risks associated with the transition to the manufacturing and production phases. Develop and document appropriate mitigation plans for the identified risks.
Describe the project’s strategy for ensuring that there are alternative development paths available if/when technologies do not mature as expected. (Refer to NPR 7123.1 for TRL definitions and SP-20205003605, Technology Readiness Assessment Best Practices Guide. The Technology Readiness Assessment Best Practices Guide can be found in NODIS on the OCE tab under the “Other NASA-Level Documents” menu.)
Describe how the project will remove technology gaps, including maturation, validation, and insertion plans, performance measurement at quantifiable milestones, off-ramp decision gates, and resources required.
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.
Describe how the project will transition technologies from the development stage to manufacturing, production, and insertion into the end system. Identify any potential costs and risks associated with the transition to manufacturing, production, and insertion. Develop and document appropriate mitigation plans for the identified risks.
3.6 Systems Engineering Management Plan
Develop a SEMP that includes the content required by NPR 7123.1, NASA Systems Engineering Processes and Requirements. 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.
3.7 System Security Plan
Identify and prepare a System Security Plan for each information system. The System Security Plan is a formal document that provides an overview of the security requirements for an information system and describes the security controls in place or planned for meeting those requirements.
System Security Plans are generated and stored within the NASA Risk Information and Security Compliance System (RISCS) at https://riscs-info.nasa.gov/. Multiple systems may be covered under a single System Security Plan. Controls selected within the System Security Plan are included as system requirements for the system or systems covered by the plan.
Document the project's approach to implementing cybersecurity requirements in accordance with NPR 2810.1, Security of Information and Information Systems, if there are requirements outside the scope of the System Security Plan(s).
3.8 Software Management Plan
Develop a Software Management Plan that includes the content required by NPR 7150.2, Software Engineering Requirements. Additional information on the plan can be found in NASA-STD-8739.8, Software Assurance and Software Safety Standard. Summarize how the project will develop and/or manage the acquisition of software required to achieve project and mission objectives. The Software Management Plan should be coordinated with the Systems Engineering Management Plan.
3.9 Verification and Validation Plan
Summarize the approach for performing verification and validation of the project products. Indicate the methodology to be used in the verification/validation (test, analysis, inspection, or demonstration), as defined in NPR 7123.1, NASA Systems Engineering Processes and Requirements.
3.10 Review Plan
Summarize the project’s approach for conducting a series of reviews, including internal reviews and project life-cycle reviews. In accordance with Center best practices, program review requirements, and the requirements in NPR 7123.1, NASA Systems Engineering Processes and Requirements and NPR 7120.5, NASA Space Flight Program and Project Management Requirements, provide the names, purposes, content, and timing of the life-cycle reviews.
Identify any deviations from these documents that the project is planning or waivers that have been granted, including tailoring to accommodate aspects of acquisition strategies. Provide the technical, scientific, schedule, cost, and other criteria that will be utilized in the consideration of a Termination Review.
For projects that plan continuing operations and production, including integration of capability upgrades, with an unspecified Phase E end point, define the initial capability in the Review Plan for KDP B if the initial capability is not the first operational mission flight.
For projects that are part of tightly coupled programs, project life-cycle reviews and KDPs should be planned in accordance with the project life cycle and KDP sequencing guidelines in the Program Plan. Document the sequencing of each project life-cycle review and KDP with respect to the associated Program life-cycle review and KDP. In addition, document which project KDPs should be conducted simultaneously with other projects’ KDPs and which project KDPs should be conducted simultaneously with the associated program KDPs.
The sequencing of project life-cycle reviews and KDPs with respect to program life-cycle reviews and KDPs is especially important for project PDR life-cycle reviews that precede KDP Cs. At KDP C, the Agency makes project technical, cost, and schedule commitments to its external stakeholders at the established JCL in accordance with NPR 7120.5 requirements. Since changes to one project can easily impact other projects’ technical, cost, schedule, and risk baselines, projects and their program may need to proceed to KDP C/KDP I together.
3.11 Mission Operations Plan
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:
3.12 NEPA Compliance Plan
Describe the level of NEPA analysis planned to comply with NPR 8580.1, Implementing the National Environmental Policy Act, and Executive Order 12114. The NEPA Compliance Plan should be prepared based on consultation with the appropriate NEPA manager (Center NEPA Manager or Mission Direction NEPA Liaison) and describe the project’s NEPA strategy at all affected Centers, including decisions regarding programmatic NEPA documents. Insert into the project schedule the critical NEPA milestones if preparation of an Environmental Assessment or Environmental Impact Statement is planned.
3.13 Integrated Logistics Support Plan
Describe how the project will implement NPD 7500.1, Program and Project Life-Cycle Logistics Support Policy, including a maintenance and support concept; participation in the design process to enhance supportability; supply support; maintenance and maintenance planning; packaging, handling, and transportation; technical data and documentation; support and test equipment; training; manpower and personnel for ILS functions; facilities required for ILS functions; and logistics information systems for the life of the project.
3.14 Science Data Management Plan
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. Identify where the preliminary science data requirements will be documented (these requirements should be documented by SRR). The Plan should be developed in consultation with the Directorate data leads and the Office of the Chief Information Officer (OCIO) early in the project life-cycle to ensure that metadata standards and data formats are appropriately considered and that infrastructure and security requirements are addressed.
Explain how the project will accomplish the information management and disposition in NPD 2200.1, Management of NASA Scientific and Technical Information; NPR 2200.2, Requirements for Documentation, Approval and Dissemination of Scientific and Technical Information; and NPR 1441.1, NASA Records Management Program Requirements, as applicable to project science data.
Explain how the project will implement NASA sample handling, curation, and planetary protection directives and rules, including NPR 8715.24, Planetary Protection Provisions for Robotic Extraterrestrial Missions.
3.15 Integration Plan
Prepare an integration plan that defines the configuration of expected aggregates of system elements and the order of assembly of these aggregates to carry out efficient verification and validation actions. The integration plan is structured to bring the elements together to assemble each subsystem and to bring all the subsystems together to assemble the system/product. The primary purposes of the integration plan are: (1) to describe this coordinated integration effort that supports the implementation strategy, (2) to describe for the participants what needs to be done in each integration step, and (3) to identify the required resources and when and where they will be needed.
3.16 Configuration Management Plan
Describe the configuration management (CM) approach that the project team will implement. Describe the CM planning and management function including the CM organization and tools to be used. Describe the methods and procedures to be used for configuration identification, configuration control, interface management, configuration change management, configuration verification and audit, and configuration status accounting and communications. Describe how CM will be audited and how contractor CM processes will be integrated with the project. Configuration Management should address hardware, software, and firmware. Additional information on configuration management is provided in NPR 7123.1 and SAE/EIA 649, Standard for Configuration Management.
3.17 Security Plan
Describe the project’s plans for ensuring security, including:
Security Requirements: Describe the project’s approach for planning and implementing the requirements for physical, personnel, and industrial security and for security awareness/education requirements in accordance with NPR 1600.1, NASA Security Program Procedural Requirements.
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.
3.18 Project Protection Plan
Ensure that a Project Protection Plan is completed according to the schedule identified in product maturities, as documented in Appendix I of NPR 7120.5. The Project Protection Plan is approved by the Mission Directorate's designated approval authority, and the implementing Center's engineering Technical Authority.
The Project Protection Plan assesses applicable adversarial threats to the project or system (including support systems, development environments, and external resources), identifies system susceptibilities, potential vulnerabilities, countermeasures, resilience strategies, and risk mitigations. The results inform the project or system’s design and concept of operations, in context with the project’s or system’s requirements. The Project Protection Plan addresses NASA-STD-1006, Space System Protection Standard, in accordance with NPR 1058.1, NASA Enterprise Protection Program, and includes inputs from threat intelligence, candidate protection strategies provided by OCE, and other applicable standards. The project team assesses adversarial threats with support from the Office of Protective Services’ Intelligence Division and the Office of the Chief Engineer and requires access to Classified National Security Information.
Since protection measures can be implemented either by designing the project’s or system’s architecture to be more resilient or by enhancing the capabilities provided by institutional security providers, it is important that the document identify to institutional security providers (both internal and external to NASA) the critical nodes and single points-of-failure in the project or system. The project System Security Plan (see Section 3.7 above) and Security Plan (see Section 3.17) should address how institutional security measures are implemented on each project to protect its critical nodes.
Risk scenarios emerging from the Project Protection Plan analysis are tracked in accordance with the project's Risk Management Plan. (See Section 3.3 above.)
Project Protection Plans provide technical information on NASA space systems to specific commands and agencies in the Department of Defense and Intelligence Community to assist those organizations in providing timely support to NASA in the event of an incident involving a NASA mission.
3.19 Technology Transfer (formerly Export) Control Plan
Describe how the project will implement the export control requirements specified in
NPR 2190.1, NASA Export Control Program.
3.20 Knowledge Management Plan
Describe the project’s approach to creating the knowledge management strategy and processes. Strategy should include practices for identifying, capturing and transferring knowledge and capturing and documenting lessons learned throughout the project life cycle as authorized in NPD 7120.4, NASA Engineering and Program/Project Management Policy and as described in NPD 7120.6, Knowledge Policy for Programs and Projects and other appropriate requirements and standards documentation.
3.21 Human-Rating Certification Package
For human space flight missions, develop a Human-Rating Certification Package per NPR 8705.2, Human-Rating Requirements for Space Systems. Human-rating certification focuses on the integration of the human into the system, preventing catastrophic events during the mission, and protecting the health and safety of humans involved in or exposed to space activities, specifically the public, crew, passengers, and ground personnel.
3.22 Planetary Protection Plan
Prepare a plan that specifies management aspects of the planetary protection activities of the project. Planetary protection encompasses: (1) the control of terrestrial microbial contamination associated with space vehicles intended to land, orbit, flyby, or otherwise encounter extraterrestrial solar system bodies, and (2) the control of contamination of the Earth by extraterrestrial material collected and returned by missions. The scope of the plan contents and level of detail will vary with each project based upon the requirements in NASA policies NPR 8715.24, Planetary Protection Provisions for Robotic Extraterrestrial Missions, and NPD 8020.7, Biological Contamination Control for Outbound and Inbound Planetary Spacecraft.
3.23 Nuclear Launch Authorization Plan
Prepare a nuclear launch authorization plan for any U.S. space mission involving the use of radioactive materials. Procedures and levels of review and analysis required for nuclear launch authorization vary with the quantity of radioactive material planned for use and potential risk to the general public and the environment. NPR 8715.26, Nuclear Flight Safety specifies the safety guidelines for the launch of spacecraft containing space nuclear systems.
3.24 Range Safety Risk Management Process Documentation
Develop documentation that details a vehicle program’s Range Safety Risk Management process in accordance with NPR 8715.5, Range Flight Safety Program. This applies to launch and entry vehicle programs, scientific balloons, sounding rockets, drones and Unmanned Aircraft Systems. This does not apply to programs developing a payload that will fly on board a vehicle. The range flight safety concerns associated with a payload are addressed by the vehicle’s range flight safety process. The focus is on the protection of the public, workforce, and property during range flight operations.
3.25 Payload Safety Process Deliverables
Develop the payload safety process deliverables in accordance with NPR 8715.7, Payload Safety Program. This applies to NASA projects involving design, fabrication, testing, integration, processing, launch, and recovery of payloads and the design of ground support equipment (GSE) used to support payload-related operations during prelaunch operations and during recovery. Included are items such as free-flying automated spacecraft, Space Launch System payloads, Space Station payloads, expendable launch vehicle payloads, flight hardware and instruments designed to conduct experiments, and payload support equipment. NASA-STD-8719.24, NASA Expendable Launch Vehicle Payload Safety Requirements, provides more details on payload processing for launch.
3.26 Communications Plan
Develop a Communications Plan in collaboration with the Associate Administrator for the Office of Communications or their designee that identifies key project milestones that will be of interest to the general public, the media, and other key stakeholders and plans to engage these audiences via audio and real and/or near real-time high resolution video and/or imagery for each milestone including during full mission operations. Summarize how these efforts will promote understanding of and engagement with project objectives, elements, benefits, and contributions to overarching NASA goals. In collaboration with the Associate Administrator for the Office of Communications or their designee, identify resources and technical requirements for implementation of communications for the general public, media, and other key stakeholders. (See the Communications Plan Template (on the Web site for the Office of Communications, http://communications.nasa.gov/content/nasa-comm-guidelines.)
3.27 Quality Assurance Surveillance Plan
Develop a consolidated set of detailed instructions for the performance of Government contract quality assurance review and evaluation for the project. The plan might include contractor documents, data, and records; products and product attributes; processes; quality system elements/attributes; and requirements related to quality data analysis, nonconformance reporting and corrective action tracking/resolution, and final product acceptance. (See NASA-STD-8709.22, Safety and Mission Assurance Acronyms, Abbreviations, and Definitions.)
3.28 Orbital Collision Avoidance Plan
Describe how the project implements the design considerations and preparation for operations to avoid in-space collisions. The plan ensures the space flight mission meets the requirements of NPR 8079.1, NASA Spacecraft Conjunction Analysis and Collision Avoidance for Space Environment Protection. Include in the plan a project overview including a concept of operation, how orbit selection was performed, the spacecraft’s ascent and descent plan, how the spacecraft’s location tracking data will be generated, and whether there will be any autonomous flight control. Discuss how the spacecraft’s design will enable it to be acquired and tracked by the Space Surveillance Network and be cataloged by the U.S. Space Command. Describe the process to routinely coordinate with other operator(s) for maneuvering. Appendix D of the NPR provides a template for this plan. (See NPR 8079.1, NASA Spacecraft Conjunction Analysis and Collision Avoidance for Space Environment Protection for more detail and plan template.)
3.29 Human Systems Integration Approach
Develop a Human Systems Integration (HSI) approach in accordance with NPR 7123.1. (See the NASA Human Systems Integration (HSI) Handbook, NASA/SP-20210010952, for additional information.)
4.0 WAIVERS OR DEVIATIONS LOG
Identify NPR 7120.5 requirements for which a waiver or deviation has been requested and approved consistent with project characteristics such as scope, complexity, visibility, cost, safety, and acceptable risk, and provide rationale and approvals.
5.0 CHANGE LOG
Track and document changes to the Project Plan.
6.0 APPENDICES
Appendix A. Acronyms
Appendix B. Definitions
Appendix C. Compliance Matrix for this NPR
| TOC | ChangeHistory | Preface | Chapter1 | Chapter2 | Chapter3 | AppendixA | AppendixB | | AppendixC | AppendixD | AppendixE | AppendixF | AppendixG | AppendixH | AppendixI | AppendixJ | ALL | |
| | NODIS Library | Program Formulation(7000s) | Search | |
This document does not bind the public, except as authorized by law or as incorporated into a contract. This document is uncontrolled when printed. Check the NASA Online Directives Information System (NODIS) Library to verify that this is the correct version before use: https://nodis3.gsfc.nasa.gov.