![[NASA Logo]](../Images/nasaball.gif) |
NASA Procedures and Guidelines |
||||
This Document is Obsolete and Is No Longer Used.
|
|||||
|
|
|||||
|
|
||||
| | TOC | ChangeLog | 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. They are based on requirements in NASA Policy Directives (NPDs) and NASA Procedural Requirements (NPRs) that affect program/project planning. Certain control plans (the Safety and Mission Assurance (SMA) Plan, Risk Management Plan, Systems Engineering Management Plan (SEMP), and Software Management Plan) are required to be stand-alone plans with summaries and references provided in the Project Plan. 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. The remaining 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. 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.
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.
Figure H-1 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.
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. 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, 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. (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 Dissenting Opinion 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, 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 knowledge management, lessons learned, and 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.
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 WBS Handbook, NASA/SP-2010-3404, which can be found on the OCE tab under the "Other Policy Documents" menu in NODIS. The WBS will support cost and schedule allocation down to a 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 in accordance with NPD 1000.5 and this NPR.
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 Implementation and beyond of projects with an estimated life-cycle cost (LCC) greater than $250 million, document the project's joint cost and schedule confidence level approved by the Decision Authority (DA) and the basis for its consistency with the program's joint cost and schedule confidence level (JCL).
3.0 PROJECT CONTROL PLANS
3.1 Technical, Schedule, and Cost Control Plan
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:
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.
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. These include:
These indicators are further explained in the NASA Space Flight Program and Project Management Handbook, the NASA Project Planning and Control Handbook, and in a white paper on the Program and Project Management Communities of Practice Web site.
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 baseline review in the event the DA 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 dissenting opinions.
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 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-level 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 General Safety Program Requirements, and NPR 8705.2, NASA Human-Rating Requirements for Space 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.1, 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 Standard for Software Assurance; quality assurance functions per NPR 8735.1, Procedures For Exchanging Parts, Materials, and Safety Problem Data Utilizing the Government-Industry Data Exchange Program and NASA Advisories and 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.
Reference the stand-alone SMA Plan here.
3.3 Risk Management Plan
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.
Develop a stand-alone Risk Management Plan that includes the content required by NPR 8000.4. Reference the stand-alone plan here.
3.4 Acquisition Plan
The project Acquisition Plan is developed by the project manager, supported by the host Center's Procurement Officer, and needs to be consistent with the results of the Agency strategic acquisition process and 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 Plan 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 plan 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 how the project will establish and implement a risk management process per NPR 8000.4.
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, inter-Center memoranda of agreement.
(2) Non-NASA agreements:
(a) Domestic, e.g., U.S. Government agencies.
(b) International, e.g., memoranda of understanding.
3.5 Technology Development Plan
Describe the technology assessment, development, management, and acquisition strategies 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 in accordance with NPR 7500.2, NASA Technology Transfer Requirements.
Describe how the project will identify opportunities for leveraging ongoing 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. (Reference NPR 7123.1 for Technology Readiness Levels definitions.)
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.
3.6 Systems Engineering Management Plan
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.
3.7 Information Technology Plan
Describe how the project will acquire and use information technology, addressing the following:
Document the project's approach to implementing IT security requirements in accordance with NPR 2810.1, Security of Information Technology. Place special emphasis on describing how the project will meet the following requirements:
(1) Conduct the Information/System Security Categorization for IT systems during Phase A of the project.
(2) Perform the IT system risk assessment during Phase B of the project.
(3) Document and implement all technical, management, and operational security controls for IT systems during Phase D of the project.
(4) Meet the IT security certification and accreditation requirements for IT systems during Phase D of the project.
(5) Conduct an annual IT security assessment of IT systems during Phase E of the project.
Describe how the project will manage information throughout its life cycle in accordance with NPR 2800.1, Managing Information Technology, 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, NASA Records Retention Schedules. Reference the stand-alone Records Management Plan, if applicable, to address all records described in NPR 7120.5.
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.2, Requirements for Documentation, Approval, and Dissemination of NASA Scientific and Technical Information.
3.8 Software Management Plan
ummarize 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-STD-8739.8, Software Assurance Standard. The Plan should be coordinated with the Systems Engineering Management Plan. Reference the stand-alone Plan here.
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. Provide the technical, scientific, schedule, cost, and other criteria that will be utilized in the consideration of a Termination Review.
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 Environmental Management Plan
Describe the activities to be conducted at all project locations with support from the responsible Environmental Management Office to comply with NPR 8580.1, Implementing the National Environmental Policy Act and Executive Order 12114. Specifically:
3.13 Integrated Logistics Support Plan
Describe how the project will implement NPD 7500.1, Program and Project Logistics 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. 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.2, Requirements for Documentation, Approval, and Dissemination of NASA Scientific and Technical Information, NPR 1441.1, NASA Records Retention Schedules, as applicable to project science data.
3.15 Integration Plan
Prepare an integration plan that defines the integration and verification strategies for a project interface with the system design and decomposition into the lower-level elements. The integration plan is structured to bring the elements together to assemble each subsystem and to bring all of the subsystems together to assemble the system/product. The primary purposes of the integration plan are: (1) to describe this coordinated integration effort that supports the implementation strategy, (2) to describe for the participants what needs to be done in each integration step, and (3) to identify the required resources and when and where they will be needed.
3.16 Configuration Management
Describe the configuration management (CM) approach that the project team will implement, consistent with NPR 7123.1 and SAE EIA 649B Standard for Configuration Management. 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.
3.17 Security Plan
Describe the project's plans for ensuring security and technology protection, including:
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, NASA 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.
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's or system's design and concept of operations, in context with the project's or system's requirements. The plan includes inputs from threat intelligence, Candidate Protection Strategies provided by the Office of Chief Engineer, and applicable standards. The project team assesses adversarial threats with support from the Office of Protective Services' Intelligence Division and the Office of 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 Information Technology Plan (see Section 3.7) 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).
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 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 in accordance with NPD 7120.4, NASA Engineering and Program/Project Management Policy and as described in NPD 7120.6, Knowledge Policy on 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 8020.12, Planetary Protection Provisions for Robotic Extraterrestrial Missions, and NPD 8020.7, Biological Contamination Control for Outbound and Inbound Planetary Spacecraft.
3.23 Nuclear Safety Launch Approval Plan
Prepare a nuclear safety launch approval plan for any U.S. space mission involving the use of radioactive materials. Procedures and levels of review and analysis required for nuclear launch safety approval vary with the quantity of radioactive material planned for use and potential risk to the general public and the environment. NPR 8715.3, NASA General Safety Program Requirements, specifies the procedural requirements for characterizing and reporting potential risks associated with a planned launch of radioactive materials into space, on launch vehicles and spacecraft, and during flight.
3.24 Range Flight Safety Risk Management Process Documentation
Develop documentation that details a vehicle program's Range Flight 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 Expendable Launch Vehicle Payload Safety Process Deliverables
For Expendable Launch Vehicle payloads, develop the payload safety process deliverables in accordance with NPR 8715.7, Expendable Launch Vehicle Payload Safety Program. This applies to uninhabited orbital and uninhabited deep space payloads that fly onboard Expendable Launch Vehicles and are managed by NASA, whether developed by NASA or any contractor or independent agency in a joint venture with NASA. The focus is on payload design, fabrication, testing, vehicle integration, launch processing, launch, and planned recovery; payload-provided upper stages; interface hardware that is flown as part of a payload; and Ground Support Equipment used to support payload-related operations. NASA-STD 8719.24 provides more details on payload processing for launch.
3.26 Communications Plan
Describe plans to implement a diverse, broad, and integrated set of efforts and activities to communicate with, and engage target audiences, the public, and other stakeholders in, understanding the project, its objectives, elements and benefits, and how it relates to the larger NASA vision and mission. Focus should be placed on activities and campaigns that are relevant, compelling, accessible, and where appropriate, participatory. Describe how these efforts and activities will promote interest and foster participation in NASA's endeavors. Address how these efforts and activities will develop exposure to, and appreciation for, STEM.
Define goals and outcomes, as well as key overarching messages and themes. Identify target audiences, stakeholders, and partnerships. Summarize and describe products to be developed and the tools, infrastructure, and methods that will be used to communicate, deploy, and disseminate those products, including media, multimedia, Internet, social media, and publications for non-technical audiences. Describe events, activities, and initiatives focused on public engagement and how they link with planned products and infrastructure. Identify milestones and resources required for implementation, and define metrics to measure success.
Describe the relationship between communications project plan elements and program plan elements, and coordination between the project and program regarding communications activities.
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 | ChangeLog | Preface | Chapter1 | Chapter2 | Chapter3 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | AppendixF | AppendixG | AppendixH | AppendixI | AppendixJ | ALL | |
| | NODIS Library | Program Formulation(7000s) | Search | |