Procedural
Requirements
Effective Date: September 14, 2018
Expiration Date: September 14, 2028
|
|
NASA Procedural Requirements |
NPR 7120.8A Effective Date: September 14, 2018 Expiration Date: September 14, 2028 |
| | TOC | ChangeLog | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | AppendixF | AppendixG | AppendixH | AppendixI | AppendixJ | AppendixK | AppendixL | AppendixM | ALL | |
4.1.1 R&T Project Types
4.1.1.1 The requirements in this section cover R&T projects. As described in Section 2.3, there are two types of R&T projects: Technology Development and Research Projects. The requirements in this section apply equally to both types of projects. R&T projects may comprise a portfolio or series of scientific and/or technical investigations, experiments, or prototyping. As mentioned in Section 2.1.2 of this document, how they are implemented will vary between projects depending on their type, size, and complexity. Some guidance is provided with each requirement as to how the implementation may vary for different types and sizes of projects.
4.1.1.2 New technologies often emerge from R&T activities where fundamental scientific principles are investigated and concepts for their application are formulated. The early stages of technology development and research are often performed in the laboratory but may involve model development or simulations; later stages may involve field tests or flight demonstration experiments to validate the technology or research in relevant environments.
4.1.2 Project Life Cycle
4.1.2.1 The project life cycle is shown in Figure 4-1. As shown in the figure, the project life-cycle phases consist of Pre-Formulation, Formulation, and Implementation (including Closeout). The figure also depicts project reviews (including key decision points, internal reviews, and independent assessments) and key products.
4.1.2.2 The project reviews consist of KDP reviews that include ATP, Project Approval, CAs, and Closeout; internal reviews (PPRs); and IAs. As depicted in the life cycle, three specific KDPs are required: ATP (to transition from Pre-Formulation to Formulation), Project Approval (to transition from Formulation to Implementation), and Closeout. In addition to these KDPs, at least one CA is conducted during the Implementation Phase. Depending on the duration, investment-level, complexity, and/or project scope, periodic CAs may be added as additional KDPs. If IAs are required at any KDP, they are performed immediately preceding or concurrent with the KDP. The schedule of reviews, including CAs and PPRs is approved by the DA in coordination with the program manager and project manager and documented in the Project Plan.
4.1.2.3 The DA is the individual authorized by the Agency that determines the readiness of a project to progress to the next phase of the life cycle. The DA conducts the project key decision point reviews. The project may not have all the phases identified in Figure 4-1 depending on its type, size, and complexity. A large project may need all phases, whereas a smaller project may proceed directly into Implementation after attaining approval. The decision of where a project may enter the life cycle is made by the DA in coordination with the program manager and documented in the Project Plan. For the purposes of this document, all phases will be described. Which phases a specific project will execute will be at the discretion of the DA.
Figure 4-1 R&T Project Life Cycle
4.1.2.4 For R&T projects, the DA, Management Official, governing PMC, and governing document are defined in Table 4-1.
Table 4-1 Summary of Governance Authorities for R&T Projects
| Authority Role | Authority | Comments |
|---|---|---|
| Project DA for KDPs (ATP), Project Approval, CAs, and Closeout) | MDAA | The MDAA can delegate responsibility to the program manager. |
| Management Official for Establishing Independent Assessment Team(s) | MDAA | The MDAA identifies the chair of the independent assessment team. The chair selects any team members. Approvals/concurrences are obtained from the Mission Directorate, implementing Centers, and OCE for the 1) IA Chair, 2) IA team members, and 3) IA expectations document. The MDAA may delegate responsibility for independent reviews per their discretion. The MDAA will ensure that the team(s) and process are independent and objective. |
| Governing PMC | DPMC | If decision authority is delegated to the program manager, the governing PMC can be delegated to a lower level board or council. |
| Governing Document | Project Plan | The Project Plans are approved by the project DA with concurrence by the program manager/Research Director and applicable Center Director(s). |
Note: Project Plans will reflect delegations, define reviews, and document the attendant rationale for the changes.
4.2.1 Figure 4-2 depicts the generic flow of activities for R&T projects. Details of how each activity is accomplished may vary depending on the type of project and its size and complexity. Each activity will be described in the following sections and their associated requirements. For competed projects, see Sections 4.2.6.5 to 4.2.6.9.
4.2.2 The MDAA and Center Director roles (other than as described in Table 4-1) may be delegated, as appropriate, to the size and scope of the project. In this NPR, when the role of these authorities is described, “or designee” is implied.
Figure 4-2 Generic Flow for R&T Projects
4.2.3 Select Project Manager
4.2.3.1 The R&T program manager, in coordination with the DA, shall assign a project manager to lead the project effort.
4.2.3.2 For projects that reside in a Center, the program manager coordinates the assignment of the project manager with the providing Center Director or designee.
4.2.3.3 The selection and assignment of a project manager is made as early in the project life cycle as possible. The project manager provides the overall leadership for the project, managing all aspects of the project, including technical, cost, schedule, safety, and business aspects. The project manager will also be responsible for the coordination and direction of the project team. For details of the role and responsibilities of a project manager, refer to section 5.2.2.10
4.2.4 Receive Project Scope
4.2.4.1 As early in the life cycle as possible, the program manager provides the project manager with a documented statement for the project’s purpose, scope (e.g., FAD), constraints, and any requirements that may be placed on the project or its product.
4.2.4.2 The scope of the project may be provided from the program in many forms, including in a formal FAD (see Appendix F for guidance), project charter, task agreement, memorandum, or from a Request for Proposal (RFP), Announcement of Opportunity (AO), or other documentation, as appropriate, for the type, size, and complexity of the project and as agreed-to by the MDAA and the program manager.
4.2.5 Preliminary Planning
4.2.5.1 The project manager shall provide to the DA documentation that establishes the technical and acquisition work that needs to be performed during the life cycle or at least during the Formulation Phase, including the management process, deliverables, preliminary schedule, and funding requirements. This information is documented as a preliminary Project Plan, preliminary proposal response, development of an abstract for a paper, or other form depending on the type and size of the project.
4.2.5.2 Members of the project team are usually provided by line management in coordination with the project manager. The number and makeup of this initial project team will vary depending on the type and size of the project.
4.2.5.3 Planning starts with understanding the needs of the stakeholders and any high-level threshold requirements. The expected end-state of the project and its deliverables are identified. If not provided as part of the project scope, a preliminary schedule and estimate of life-cycle cost is developed. If the research is more exploratory in nature, this initial cost and schedule estimate may be just for the next phase of the project and then the information is updated as the forward progress becomes clearer. Note that in some cases, the length of the Formulation Phase may be very short—just enough to gather the information that will be provided to the DA for the ATP decision.
4.2.5.4 If the project is developing a technology for a space flight project, further technology development or integration may be governed by NPR 7120.5. The decision of when and how a technology is transitioned from this directive to NPR 7120.5 is planned and identified in the Project Plan. This decision will affect the type of documentation, verification, and processes used during the technology development project and should be addressed early in the life cycle to ensure project planning is aligned to accommodate compliance with applicable requirements (e.g., space flight vehicle safety and interface requirement and integration reviews, and other applicable requirements to support preparation and certification for space flight). R&T projects flying on expendable launch vehicles also need to comply with NPR 8715.7, Payload Safety Program. NASA-sponsored R&T projects launched into space will comply with NPR 8715.6, NASA Procedural Requirements for Limiting Orbital and Evaluating the Meteoroid and Orbital Debris Environments. R&T projects operating in space will comply with the requirement to develop a Project Protection Plan in accordance with NASA-STD-1006 per NPR 7120.5.
4.2.6 R&T Project Authority to Proceed (ATP)
4.2.6.1 The DA shall conduct the ATP KDP to determine approval for a proposed project to enter the Formulation Phase and begin developing more detailed plans. The approach for the Formulation Phase (both technical and management), including preliminary costs and schedules, is reviewed at the ATP. The Formulation key milestones and reviews are identified. The associated Program Plan can be referenced for the details of the new project initiation process.
4.2.6.2 Table 4-2 provides guidance on input and output expectations for the ATP KDP. The actual input and output content and format requirements are determined by the DA in coordination with the program manager, project manager, and other key stakeholders and depends on the type and size of the project.
Table 4-2 ATP Expected Inputs and Outputs
| Authority to Proceed | |
|---|---|
| Input Expectations | Output Expectations |
|
|
4.2.6.3 The agreed-to information is provided to the DA so that they can determine whether the potential project is within the cost, schedule, and technical needs of the project scope (FAD, Task Agreement, RFP, or other). The DA may gather peers, stakeholders, or line management to review the information or make the decision on their own depending on the type and size of the project. If the information is not sufficient to make that determination, the DA may ask the project team to continue their planning effort or modify their plans based on identified weaknesses. If the DA determines that the concepts for the potential project do not meet minimum requirements or are not relevant to the associated AO, NASA Research Announcement (NRA), or other solicitation, the DA may decide to discontinue work on the potential project. If the information is deemed sufficient to continue into more detailed planning, the DA will approve the project’s transition to Formulation.
4.2.6.4 The ATP authorization decision documentation can come in the form of a Decision Memorandum, a signature on a task agreement, or other form depending on the type and size of the project. The decision is captured in some form and stored with the project’s retrievable records (e.g., appended to Project Plan).
4.2.6.5 Competed projects may enter the life cycle as early as Formulation, with the selection process review being the equivalent of the ATP KDP. Competed projects are awarded through a solicitation process such as an AO, Broad Agency Announcement (BAA), and/or NRA. NPR 1080.1, Requirements for the Conduct of NASA Research and Technology (R&T), governs the selection process for competed R&T activities.
4.2.6.6 It is the responsibility of the DA for any competed projects to ensure the requirements of this directive are met. As with all projects for which this directive applies, competed projects are afforded great flexibility in meeting the intent of the requirements. For competed projects, the equivalent of Pre-Formulation is NASA’s solicitation development effort, which outlines the scope of project activities and initial resource estimates. Any tailoring of requirements and contractual obligations on the project are written into the solicitation.
4.2.6.7 Competed projects can be selected in either a single step or in multiple steps where several projects may be selected and program resources are invested to mature the concept, associated research, and/or technologies of the project. Depending on the selection process, the maturity of the project, and the products developed for the competition, the selection may meet the expectation criteria of an ATP KDP or the criteria satisfying the Project Approval KDP. Where the competed project enters the conventional life cycle should be determined by the DA before award.
4.2.6.8 The Formulation Phase for competed projects is performed by the proposer either after selection (for a one-step selection process) or in their response to the solicitation (for a multiple-step selection process). Multiple-step proposals typically include a WBS, schedule, cost estimate, science content, technology requirements, and implementation strategy that serve as the equivalent of a preliminary Project Plan for the project. Proposals are reviewed and if one or more proposals are selected, this decision serves as the Project Approval KDP for those projects to proceed to the Implementation Phase at which point their life cycle becomes conventional. At this time, the project’s DA should have a detailed understanding of the resources and work plans to execute the selected project(s). As part of the Project Approval KDP, any clarifications or changes to the project’s proposal should be negotiated as part of the project’s Statement of Work (SOW). As determined by the DA, the SOW may serve as the Project Plan for competed projects, or the project may be asked to develop a Project Plan in accordance with the template in this NPR that references the SOW and addresses other aspects of project management as well. The Project Plan or equivalent SOW should include project reviews required by the DA, including CAs and IA(s). The Project Plan or SOW should also document the Closeout plan and criteria for the required Closeout KDP.
4.2.6.9 There are various management structures that can be utilized when multiple awards are given. For example, they can be managed as a single project with multiple technologies or as separate projects. The approach is at the discretion of the DA but should be determined prior to award and documented as part of the final Project Approval decision.
4.2.7 R&T Project Formulation
4.2.7.1 The project manager shall develop a Project Plan that contains, as a minimum:
a. A description of the project and its objectives.
b. How the project will be managed.
c. How the project will be monitored and controlled, including reviews.
d. The expected cost and schedule.
e. Deliverables.
4.2.7.2 The Project Plan should be of sufficient detail for the project to manage its work through the Implementation Phase and to measure its progress and performance. In addition to the required information, the plan may also include the research or technical approach, technology needs derived from mission concept studies, metrics for tracking progress, WBS, planned reviews, resource requirements (cost and institutional), a schedule showing key milestones/deliverables and the approach for transition/infusion, the risk management approach or dissemination of the project results. The customers, stakeholders, or other beneficiaries that will benefit from the project’s product as well as any specific points of contact (e.g., working groups, advisory committees) may be included in the Project Plan. The customers/beneficiaries may include projects managed under NPR 7120.5, another R&T program, another Government agency, the aeronautics and aerospace communities, or the U.S. aerospace industry. The plan may also include identification of relationships with other entities such as working groups, advisory committees, integrated product teams, technology infusion liaisons, etc. Projects should also identify and manage the test, prototype, demonstration hardware/software, firmware, and instrumentation systems and product configuration as part of all R&D Projects in a form appropriate for the size and complexity of the project.
4.2.7.3 The Project Plan may be a separate document or contained within the Program Plan as appropriate for the type and size of the projects. For projects with a stand-alone Project Plan, a template is provided in Appendix G as guidance on the expected content. Templates may also be prescribed by the governing organization.
4.2.7.4 The Project Plan is an agreement between the project DA, the program manager, and the project manager that details how the project will be managed. The Project Plan is signed by the project manager and approved by the project DA with concurrence by the program manager. If the project manager resides at a Center, the Center Director (or designee) responsible for committing workforce and facilities is added as a concurrence signatory to the Project Plan. The plan is updated as needed when major project goals or activities change or when warranted by major program changes that affect the project.
4.2.7.5 Monitoring and controlling progress includes the planned reviews (e.g., PPRs, CAs, Independent Assessments, and Peer Reviews) and the use of metrics to allow the tracking of the projects cost, schedule, and technical performance.
4.2.7.6 Cost and Schedule Metrics. The form of these metrics will vary depending on the type of project. For example, costs may be tracked using Earned Value Management (EVM) for very large projects or may be a comparison of planned costs versus actual costs. Schedule tracking may be performed using an integrated master schedule or through tracking key milestones. The metrics should be periodically reviewed to ensure the cost and schedule are progressing according to plan and are under control.
4.2.7.7 Key Performance Parameters. Technical metrics may take the form of Key Performance Parameters (KPPs) for projects that have a measurable outcome or may be tracking towards a given goal or objective for outcomes that are not directly measurable. KPPs consist of measurable parameters that would be readily understood and used by engineers concerned with the ultimate application of the technology. For each KPP, both a goal and a threshold are specified. The goal is a performance level that the project team is striving for, and the threshold is the minimum performance level that users agree is acceptable for the end item deliverable. Typically, the threshold KPP values are set beyond the current state of the art to warrant investment in the project. KPPs include information that enables assessment of the advancement of the maturity of the technology throughout the development process. The definition of a KPP includes identifying the appropriate environment and the component, subsystem, or system within which the KPP measurements are to be made.
4.2.7.8 Technology Readiness Assessment
a. As part of monitoring and controlling, the accurate assessment of technology maturity is critical to technology advancement and its subsequent incorporation into operational products. Refer to the Technology Readiness Assessment process in Appendix K and NASA-SP 6105, NASA Systems Engineering Handbook, for additional information on technology readiness assessments.
b. When a TD Project uses a measure of maturity other than Technical Readiness Level (TRLs), the measurement system should map back to TRLs. TRLs are defined in NPR 7123.1, NASA Systems Engineering Processes and Requirements.
c. An independent validation should be made of the current state of maturity. The maturity assessment should involve or be reviewed by the customer(s)/beneficiary(ies) or their representatives. The initial maturity assessment is performed in the Formulation Phase and updated at the project status reviews.
d. TRLs establish the baseline maturity of a technology at a given time. Moving to a higher level of maturity (higher TRL) requires the assessment of an entire range of capabilities for design, analysis, manufacture, and test. These additional assessments may be embodied in other measures of technology maturity such as a Technology Maturity Index (TMI) or an Advancement Degree of Difficulty (AD2), which are described in NASA/SP-2016-6105 (https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20170001761.pdf).
4.2.7.9 As part of monitoring and controlling, any critical analyses, control plans, and applicable policies needed by the project are also documented in the Project Plan. These may include:
a. A plan for acquisition of new aircraft in accordance with NPR 7900.3, Aircraft Operations Management.
b. A document of environmental compliance considerations for the National Environmental Policy Act (NEPA) per NPR 8580.1, Implementing the National Environmental Policy Act and Executive Order 12114.
c. If a project contains elements or systems that could result in harm to personnel or property:
(1) An SMA plan in accordance with NPRs 8715.3 and NPR 8705.6.
(2) A risk management plan in accordance with NPR 8000.4.
d. In some cases, these plans are already established by Center and/or facility procedures for operations such as wind tunnel tests and flight testing and do not need to be developed by the project.
e. IT controls per NPD 2810.1, NASA Information Security Policy, and NPD 1382.17, NASA Privacy Policy.
4.2.8 R&T Project Approval
4.2.8.1 Before the project can enter the Implementation Phase, the DA shall conduct the Project Approval KDP to determine the project’s readiness to proceed to Implementation and document the decision.
4.2.8.2 The DA reviews the Project Plan (or equivalent documentation) and any other relevant data requested to ensure that the project objectives are aligned with the research goals and/or stakeholder needs and that the project is well planned to meet the objectives.
a. The decision resulting from the Project Approval KDP review is documented and can be in the form of a Decision Memorandum or other documentation (depending on the type and size of the project) and becomes part of retrievable project records.
b. The decision documentation should include the decision made, rationale, effective date, and any caveats for follow-up actions associated with the decision (including responsible parties and due dates). As part of the decision documentation, the costs, schedules, and key deliverables are captured. Other information may be captured such as the project roles and responsibilities, and other key parameters can be captured along with the decision. Upon approval, the project may proceed into the Implementation Phase. This phase may be the entry point for small projects that do not need to go through the Pre-Formulation or Formulation phases.
4.2.8.3 Table 4-3 provides guidance on input and output expectations for the review to obtain approval for a project to proceed to Implementation.
Table 4-3 Project Approval Expected Inputs and Outputs
| Project Approval | |
|---|---|
| Input Expectations | Output Expectations |
| |
4.2.9 R&T Project Implementation
4.2.9.1 During the Implementation Phase, the project is implemented as described in the Project Plan and executed according to the planned cost (phasing) and schedule commitments. Project end products are developed, analyzed, verified to meet requirements, validated against stakeholder expectations, and delivered/transitioned per applicable plans. Project Status Reviews, CA Reviews, and Independent Assessments are conducted as defined in the Project Plan. The Implementation Phase culminates in the closeout activities, including data/information archiving, as needed to end the program.
4.2.9.2 For projects with a life-cycle cost (LCC) of $250 million or greater, if the project exceeds the LCC by 30 percent or more, the project manager7 shall notify the DA and program manager. At that point, the project is considered terminated. The project will need to respond to Agency direction for re-baseline consideration and potential reauthorization by Congress.
4.2.10 Conduct Reviews
4.2.10.1 As the project proceeds to mature the technology or conducts the research in the Implementation Phase, progress toward the project’s technical goals, cost, and schedule are evaluated in periodic reviews. There are two types of reviews during the Implementation Phase: PPRs and CAs.
4.2.10.2 Periodic Project Reviews
a. The project manager shall conduct PPRs to evaluate the status of the project.
b. These reviews are typically considered internal reviews, conducted by the project, to review the project cost, schedule, and technical performance. Any issues or concerns are discussed, risks reviewed, recommendations made and/or actions assigned. The frequency and timing of the PPRs are determined by the project manager in coordination with the DA and documented in the Project Plan. As desired by the project and DA, these PPRs may take the form of informal discussions or as more formal life-cycle reviews such as PDR or CDR, as described in NPR 7123.1. For small projects, a gathering of the project team and key stakeholders may suffice to discuss the project’s progress and to refine forward planning. Larger projects may need a more formal review with a wider audience and a more formal process for gathering comments, dispositioning them, and refining plans. In either case, it is important to describe the planned approach in the Project Plan (or its equivalent).
c. The PPRs for a project are documented in the Project Plan. The project manager should consider the number, frequency, and timing of these reviews (e.g., annually or at key milestones). Table 4-4 provides guidance on input and output expectations for PPRs. As project internal reviews, PPRs are not KDPs but can be combined with or the information from a PPR may feed into CAs.
Table 4-4 PPR Expected Inputs and Outputs
| Periodic Project Reviews | |
|---|---|
| Input Expectations | Output Expectations |
|
|
4.2.10.3 Continuation Assessments
a. The DA shall conduct decisional CAs. The DA is responsible for conducting the CA with projects presenting as needed.
b. CAs are KDP reviews. The number, frequency, and timing of the CAs (e.g., annually or before key events) are determined by the DA and the program manager and documented in the Project Plan. During this assessment, the technical progress summary, cost/schedule summary, top risks, relevancy to stakeholder, and continued suitability of the project end-state is determined. A discussion of what was learned, any advancements in the state of the art that was achieved, progression of the project towards its goals, any achievements that have reduced the level of uncertainty in the field, and any results from independent assessments should also be discussed. A decision to redirect, continue, or terminate the project is made then.
c. The result of a CA is documented in a Decision Memorandum or other appropriate format and is part of retrievable project records. The decision documentation should include the decision made and rationale, the effective date, any caveats for follow-up actions associated with the decision (including responsible parties and due dates). As part of the decision documentation, the costs, schedules, and key deliverables discussed are captured. Other information may be captured such as the project roles and responsibilities and other key parameters along with the decision. If the project is redirected in a significant way, the Project Plan should be updated to reflect the change. A decision to terminate a project should trigger a project closeout activity per Section 4.2.11.
d. Table 4-5 provides guidance on input and output expectations for CAs. CAs are key decision points that may be combined with or fed by information from PPRs.
Table 4-5 CA Expected Inputs and Outputs
| Continuation Assessment | |
|---|---|
| Input Expectations | Output Expectations |
|
|
4.2.11 Project Closeout
4.2.11.1 When a project achieves its goals and objectives and completes the planned mission, or if a project is terminated early, the DA shall conduct the Closeout KDP. The decision of the project DA to closeout or terminate a project and the rationale is documented in a Decision Memorandum or other appropriate retrievable project documentation, including any recommendations relevant to existing contractual relationships, disposal of assets, manpower support, and timeframe of closure process.
4.2.11.2 Table 4-6 provides guidance on input and output expectations for a Closeout KDP. A final project summary, transition and/or infusion plan is provided documenting the results of the project work. The project summary may include a description of the research and/or technology advancement, performance relative to goals and threshold requirements, technologies transferred, and TRL advancement that was accomplished, the life-cycle cost summary, dissemination/ storage/archival of project information and any lessons learned.
Table 4-6 Closeout Expected Inputs and Outputs
| Closeout | |
|---|---|
| Input Expectations | Output Expectations |
|
|
| Closeout KDP should include stakeholder/customer participation. | |
4.2.11.3 Upon review of this information, the DA can declare the project completed and assess whether the project achieved its stated goals and objectives. The DA may also want to engage the R&T community in an assessment of the science accomplishments. The failure of an R&T project can occur for the same reason as other projects: poor management, including cost overruns; no credible or measurable data results; not meeting expectations; or is not demonstrated. Through no fault of the project, a technology may lose relevancy if Agency needs change, but the achievements and knowledge gained may be useful for other projects. Note that the concept of “success” or “failure” is dependent on the nature of the project and its goals. For example, if a research project is investigating the feasibility of a possible new concept or discovery, showing that the line of work is not feasible may still be considered a success. Table 4-7 provides examples of what “success” might mean for R&T projects.
Table 4-7 Examples of Success
| Research Projects | Technology Development Projects |
|---|---|
|
|
|
|
|
|
4.2.11.4 Once the DA authorizes a project to end, closeout activities can proceed. The project manager shall provide a closeout report at the conclusion of each project. The report includes a summary of the project’s accomplishments, including an assessment of the end state and other maturity measures. If there is a decision to terminate the project during a CA, the details of what is required for closeout activities are documented in the CA decision documentation.
4.2.11.5 Project managers shall report new technologies derived from NASA R&T projects to the appropriate Center Technology Transfer Office in a timely manner in accordance with NPR 7500.2 to be considered for intellectual property protection and transfer for secondary applications.
4.2.11.6 At the conclusion of the project, the project manager shall archive data so that future users can assess the research results and technology maturity (e.g., TRL) and incorporate the research or technology into system designs or perform further investigations.
a. Archival data may include, but are not limited to, the final report from the Closeout KDP, results from independent assessments, engineering drawings, specifications, test reports, problem reports, anomalies, cost, schedule, risk mitigations, and any other documentation of project activities and results necessary for future researchers to understand the work performed resources needed, and the results that were achieved. Lessons learned are documented in accordance with NPD 7120.6.
b. For projects with products transferring to a flight project that will be performed under NPR 7120.5, careful documentation of the product configuration, pedigree, analyses performed, tests conducted, discrepancies that were noted, engineering drawings, and other information will need to be captured.
c. Documentary information produced while conducting NASA R&T projects that is suitable for preservation, as evidence of NASA organization and activities or because of the value of the information contained, regardless of format, is a Federal record and is maintained, safeguarded, and dispositioned in accordance with the guidelines of NPR 1441.1, NASA Records Management Program Requirements.
d. Except when the information is classified or subject to export control restrictions, as delineated in the Export Administration Regulations (EAR) and the International Traffic in Arms Regulations (ITAR) restrictions, the project manager should encourage peer-reviewed publication of research results or the posting of a final report external to NASA to ensure wide dissemination of publicly funded research or technology information. For some R&T projects, peer-review of published results may serve as a form of IA.
e. The project manager should encourage dissemination of new software technologies developed by the project per NPR 2210.1, Release of NASA Software.
| TOC | ChangeLog | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | AppendixF | AppendixG | AppendixH | AppendixI | AppendixJ | AppendixK | AppendixL | AppendixM | 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.