![[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 | | |||||
G.1.1 The Program Plan is an agreement among the program manager, Center Director, and Mission Directorate Associate Administrator (MDAA). Other Center Directors providing a significant contribution to the program also concur with the Program Plan to document their commitment to provide required Center resources. The Program Plan defines the goals and objectives of the program, the environment within which the program operates, and the Management Agreement commitments of the program, including identifying the high-level requirements on both the program and each constituent project. These requirements on the project may be in the body of the Plan or added as appendices. The Program Plan is to be updated and approved during the program life cycle if warranted by changes in the stated Management Agreement commitments.
G.1.2 In this Program Plan template, all subordinate plans, collectively called control plans, are required unless they are not applicable. They are based on requirements in NASA Policy Directives (NPDs) and NASA Procedural Requirements (NPRs) that affect program/project planning. For tightly coupled programs, the SMA Plan, Risk Management Plan, Product Data and Life-Cycle Management (PDLM) Plan, and SEMP are required to be stand-alone plans with summaries and references provided in the Program Plan. If a control plan is not applicable to a particular program, indicate that by stating it is not applicable in the appropriate section and provide a rationale. The remaining control plans can either be part of the Program Plan or separate stand-alone documents referenced in the appropriate part of the Program Plan. In the case of the latter, the Program Plan contains a summary of and reference to the stand-alone document; the approval authority for the stand-alone Control Plan is the program manager.
G.1.3 Each section of the Program Plan template is required. If a section is not applicable to a particular program, indicate in the appropriate section and provide a rationale. If a section is applicable but the program desires to omit the section or parts of a section, then a waiver needs to be obtained in accordance with the requirement tailoring process for NPR 7120.5. Approvals are documented in Part 4.0, Waivers or Deviations Log, of the Program Plan. In addition, the program's Compliance Matrix for this NPR is attached to the Program Plan. If the format of the completed Program Plan differs from this template, a cross-reference table indicating where the information for each template paragraph is needs to be provided with the document when it is submitted for MDAA signature.
G.1.4 The approval signatures of the MDAA, the Center Director, and the program manager certify that the Program Plan implements all the Agency's applicable institutional requirements or that the authority responsible for those requirements, e.g., Safety and Mission Assurance, have granted a deviation or waiver to the modification of those requirements.
G.1.5 Single-project programs may combine the Program and Project Plans into a single document if the MDAA agrees.
Figure G-1 Program Plan Title Page
[Program Name] Program Plan]
[short title or acronym]
1.0 PROGRAM OVERVIEW
1.1 Introduction
Briefly describe the background of the program and its current status, including results of Formulation activities, decisions, and documentation.
1.2 Goals and Objectives
State program goals and specific objectives, and provide clear traceability to the Agency's strategic goals and to Mission Directorate strategic goals and objectives. Program performance goals and their relationship to NASA program goals set forth in NPD 1001.0, NASA Strategic Plan should be expressed in an objective, quantifiable, and measurable form. Goals and objectives should include specific commitments to safety and mission success.
1.3 Program Architecture
Briefly describe the architecture of the program, its major components, and the way they will be integrated. Describe how the major program components are intended to operate together, and with legacy systems, as applicable, to achieve program goals and objectives. Specify the type of program (i.e., single-project, uncoupled, loosely coupled, or tightly coupled) and the basis for that classification.
Provide a summary-level technical description of the program, including constituent projects and operations concepts. The description should also include mission description, program interfaces, facilities, logistics concepts, planned mission results, and data analysis, archiving, and reporting. Identify driving ground rules and assumptions and major constraints affecting program systems development (e.g., cost, launch window, required launch vehicle, mission planetary environment, fuel/engine design, and foreign partners).
Describe how the program will relate to other organizations within and outside NASA. Reference Section 3.4, Acquisition Plan of this document (below) or provide the following information here:
For organizations within NASA, describe the roles of each in the program, including technology efforts, space communications, and launch services.
For organizations outside NASA, describe the role of each in the program, including other government agencies, academia, industry, and international partners as they are known at the start of the program.
1.4 Stakeholder Definition
Identify the main stakeholders of the program (e.g., PI, science community, technology community, public, education community, and Mission Directorate sponsor(s)) and the process to be used within the program to ensure stakeholder advocacy.
1.5 Program Authority, Management Approach, and Governance Structure
Describe the program management structure, including each participating organization's responsibilities. Identify:
Describe the chain of accountability and decision path outlining the roles and responsibilities of the Mission Directorate sponsor(s), program manager, Center Director, and other authorities (including the Technical Authorities), as required. Provide a high-level description of the project's organization within the program, showing the chain of accountability. Describe clear lines of authority from projects and Centers to the program, and to the Mission Directorate, and frequency of reporting for each. Illustrate the organization graphically. Describe the process by which projects are formulated, approved, and terminated.
1.6 Implementation Approach
Describe briefly the implementation approach of the program, including any applicable guidance or direction from the ASM review, the acquisition strategy (e.g., in-house, NASA Centers, and contractor primes), partners, and partner contributions, if appropriate. Include make-or-buy decision plans and trade studies.
Describe how knowledge management, lessons learned, and participating NASA Centers' implementation policies and practices will be utilized in the execution of the program. (Note: For tightly coupled programs, the program manager, the NASA Chief Engineer, and the Center Chief Engineers (or designees) participating in the program establish the engineering best practices for the program. These decisions are documented here.) Document the agreements on the use of implementation policies and practices between the program manager and participating NASA Centers in this section (or in appendices to the document), along with the program's approach to ensuring that interfaces do not increase risk to mission success.
2.0 PROGRAM BASELINES
2.1 Requirements Baseline
Program Requirements. Document the high-level program requirements, including performance, safety, and programmatic requirements and correlate them to Agency and Mission Directorate strategic objectives and requirements. Describe the process by which program requirements are verified for compliance. Describe the process for controlling changes to program requirements. Document the traceability of requirements that flow down from Agency- and Center-level policy to the program and from the program to projects.
Requirements Documentation. For tightly coupled programs and single-project programs, decompose these high-level requirements into requirements on constituent projects or systems, specified herein or in a separate, configuration-controlled, program requirements document to be prepared by the program manager and approved by the MDAA. Additional concurrences may be required at the option of the NASA AA. There may also be subordinate project requirements documents controlled at lower levels.
For uncoupled or loosely coupled programs, apply these high-level requirements to generate the program's requirements on each constituent project. This documentation is controlled by the Mission Directorate and may be located in the body of the Program Plan or in a subsequent appendix. Requirements thus documented, and any subsequent changes, require approval of the program manager, MDAA, and participating Center Director(s).
Program Requirements on Projects. For each project, provide a top-level description, including the mission's science or exploration objectives. Document the project's category, governing PMC, and risk classification. Describe the project's mission, performance, and safety requirements. For science missions, include both baseline science requirements and threshold science requirements. (See Appendix A for definitions.) Identify the mission success criteria for each project based on the threshold science requirements. State each requirement in objective, quantifiable, and verifiable terms. Identify the project's principal schedule milestones, including Preliminary Design Review (PDR), Critical Design Review (CDR), launch, mission operational-critical milestones, and the planned decommissioning date. State the development and/or total life-cycle cost constraints on the project. Set forth any budget constraints by fiscal year. State the specific conditions under which a project Termination Review would be triggered. Describe any additional requirements on the project (e.g., international partners). If the mission characteristics indicate a greater emphasis is necessary on maintaining technical, cost, or schedule, then identify which is most important (e.g., state if the mission is cost capped; or if schedule is paramount, as for a planetary mission; or if it is critical to accomplish all of the technical objectives, as for a technology demonstration mission).
2.2 WBS Baseline
Provide the program's Work Breakdown Structure (WBS) and WBS dictionary down to the project level developed in accordance with guidance provided by the NASA WBS Handbook, NASA/SP-2010-3404, which can be found on the OCE tab under the "Other Policy Documents" menu in NODIS. The WBS will support cost and schedule allocation down to a project level that allows for unambiguous cost reporting.
2.3 Schedule Baseline
Present a summary of the program's integrated master schedule (IMS), including all critical milestones, major events, life-cycle reviews, and KDPs throughout the program life cycle. The summary of the master schedule should include the logical relationships (interdependencies) for the various program elements and projects and critical paths, as appropriate. Identify driving ground rules, assumptions, and constraints affecting the schedule baseline.
2.4 Resource Baseline
Present the program's funding requirements by fiscal year. State the New Obligation Authority (NOA) in real-year dollars for all years - prior, current, and remaining. The funding requirements are to be consistent with the program's WBS and include funding for all cost elements required by the Agency's full-cost accounting procedures. Funding requirements are to be consistent with the budget. Provide a breakdown of the program's funding requirements to the WBS Level 2 elements. Present the program-specific (i.e., not individual project) workforce requirements by fiscal year, consistent with the program's funding requirements and WBS. Throughout the Implementation Phase, baselines are to be based on the joint cost and schedule confidence level in accordance with NPD 1000.5 and NPR 7120.5.
Describe the program infrastructure requirements (acquisition, renovations, and/or use of real property/facilities, aircraft, personal property, and information technology). Identify means of meeting infrastructure requirements through synergy with other existing and planned programs and projects to avoid duplication of facilities and capabilities. Identify necessary upgrades or new developments, including those needed for environmental compliance.
Identify driving ground rules, assumptions, and constraints affecting the resource baseline.
Document the project Commitment Baselines.
2.5 Joint Cost and Schedule Confidence Level
For implementation and beyond for single-project and tightly coupled programs, document the joint cost and schedule confidence level approved by the Decision Authority.
3.0 PROGRAM CONTROL PLANS
3.1 Technical, Schedule, and Cost Control Plan
Document how the program plans to control program requirements, technical design, schedule, and cost to achieve its high-level requirements. This control plan will include the following:
Describe the plan to monitor and control the requirements, technical design, schedule, and cost of the program.
Describe the program's performance measures in objective, quantifiable, and measurable terms and document how the measures are traced from the program high-level requirements. Establish baseline and threshold values for the performance metrics to be achieved at each Key Decision Point (KDP), as appropriate. In addition, document the mission success criteria associated with the program-level requirements that, if not met, trigger consideration of a Termination Review.
Tightly coupled and single-project programs also develop and maintain the status of a set of programmatic and technical leading indicators to ensure proper progress and management of the program. These include:
Requirement Trends (percent growth, TBD/TBR closures, number of requirement changes); Interface Trends (percent ICD approval, TBD/TBR burn down, number of interface requirement changes);
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.
For tightly coupled programs, describe the approach to monitor and control the program'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 enable corrective action prior to triggering the 30 percent breach threshold. Describe how the project will support a baseline review in the event the Decision Authority (DA) directs one.
Describe how the program will implement the Systeme Internationale (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 program's implementation of Technical Authority (Engineering, Safety and Mission Assurance, and Health and Medical).
For tightly coupled programs, describe the program's Earned Value Management System (EVMS), if EVM requirements are to be levied at the program level. For loosely coupled or uncoupled programs, describe the EVM requirements flowed down to the projects. Include plan for flow down of EVM requirements and reporting to support project EVM.
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.
Describe how the program will monitor and control the integrated master schedule (IMS).
Describe how the program will utilize its technical and schedule margins and Unallocated Future Expense (UFE) to control the Management Agreement.
Describe how the program plans to report technical, schedule, and cost status to the MDAA, including frequency and the level of detail.
Describe how the program will address technical waivers and deviations and how dissenting opinions will be handled.
3.2 Safety and Mission Assurance Plan
Develop a program Safety and Mission Assurance (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, pre-flight verification and test, maintenance, and retirement.
The Plan also addresses specific critical SMA disciplines including (as a minimum): safety per NPR 8715.3, NASA General Safety Program Requirements; 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 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 problems and anomaly reports, problem analysis, and corrective action.
3.3 Risk Management Plan
Summarize how the program will implement the NASA 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. Programs 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.
For tightly coupled programs, develop a stand-alone Risk Management Plan and reference the stand-alone plan here.
3.4 Acquisition Plan
The program Acquisition Plan is developed by the program manager, supported by the Office of Procurement, and needs to be consistent with the results of the process for acquisition and the ASM. The elements of the program Acquisition Plan should be reflected in any resulting Procurement Strategy Meeting (PSM) for individual procurement activity supporting the program Acquisition Plan. It documents an integrated acquisition strategy that enables the program 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 program 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 state of the industrial base capability 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 industrial base and supply chain risks. Include data reporting relationships to allow continuous surveillance of the entire supply chain that provides for timely notification and mitigation of potential risks associated with the industrial base or supply chain. Describe the process for reporting industrial base and supply chain risks to the MDAA.
Identify the program's approach to strengthen safety and mission assurance in the contract.
Describe how the program 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 the NFS. List all such agreements (the configuration control numbers, the date signed or projected dates of approval, and associated record requirements) 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.
(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 program's mission objectives.
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. 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 program will identify opportunities for leveraging ongoing technology efforts.
Describe how the program 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 program'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).
Describe how the program 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 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.
Describe how the program will transition technologies from the development stage to manufacturing, production, and insertion into the end system. Identify any potential costs and risks associated with the transition to manufacturing, production, and insertion. Develop and document appropriate mitigation plans for the identified risks.
3.6 Systems Engineering Management Plan
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.
3.7 Verification and Validation Plan
Summarize the approach for performing verification and validation of the program 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.8 Information Technology Plan
Describe how the program will acquire and use information technology, addressing the following:
a. 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.2, Requirements for Documentation, Approval, and Dissemination of NASA Scientific and Technical Information.
b. 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, NASA Records Retention Schedules.
c. Document the program's approach to implementing IT security requirements in accordance with NPR 2810.1, Security of Information Technology.
3.9 Review Plan
Summarize the program's approach for conducting a series of reviews, including internal reviews and program life-cycle reviews. In accordance with Center best practices, MD 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 program is planning or waivers that have been granted. Specify the considerations that will be used to trigger a discussion on the need for a PIR with the NASA AA (see Section 2.4.4.1 and Considerations for a PIR in Appendix A.) 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 life-cycle 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. For each program life-cycle review and KDP, document the sequencing of the associated project life-cycle reviews and KDPs, i.e., whether the associated project life-cycle reviews and KDPs precede or follow the program life-cycle review and KDP. In addition, document which projects should proceed to their KDPs together, which projects should proceed to their KDPs simultaneously with the program KDP, and which projects may proceed to their KDPs as individual projects.
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.10 Mission Operations Plan
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:
3.11 Environmental Management Plan
Describe the activities to be conducted to comply with NPR 8580.1, Implementing the National Environmental Policy Act, and Executive Order 12114. After consultation with the NASA Headquarters National Environmental Policy Act (NEPA) coordinator, describe the program's NEPA strategy at all affected Centers, including decisions regarding programmatic NEPA documents. Insert into the program schedule the critical milestones associated with complying with these regulations.
3.12 Integrated Logistics Support Plan
Describe how the program 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 Integrated Logistics Support (ILS) functions; facilities required for ILS functions; and logistics information systems for the life of the program.
3.13 Science Data Management Plan
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 definitions 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.2, Requirements for Documentation, Approval, and Dissemination of NASA Scientific and Technical Information, NPR 1441.1, NASA Records Retention Schedules, as applicable to program science data.
State further that the program will adhere to all NASA sample handling, curation, and planetary protection directives and rules, including NPR 8020.12, Planetary Protection Provisions for Robotic Extraterrestrial Missions.
3.14 Configuration Management Plan
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.
3.15 Security Plan
Describe the program's plans for ensuring security and technology protection, including:
Security Requirements: Describe the program'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 provisions in the plan 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.
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.
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.
3.16 Technology Transfer Control Plan
Describe how the program will implement the export control requirements specified in NPR 2190.1, NASA Export Control Program.
3.17 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 program, its objectives, elements, and benefits. Describe how the plan 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, Web, 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 the program and project Communications Plans and the coordination between program and projects regarding communications activities.
3.18 Knowledge Management Plan
Describe the project's approach to creating the program's knowledge management strategy and processes. Strategy should include practices for examining the lessons learned database for relevant lessons that can be reflected in the program early in the planning process to avoid known issues; identifying, capturing and transferring knowledge and continuously capturing and documenting lessons learned throughout the program 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.19 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.
4.0 WAIVERS OR DEVIATIONS LOG
Identify NPR 7120.5 requirements for which a waiver or deviation has been requested and approved consistent with program characteristics such as scope, complexity, visibility, cost, safety, and acceptable risk, and provide rationale and approvals.
5.0 CHANGE LOG
Record changes in the Program 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 | |