**NASA Procedural Requirements**

**NPR: 7120.7**

**Effective Date: November 3, 2008**

**Expiration Date: November 3, 2013**

**NASA Information Technology and Institutional Infrastructure Program
and Project Management Requirements**

**Responsible Office: Office of the Chief Engineer**

**TABLE OF CONTENTS**

**PREFACE**

**[CHAPTER 1. Introduction]{.underline}**

1.  Background

2.  Overview of Management Processes

3.  Document Structure

    **[CHAPTER 2. NASA Life Cycles for Institutional Infrastructure and
    Information Technology Programs and Projects]{.underline}**

```{=html}
<!-- -->
```
1.  Defining Programs and Projects

2.  Program/Project Oversight and Decision Authority

3.  IT Governance

4.  Program Life Cycle

5.  Project Life Cycles

6.  Program and Project Reviews

7.  Independent Assessment

    **[CHAPTER 3. Program and Project Management Roles and
    Responsibilities]{.underline}**

```{=html}
<!-- -->
```
1.  Roles and Responsibilities

2.  Program and Project Managers

3.  Process for Handling Dissenting Opinions

4.  Information Technology Authority

    **[CHAPTER 4. Information Technology (IT) Program and Project
    Requirements by Phase]{.underline}**

```{=html}
<!-- -->
```
1.  IT Programs -- Formulation Phase

2.  IT Programs -- Implementation Phase

3.  IT Projects -- Pre-Phase A

4.  IT Projects -- Phase A

5.  IT Projects -- Phase B

6.  IT Projects -- Phase C

7.  IT Projects -- Phase D

8.  IT Projects -- Phase E

9.  IT Projects -- Phase F

**[CHAPTER 5. Other Mission Support Investment (OMSI) Program and
Project Requirements by Phase]{.underline}**

1.  OMSI Programs -- Formulation Phase

2.  OMSI Programs -- Implementation Phase

3.  OMSI Projects -- Pre-Phase A

4.  OMSI Projects -- Phase A

5.  OMSI Projects -- Phase B

6.  OMSI Projects -- Phase C

7.  OMSI Projects -- Phase D

8.  OMSI Projects -- Phase E

9.  OMSI Projects -- Phase F

    **[CHAPTER 6. Required Gate Products at Key Decision
    Points]{.underline}**

```{=html}
<!-- -->
```
1.  Gate Products

2.  Waiver Approval Authority

    **[APPENDIX A. Definitions]{.underline}**

    **[APPENDIX B. Acronyms]{.underline}**

    **[APPENDIX C. Formulation Authorization Document
    Template]{.underline}**

    **[APPENDIX D. Program Commitment Agreement Template]{.underline}**

    **[APPENDIX E. Program Plan Template]{.underline}**

    **[APPENDIX F. Project Plan Template]{.underline}**

    **[APPENDIX G. Technical Review Entrance and Success Criteria for
    Information Technology Projects]{.underline}**

    **[DISTRIBUTION]{.underline}:**

    **NODIS**

    **PREFACE**

    **P.1 PURPOSE**

This document establishes the requirements by which NASA will formulate
and execute information technology and institutional infrastructure
programs and projects, consistent with the governance model contained in
the NASA Governance and Strategic Management Handbook (NPD 1000.0).

**P.2 APPLICABILITY**

a\. This NPR is applicable to NASA Headquarters and NASA Centers,
including Component Facilities and Technical and Service Support
Centers.

b\. This NPR is applicable to all NASA information technology and
institutional infrastructure programs and projects to include the
development of information technology capabilities, real property
(construction of facilities and environmental compliance and
restoration), and other mission support investments, as described in
section 1.1.2.

**P.3 AUTHORITY**

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

b\. NPD 7120.4, Program/Project Management.

**P.4 APPLICABLE DOCUMENTS**

a.  NID-9250, Identifying Capital Assets and Capturing Their Cost.

b.  NPD 1000.0, NASA Governance and Strategic Management Handbook.

c.  NPD 1000.3, The NASA Organization.

d.  NPD 1382.17, NASA Privacy Policy.

e.  NPD 1440.6, NASA Records Management.

f.  NPD 2800.1, Managing Information Technology.

g.  NPD 2820.1, NASA Software Policy.

h.  NPD 7120.4, Program/Project Management.

i.  NPD 8820.2, Design and Construction of Facilities.

j.  NPR 1441.1, NASA Records Retention Schedules.

k.  NPR 2800.1, Managing Information Technology.

l.  NPR 2810.1, Security of Information Technology.

m.  NPR 2830.1, NASA Enterprise Architecture Procedures.

n.  NPR 4300.1, NASA Personal Property Disposal Procedural Requirements.

o.  NPR 7150.2, NASA Software Engineering Requirements.

p.  NPR 8000.4, Risk Management Procedural Requirements.

q.  NPR 8590.1, NASA Environmental Compliance and Restoration (ECR)
    Program.

r.  NPR 8820.2, Facility Project Implementation Guide.

    **P.5 MEASUREMENT/VERIFICATION**

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

**P.6 CANCELLATION**

NPR 7120.5C, NASA Program and Project Management Processes and
Requirements, dated March 2005, is cancelled for Institutional
Infrastructure Programs and Projects.

/S/

**Michael G. Ryschkewitsch**

**Chief Engineer**

**CHAPTER 1. Introduction**

**1.1 Background**

1.1.1 NASA distinguishes programs and projects in three investment areas
or product lines: Research and Technology, Space Flight, and Information
Technology (IT) and institutional infrastructure. This document
establishes the management requirements for formulating, approving,
implementing, and evaluating NASA IT and institutional infrastructure
programs and projects consistent with the governance model contained in
NPD 1000.0, NASA Governance and Strategic Management Handbook.

1.1.2 This NPR identifies four types of IT and institutional
infrastructure investments:

a\. IT - Any equipment or interconnected system(s) or subsystem(s) of
equipment that is used in the automatic acquisition, storage, analysis,
evaluation, manipulation, management, movement, control, display,
switching, interchange, transmission, or reception of data or
information by the Agency.

\(1\) NASA distinguishes between highly specialized IT and IT that is
not highly specialized. Highly specialized IT is defined in Appendix A,
Definitions, and is subject to NPR 7120.5, NASA Space Flight Program and
Project Management Requirements, or to NPR 7120.8, NASA Research and
Technology Program and Project Management Requirements, depending on the
program or project content.

\(2\) IT programs and projects that are not highly specialized IT are
subject to the requirements of this document, unless granted a waiver by
the NASA Chief Information Officer (CIO) or the CIO of the Center making
the investment, if they meet either of the following criteria:

\(a\) If the program or project includes the development of new IT
systems or capabilities: \$500K or greater total development and
implementation cost or affects more than one Center.

\(b\) If the program or project includes modification to or enhancement
of existing IT systems or capabilities: \$500K or greater total
modification/enhancement cost, regardless of how many Centers are
affected.

\(3\) The development, modification, and enhancement of Web-based
applications (here meaning software applications that support an
Internet browser as a user interface) as a class are subject to this
document if they meet one of the above criteria. The development,
modification, and enhancement of Web sites and Web-based questionnaires
that are used solely to disseminate or collect information are not
subject to this document.

\(4\) For IT that is not highly specialized, the NASA CIO or the CIO of
the implementing Center may require a program or project to comply with
the requirements of this document even if the program or project does
not meet the above criteria. Such a decision may be made, for example,
for reasons related to high risk, high importance, or high visibility of
the program or project. In making this determination, the CIO will
consult and coordinate with the office that is sponsoring the program or
project. In the event of a disagreement, the sponsoring office may
appeal the CIO's or delegee's determination. If not resolved at a lower
level, the NASA Associate Administrator will make the final
determination. The right of appeal shall not be construed as a right to
delay or avoid the CIO's authority, i.e., appeals must be pursued
expeditiously and responsive interim plans put in place pending hearing
of the appeal.

\(5\) It is possible that programs and projects governed by NPR 7120.5,
or NPR 7120.8, will have systems under development with both highly
specialized and not highly specialized IT components, which must be
developed and integrated under a unified management structure to ensure
technical and programmatic success. Such IT components embedded in
programs and projects will also comply with policies and other technical
requirements to ensure systems and capabilities being developed align
with Agency requirements and direction for IT architectures, policies,
procedures, standards, guidelines, and practices. The Office of the CIO
will work with the Mission Directorate or Mission Support Office
responsible for the program or project to identify such embedded IT
components and define boundaries and interfaces for inclusion in IT
management processes. The Office of the CIO will also coordinate with
the appropriate Governing Body required by NPR 7120.5, or NPR 7120.8, as
described in section 2.3 of this document to reflect those interactions.

\(6\) The Mission Directorate or Mission Support Office responsible for
a program or project and the Office of the CIO will come to agreement
concerning whether particular instances of IT included in the program or
project are highly specialized or not highly specialized. The agreements
shall be documented in the program plan or project plan (or other
appropriate document) encompassing the systems of concern. In the event
that disagreements cannot be resolved at a lower level, the NASA
Associate Administrator will make the final determination.

b\. Construction of Facilities (CoF) - Construction and renovation of
facilities on NASA-controlled real property. This investment includes
facility planning, budgeting, design, construction, and activation.

\(1\) Critical technical facilities specifically developed or
significantly modified for space flight systems are subject to NPR
7120.5, and not this document.

c\. Environmental Compliance and Restoration (ECR) - Environmental
restoration and environmental management efforts.

d\. Other Mission Support Investments (OMSI) - Investments for
developing or enhancing a supporting capability for the Agency or a
Center that are not covered elsewhere in this document or under other
NPR 7120 guidance. These investments are considered to be important and
visible enough to warrant project management reporting and oversight.
Examples include Agency-wide implementation of a Presidential directive
(e.g., HSPD-12) or certification program (e.g., Voluntary Protection
Program); establishment of a centralized capability for mission support
services (e.g., transfer of new responsibilities to the NASA Shared
Services Center); or implementation of a security and program protection
project at a Center (e.g., a new emergency preparedness program).

\(1\) OMSI programs and projects are subject to the requirements of this
document if they meet either of the following criteria:

\(a\) The total development and implementation cost of the program or
project is \$1M or greater.

\(b\) The total development and implementation of the program or project
will take one year or longer.

\(2\) The Official-in-Charge of the implementing Mission Directorate or
Mission Support Office or the Center Director of an implementing Center
may require a program or project to comply with the requirements of this
document even if the program or project does not meet the above
criteria. Such a decision may be made, for example, for reasons related
to high risk, high importance, or high visibility of the program or
project.

**1.2 Overview of Management Process**

1.2.1 Management of NASA programs and projects is a four-part process
consisting of:

a\. Formulation - the assessment of feasibility, technology and
concepts, risk assessment, teambuilding, development of operations
concepts, alternatives evaluation and trade studies, acquisition
strategies, establishment of high-level requirements and success
criteria, the preparation of plans, budgets, and schedules essential to
the success of a program or project, and the identification of how the
program or project supports the Agency's strategic needs, goals,
objectives, and/or NASA Education outcomes.

b\. Approval - the acknowledgement by the responsible official (the
Decision Authority) that the program/project has met expectations and
formulation requirements and is ready to proceed to implementation.

c\. Implementation - the execution of approved plans for the
development, construction, testing, and operation of products and
services, and the use of control systems to ensure performance to
approved plans and alignment with the NASA Strategic Plan.

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

1.2.2 NASA's IT and institutional infrastructure program and project
management process is based on life cycles with key decision points at
life-cycle phase boundaries, evolving products, a decision authority, a
governance structure, and independent assessment.

1.2.3 The scope and scale of NASA IT and institutional infrastructure
programs and projects are varied. They include environmental cleanup
projects at an individual Center; Agency-wide programs such as the
Integrated Enterprise Management Program, which includes a dozen or more
financial, procurement, asset management, and human capital projects;
and educational projects such as the NASA Explorer Schools, which may be
in evaluation for ten years or more. The requirements and management
process of IT and institutional infrastructure programs and projects
take into account the scope and scale of the program or project.

**1.3 Document Structure**

1.3.1 The remainder of this document is organized as follows: Chapter 2
defines the life cycles for IT and institutional infrastructure programs
and projects, and Chapter 3 defines the roles and responsibilities of
program and project management.

1.3.2 Chapter 4 defines the requirements for IT projects.

1.3.3 The requirements for CoF projects are defined in NPD 8820.2,
Design and Construction of Facilities, and NPR 8820.2, Facility Project
Implementation Guide.

1.3.4 The requirements for ECR projects are defined in NPR 8590.1, NASA
Environmental Compliance and Restoration (ECR) Program.

1.3.5 Chapter 5 defines the requirements for OMSI projects.

1.3.6 Chapter 6 has required gate products at Key Decision Points (KDPs)
as referenced in Chapters 4 and 5 and defines the waiver process for the
requirements in this document.

1.3.7 Appendices A and B contain definitions and acronyms.

1.3.8 Appendices C through F contain templates for key program and
project management documents.

1.3.9 Appendix G contains entrance and success criteria for IT project
reviews.

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

**CHAPTER 2. NASA Life Cycles for Information Technology and
Institutional Infrastructure Programs and Projects**

**2.1 Defining Programs and Projects**

2.1.1 To support its diverse activities, NASA invests in a complex set
of supporting IT and institution and infrastructure development and
enhancement programs and projects. Programs and projects are different
and the following definitions are used to distinguish between the two:

a\. Program - a strategic investment by a Mission Directorate or Mission
Support Office that has a defined architecture and/or technical
approach, requirements, funding level, and a management structure that
initiates and directs one or more projects. A program defines a
strategic direction that the Agency has identified as needed to
implement Agency goals and objectives.

b\. Project - a specific investment having defined requirements, a
life-cycle cost, a beginning, and an end. A project also has a
management structure and may have interfaces to other projects,
agencies, and international partners. A project yields new or revised
products that directly address NASA's strategic needs.

c\. Activity - an operation that sustains NASA as an organization.
Unlike projects, which are temporary and unique, activities are ongoing
and repetitive.

d\. The term "Mission Support Office," as used in this document, refers
to any Headquarters non-Mission Directorate office that initiates a
program or project. Refer to the definition of "Mission Support Office"
in Appendix A for additional information.

2.1.2 For CoF projects, the facilities program is as described in NPR
8820.2 and should be referenced for detailed requirements for CoF
program/project management.

2.1.3 For ECR projects, the environmental program is as described in NPR
8590.1 and should be referenced for detailed requirements for ECR
program/project management.

2.1.4 The Office of the Chief Financial Officer maintains the official
database of the structure of NASA's work, which is named the Metadata
Manager (MdM). This database documents the Agency's financial Work
Breakdown Structure (WBS). At the highest level, a WBS element is
flagged as an activity or a project. An activity is an ongoing operation
to sustain NASA as an organization. IT and institutional infrastructure
elements identified as projects comply with this NPR. The Office of
Chief Engineer (OCE) approves the designation of an element as a project
or an activity. Project managers are responsible for maintaining project
attributes in MdM.

2.1.5 NASA strives to execute all programs and projects with excellence.
Management requirements and oversight should track with the investment's
magnitude and Agency priority. These factors are taken into account in
IT and institutional infrastructure program and project requirements;
the assignment of a program and project Governing Body; and
identification of the Decision Authority for the program or project. A
waiver process is established in section 6.2 to adapt the requirements
to the scope and scale of a project. The program plan and the project
plan are also used to define program and project requirements. A program
plan template is found in Appendix E. A project plan template is found
in Appendix F.

**2.2 Program/Project Oversight and Decision Authority**

2.2.1 The NASA strategic management framework has a governance
structure, which consists of three Agency-level management councils: the
Strategic Management Council (SMC), the Program Management Council
(PMC), and the Operations Management Council (OMC). The SMC is chaired
by the Administrator and determines NASA's strategic direction and
assesses Agency strategic progress. The PMC is chaired by the Associate
Administrator and assesses program and project performance. Mission
Directorate PMCs (DPMCs) support the Agency PMC. The OMC is chaired by
the Deputy Administrator and reviews and approves institutional plans.
In most cases, the OMC is the Governing Body for IT and institutional
infrastructure programs and projects; however, in exceptional cases the
PMC or the SMC may be assigned as the Governing Body. The OMC may also
delegate governance to a Mission Support Office. If the Mission Support
Office does not have an appropriate established oversight body, one will
be formed. In other cases, another institutional committee, such as the
Education Coordinating Committee, may be assigned as the Governing Body.
If a Mission Directorate has an IT and institutional infrastructure
program or project, the DPMC may be assigned as the Governing Body.

2.2.2 The Governing Body is the council, committee, board, or other
organization with the responsibility of periodically evaluating the
cost, schedule, risk, and performance of a program or project within its
purview. The evaluation focuses on whether the program or project is
meeting its commitments to the Agency. The Governing Body conducts a
review prior to each KDP and then makes recommendations to the Decision
Authority based on its findings.

2.2.3 A KDP is a point in time where the Decision Authority makes a
decision on the readiness of a program or project to progress to the
next phase of the life cycle. KDPs serve at each phase as gates through
which programs and projects must pass. Within each phase, the KDP is
preceded by one or more reviews, including a Governing Body review.
Program KDPs are designated with roman numerals, e.g., KDP II, and
project KDPs are designated with letters, e.g., KDP B.

2.2.4 The Decision Authority is the individual responsible for
authorizing the transition at a KDP to the next life-cycle phase for a
program or project. For programs and projects governed by the OMC, the
Decision Authority is the NASA Deputy Administrator. This authority can
be delegated to the Mission Support Office Official-in-Charge, usually
an Assistant Administrator. The Decision Authority may also be the
chairperson of the Governing Body.

**2.3 IT Governance**

2.3.1 The Office of the CIO has implemented a governance model that
pertains to investments in IT that are not highly specialized, as highly
specialized IT is defined in Appendix A. The governance model includes
an IT Strategy and Investment Board

(IT SIB), an IT Program Management Board (IT PMB), and an IT Management
Board (ITMB).

2.3.2 The purpose of the IT SIB is to provide a forum for senior-level
stakeholder participation in the setting of IT strategy and policy of
broad impact in terms of budget or operational capacity, as well as
prioritization of significant IT investments that align with the
strategy and mission of the Agency. The purpose of the IT PMB is to
provide a forum for high-level Agency participation in the oversight and
evaluation of Agency IT programs and projects. The purpose of the ITMB
is to make decisions regarding performance, integration, and other
issues pertaining to operational systems. The ITMB also serves as a
senior-level Configuration Control Board (CCB) for Agency infrastructure
projects, reviewing and approving high-level infrastructure
requirements.

2.3.3 The IT PMB is the Governing Body for IT programs and projects that
are in the scope of this document. The IT PMB has two levels: an Agency
IT PMB level and a Center IT PMB level. Center IT PMBs are Governing
Bodies performing the comparable functions of the Agency IT PMB, but at
the Center level. Centers may assign Center IT PMB responsibilities to a
new or existing body, e.g., the Center Management Council. Table 2-1
describes which IT PMB oversees a particular program or project.

  ---------- ------------ ---------- ---------- ------------ ------------ ------------
  Criteria   Programs\*   Projects   Projects   Projects     Projects     Projects
                          with DME   with DME   with high    with high    with high
                          cost \$1M  cost less  visibility   impact as    risk as
                          or more    than \$1M  as           determined   determined
                          (full cost (full cost determined   by NASA CIO  by NASA CIO
                          basis)     basis)     by NASA CIO               

  Agency IT  X            X                     X            X            X
  PMB                                                                     

  Center IT                          X                                    
  PMB                                                                     
  ---------- ------------ ---------- ---------- ------------ ------------ ------------

\*For programs delegated to the IT PMB by the Agency OMC or PMC; DME:
Development, Modification, or Enhancement.

Table 2-1: Scope of Agency IT PMB vs. Center IT PMB

2.3.4 The NASA CIO is the Decision Authority for programs and projects
overseen by the Agency IT PMB. The Center CIO is the Decision Authority
for programs and projects overseen by the Center IT PMBs.

2.3.5 The NASA CIO will have visibility into projects in the scope of
this document and, regardless of the criteria in the table above, may
designate oversight of a particular project to either the Agency IT PMB
or a Center IT PMB.

2.3.6 For programs and projects governed under NPR 7120.5, or NPR
7120.8, with an identified IT component subject to IT Authority, the
NASA CIO or the Center CIO, as appropriate, will include those elements
in the IT management process to ensure overall alignment within Agency
IT requirements and direction. The NASA CIO or designee will in turn
represent and/or reflect those discussions, findings, and issues with
the appropriate Governing Body under the auspices of NPR 7120.5, or NPR
7120.8, to ensure that oversight of the program or project is
rationalized to provide assistance to program and project managers in
resolving any issues. The agreement shall be documented in the program
plan or project plan (or other appropriate document) encompassing the
systems of concern. In the event that disagreements cannot be resolved
at a lower level, the NASA Associate Administrator will make the final
determination.

**2.4 Program Life Cycle**

2.4.1 NASA's strategic management approach requires that all
organizations within NASA manage requirements, schedule, and budget
according to a program and project management structure. Programs
provide the linkage between the Agency's goals and the projects that are
the means for achieving them. Programs vary in scope, complexity, cost,
and criticality; however, all programs have a life cycle that is divided
into two phases:

a\. Formulation - Pre-Program Acquisition, in which program requirements
are defined, a required funding level is established, and a plan for
implementation is designed, all consistent with the NASA Strategic Plan.

b\. Implementation - Program Acquisition, Operations, and Sustainment,
in which projects are initiated through competition or other processes
and their formulation, approval, implementation, integration, operation,
and ultimate decommissioning are constantly monitored.

2.4.2 The NASA Program Life Cycle is shown in Figure 2-1. Program
formulation and implementation require the preparation and approval (at
the appropriate level) of three key documents: a program formulation
authorization document (FAD), a program commitment agreement (PCA), and
a program plan. Each is described in subsequent paragraphs.

2.4.2.1 To initiate individual programs, a Mission Directorate or
Mission Support Office prepares a program FAD. The program FAD
authorizes a program manager to initiate the planning of a new program
and to perform the analyses required to formulate a program plan that
contains project elements, schedules, risk assessments, and budgets. A
FAD template is found in Appendix C. Because the creation of a new
program represents a major commitment of the Agency, the FAD requires
the approval of the Mission Directorate Associate Administrator (MDAA)
or Mission Support Office Official-in- Charge, usually an Assistant
Administrator. The program FAD does the following:

a\. Contains a statement of purpose for the proposed program and defines
its relationship to the Agency's strategic goals and objectives.

b\. Establishes the scope of work to be accomplished.

c\. Provides initial constraints, including resources, schedule, and
program participants within and external to NASA, as well as
international partnerships.

d\. Defines the approach and resources required to conduct program
formulation.

Figure 2-1 Information Technology and Institutional Infrastructure
Program Life Cycle

2.4.2.2 The PCA is the agreement between the MDAA or Mission Support
Office official in charge and the Decision Authority who authorizes
transition from formulation to implementation. If the MDAA is the
Decision Authority, the NASA Associate Administrator signs the PCA. If
the Mission Support Office Official-in-Charge is the Decision Authority,
the NASA Deputy Administrator signs the PCA. The PCA documents the
program's objectives, technical performance, schedule, cost, safety and
risk factors, internal and external agreements, independent reviews, and
top-level program requirements. A PCA can be considered an executive
summary of the program plan and will be updated and approved during the
program life cycle. A PCA template is found in Appendix D.

2.4.2.3 The program plan is an agreement between the MDAA or Mission
Support Office Official-in-Charge and the program manager. It documents
at a high level the program's objectives, scope, implementation
approach, the environment within which the program operates, and the
commitments of the program. The program plan is used by the program
Governing Body in the review process to determine if the program is
fulfilling its agreement. The program plan is updated and approved
during the program life cycle, as appropriate.

2.4.2.4 The program plan describes how the program will be managed and
contains the list of specific projects that are official program
elements subject to the requirements in this document. The program plan
also documents the program requirements on constituent projects. The
requirements are documented in the program plan, in an appendix to the
program plan, or in a referenced separately controlled requirements
document.

**2.5 Project Life Cycles**

2.5.1 For IT and institutional infrastructure projects, the project
life-cycle phases of formulation and implementation are further divided
into more incremental pieces that allow managers to assess progress.

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

2.5.1.2 Project implementation consists of Phases C, D, E, and F.
Approval marks the transition from Phase B of formulation to Phase C of
implementation. During Phases C (Final Design and Build) and D (System
Assembly, Integration, and Test), the primary activities are
developmental in nature, including contract execution. Phase C may
include the building and testing of components or subsystems. All
activities are executed as per the project plan developed during
formulation. The start of Phase E (Deployment, Operations, and
Sustainment) marks the transition from system development and
acquisition activities to primarily system operations and sustainment
activities. The project continues to execute the project plan, adjusted
as needed to meet Agency strategic goals. In Phase F (Decommissioning),
project systems or assets are taken out of service and safely disposed.
Independent assessment activities occur throughout the phases.

2.5.2 To initiate a project, the MDAA or Mission Support Office
Official-in-Charge, working through a program office usually provides a
small amount of discretionary resources for concept studies (i.e.,
Pre-Phase A). These pre-formulation activities involve design reference
project analyses, feasibility studies, and analyses of alternatives
(AoA) that should be performed before a specific project concept
emerges. These trade studies are not considered part of formal project
planning since there is no certainty that a specific project proposal
will emerge. In other cases, such as statute or unsolicited proposal, a
project may be initiated in Phase A.

2.5.3 The MDAA or Mission Support Office Official-in-Charge has the
authority to initiate a project and begin formulation activities. To
effect a project's official entry into formulation, the program manager
prepares a project FAD or equivalent. The project FAD is forwarded to
the MDAA or Mission Support Office Official-in-Charge for final
signature. Once the project FAD is signed, a project formally enters
formulation.

2.5.4 Working with the program manager, the project manager and the
project team develop the program requirements on the project. If
requested by the program manager, the project manager assists in
preparing a revised PCA. The project manager is then responsible for the
evolution of the project concept and ultimate project success.

2.5.5 NASA places a good deal of emphasis on project formulation because
adequate preparation of project concepts and plans is vital to success.
During formulation, the project establishes the success criteria,
including quantitative metrics, explores the full range of
implementation options, defines an affordable project concept to meet
project objectives specified in the program plan, develops needed
technologies, and develops the project plan. Formulation is an iterative
set of activities rather than discrete linear steps, and the phase may
be performed many times in the life of a project as needs and conditions
change. Formulation continues with interactive execution of its
activities, normally concurrently, until formulation output products,
like the project plan, have matured and are acceptable to the program
manager.

2.5.5.1 The project plan is an agreement between the program manager,
the MDAA or the Mission Support Office Official-in-Charge, and the
project manager, and if it is performed at a Center, the Center
Director. It defines, at a high level, the project's objectives,
technical approach, cost, schedule, risks, implementation approach, the
environment within which the project operates, and the commitments of
the program and project. The project plan is used by the project
Governing Body in the review process to determine if the project is
fulfilling its agreements. The project plan must be consistent with the
program plan. The project plan is updated and approved during the
project life cycle to reflect changes in the stated commitments or
project-level requirements.

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

2.5.6 There are specialized project life cycles for each type of IT and
institutional infrastructure project.

2.5.6.1 The CoF project life cycle consists of the formulation phases of
project planning/development and design, and the implementation phases
of Construction, Activation, Operations and Maintenance, and
Decommissioning. The CoF project life cycle is shown in Figure 2-2 and
is further described in NPR 8820.2. The figure shows the full CoF life
cycle, but facility engineering terminates at activation when the
facility is turned over to its user or owner.

Figure 2-2 CoF Project Life Cycle

2.5.6.2 The ECR project life cycle for restoration projects follows the
Environmental Cost Element Structure developed by the Environmental Cost
Engineering Committee of the Federal Remediation Technologies
Roundtable, a multiagency group that develops and shares concepts and
strategies for restoration technologies. The ECR restoration life cycle
is shown in Figure 2-3.

Figure 2-3 ECR Project Life Cycle

2.5.6.3 The IT project life cycle is shown in Figure 2-4. The Pre-Phase
A portion of the life cycle is optional; all other phases are required.
The IT project life cycle shown in Figure 2-4 is illustrated like a
"waterfall" methodology of system development. Individual projects may
find that deliverables are better met by following a different
methodology, such as iterative development or agile, that has
incremental (as opposed to waterfall) characteristics. Projects may
conduct their activities in accordance with nonwaterfall methodologies.
However, before doing so, they must present to the Governing Body, early
in the formulation phase, the proposed methodology and come to agreement
with the Governing Body concerning how the proposed methodology would
map to the project oversight requirements of this document. Chapter 4
defines the requirements for IT projects assuming a waterfall
methodology. However, the activities described in Chapter 4 will be
tailored in the project plan if an iterative development methodology is
used. Project managers should refer to NPR 7123.1, NASA Systems
Engineering Processes and Requirements, and NPR 7150.2, NASA Software
Engineering Requirements, for helpful system and software engineering
information.

![](media/image1.jpeg){width="5.998611111111111in"
height="3.6013888888888888in"}

Note: The EAPR is shown in Phase A, but, may be held at a later phase
with the agreement of the EA team.

Figure 2-4 IT Project Life Cycle Reviews and Requirements

2.5.6.4 The OMSI project life cycle is shown in Figure 2-5. Because the
scope and scale of OMSI projects vary, individual projects may be
managed to a minimal subset of the life cycle, as appropriate to the
project, agreed to between the program manager and project manager, and
documented through the waiver process described in section 6.2 and the
project plan. Chapter 5 defines the requirements for OMSI projects.

Figure 2-5 Other Mission Support Investment Project Life Cycle

**2.6 Program and Project Reviews**

2.6.1 Program reviews offer an opportunity to add value to program
products and to share knowledge by inviting outside experts who can
provide confirmation of the approach and/or recommend options. They
offer an opportunity to organize, assess, and communicate critical data
and information between providers, customers, and stakeholders. See
Table 2-2 for program review descriptions.

2.6.2 Project reviews for CoF projects are to be required as described
in NPR 8820.2.

2.6.3 Project reviews for ECR projects are to be required as described
in NPR 8590.1.

  ---------------- ---------------------------------------------------------
  **Review**       **Description**

  Program Concept  The PCDR examines the functional and performance
  and Definition   requirements defined for the program and its constituent
  Review (PCDR)    projects, and ensures that the program concept will
                   satisfy the requirements. It examines the proposed
                   program architecture and the flow down to all functional
                   elements of the program. Technology planning with
                   off-ramps (e.g., substitution of old technology) will be
                   described. The preliminary description of management
                   approach and initial budget and schedule will be
                   presented. Risk assessment and management will be
                   presented as well as the initial descope plan.

  Program          PIRs are conducted every two years to examine the
  Implementation   program's continuing relevance to the Agency's strategic
  Review (PIR)     plan, the progress to date against the approved baseline,
                   the implementation plans for current and upcoming work,
                   budget, schedule, and all risks and their mitigation
                   plans.
  ---------------- ---------------------------------------------------------

Table 2-2 IT and Institutional Infrastructure Program Reviews

2.6.4 The IT project system life cycle identifies the project reviews
associated with each phase in the IT project life cycle. In addition to
the project life-cycle reviews, there are IT project unique
reviews/assessments for enterprise architecture (EA), system
certification and accreditation, and information records management and
privacy impact. See Table 2-3 for IT system engineering project life
cycle review descriptions. All the reviews described in Table 2-3 are
required, with the exception of the system concept review. Refer to
Appendix G for information on project-appropriate tailoring of the
reviews. All Agency IT projects must adhere to the requirements of NPR
7150.2, and NPD 2820.1, NASA Software Policy.

2.6.5 NPR 2830.1, NASA Enterprise Architecture Procedures, defines a set
of criteria that determine those investments that are candidates for an
EA review, based on the significance of the investment to the Agency.
The goal of an enterprise architecture project review (EAPR) is to
ensure that projects have a fundamentally sound business foundation for
successful funding and implementation. The goal of an enterprise
architecture service review (EASR) is to ensure investments in sustained
operations, modifications, upgrades, or enhancements have a
fundamentally sound business foundation and are aligned with Agency
requirements.

  ----------------- -------------------------------------------------------
  **Review**        **Description**

  System Concept    The SCR evaluates the scope, cost benefit analysis, and
  Review (SCR)      a recommended solution/concept for the product or
                    service to be delivered for the purpose of receiving
                    approval, formalized via the Formulation Authorization
                    Document, to proceed to the Formulation Phase. It
                    assesses the effect on the "as-is" and "to-be"
                    Enterprise Architecture, and ensures applicable
                    security controls have been considered. The Pre-Phase A
                    life-cycle phase is optional, but the SCR is conducted
                    if the project includes Pre-Phase A.

  System            The SRR examines the functional**,** technical**,**
  Requirements      performance, and security requirements for the system
  Review (SRR)      and elements of the preliminary Project Plan and
                    ensures that the requirements and the selected concept
                    will satisfy the system objectives.

  Preliminary       The PDR demonstrates that the preliminary design meets
  Design Review     all system requirements with acceptable risk and within
  (PDR)             the cost and schedule constraints and establishes the
                    basis for proceeding with detailed design. It will show
                    that the correct design option has been selected,
                    interfaces have been identified, and verification
                    methods have been described.

  Critical Design   The CDR confirms that the maturity of the design is
  Review (CDR)      appropriate to support proceeding with implementation,
                    that it was developed in conjunction with stakeholders,
                    demonstrates that the design meets detailed
                    requirements, and identifies open design issues for the
                    purpose of obtaining a decision to proceed with
                    development and deployment. It reviews the technical
                    architecture to ascertain the effect on the enterprise
                    architecture and reviews the application security
                    design and the inclusion of security controls.

  Test Readiness    The TRR evaluates the project's readiness to proceed
  Review (TRR)      with testing, ensuring adequate schedule, resources,
                    and management processes are in place. It ensures the
                    completion of an integration test plan and the system's
                    readiness for execution of integration testing.

  Operational       The ORR determines that the project is ready to go-live
  Readiness Review  with the system or service: requirements have been met;
  (ORR)             the functionality, performance, and security controls
                    have been thoroughly tested; procedures are in place
                    for operations; the users have been adequately trained;
                    and, the organization responsible for operations and
                    sustaining engineering is ready to assume
                    responsibility. It ensures a security plan is in place
                    and that system authorization has been received.

  Project           The PCR provides assurance that the implemented system
  Completion Review is performing as expected and that all necessary
  (PCR)             support requirements are in place and functioning
                    properly. It confirms that the system is operating
                    properly in its production environment. It is the
                    official closeout of the project and project team. The
                    final project schedule is published and remaining open
                    risks are transferred, closed, or accepted. At the
                    conclusion of the PCR, the system is considered fully
                    operational.

  Decommissioning   The DR confirms the decision to terminate or
  Review (DR)       decommission the system and assess the readiness for
                    the safe decommissioning and disposal of system assets.
  ----------------- -------------------------------------------------------

Table 2-3 IT Project System Engineering Life-Cycle Reviews

2.6.5.1 As of the writing of this document, NPR 2830.1, requires an EAPR
prior to any new investment for projects that meet any of the following
criteria: over \$500,000 in value; affects more than one Center; affects
more than 100 people; or if it is a major investment requiring an OMB
Exhibit 300. An EASR is required to consider sustained investment or
modification/enhancement proposals for projects that meet any of the
following criteria: over \$1 million in value; affects more than one
Mission Directorate; affects more than one Center; affects more than 100
customers; or is a major investment requiring an OMB Exhibit 300. If any
of these EAPR or EASR criteria are met, the Chief Enterprise Architect
or designee must be notified, and an EA review will be scheduled.
Consult NPR 2830.1 for the most current and authoritative description of
criteria for the EAPR and EASR.

2.6.5.2 NASA requires that all projects with IT content adhere to the EA
reviews outlined in Table 2-4. Refer to NPR 2830.1, for additional
requirements on EA reviews. The authority and responsibility for
conducting an EA review is determined by the investment category and the
life-cycle stage of the investment. In addition, the participation of
enterprise architecture staff in the IT system engineering life-cycle
reviews described in Table 2.3 is encouraged to further ensure alignment
of the project with the enterprise architecture, but their participation
is not required.

  ------------- ---------------------------------------------------------
  **Review**    **Description**

  EA Project    The EAPR ensures that project proposals have a solid
  Review (EAPR) business mapping to the program goals they support,
                create new capabilities for the Agency, and ensure that
                these proposals do not create capabilities that already
                exist. A review helps ensure that key sponsors,
                executives, and stakeholders have the appropriate
                information detail to make informed investment and
                funding prioritization decisions.

  EA Service    The goal of an EASR is to ensure investments in sustained
  Review (EASR) operations, or which are undergoing modifications,
                upgrades, or enhancements, have a fundamentally sound
                business foundation, and are aligned with Agency
                requirements. This review allows key sponsors,
                executives, and stakeholders to assess the extent and
                effectiveness of that service against the program goals
                it supports.
  ------------- ---------------------------------------------------------

Table 2-4 Enterprise Architecture (EA) Reviews for all IT-Related
Projects

2.6.6 IT security risks and controls need to be planned for and factored
into all decisions during all phases of the IT project life cycle, from
Pre-Phase A through decommissioning of the system in Phase F.

2.6.6.1 IT Security assessments are required at various phases in the
system development life cycle as shown in Figure 2-4. For example, IT
risk assessments and system security categorizations should be initiated
during the formulation phase to ensure that security controls are
properly designed, developed, implemented, and verified. Additional
assessments such as system certification and accreditation are required
during the implementation phase of the life cycle to ensure that the
selected security controls are effective in the operational environment
where the information system is deployed. IT security policy and Federal
regulations also require the periodic testing and evaluation of the
security controls in an information system, to be performed with a
frequency depending on risk, but no less than annually.

2.6.6.2 NASA requires that all projects with IT content adhere to the IT
security reviews and assessments outlined in Table 2-5. Additional IT
Security activities and assessments are listed in Chapter 4 and Appendix
G. They are consistent with the IT security requirements for NASA as
described in NPR 2810.1, Security of Information Technology.

  ----------------------- -------------------------------------------------------
  **Review/Assessment**   **Description**

  Information / System    Analysis of the information types to be stored and
  Security Categorization processed in the system to address three IT security
                          objectives (Confidentiality, Integrity, and
                          Availability). Determines the potential impact that a
                          loss would have on the system or functional line of
                          business supported by the information system and the
                          level of IT security required to manage risk to an
                          acceptable level. The result of the analysis is an "IT
                          security category," validated by an appropriate NASA
                          authority.

  Security Certification  Comprehensive assessment of the management, operational
                          and technical security controls and other safeguards of
                          an IT system. Establishes the extent to which a
                          particular design and implementation meets documented
                          security requirements and any necessary remedial
                          actions.

  Security Accreditation  Formal declaration by an Authorizing Official that an
                          IT system is compliant with established security
                          requirements, that any residual risks identified during
                          the risk mitigation process are acceptable, and that
                          the system is approved to operate using a prescribed
                          set of safeguards.

  Annual Self-Assessment  Self-assessment of each system, performed at least
  of Controls             annually, to ensure that security controls are still
                          operating appropriately and that the level of risk to
                          the IT system and the information contained therein
                          remains acceptable.
  ----------------------- -------------------------------------------------------

Table 2-5 IT Security Reviews and Assessments for All Projects with IT
Systems

2.6.7 The ability to properly manage records is an important requirement
for IT systems, both to comply with Federal law and to build a history
of NASA's decisions for use by future projects. Privacy is also
essential for all IT projects that store information about individuals.
As such, all IT projects must incorporate the records management and
privacy assessment activities, as described in Chapter 4 and Appendix G.
The requirements for records management and privacy are detailed in NPR
1441.1, NASA Records Retention Schedules, and in NPR 1382.1, NASA
Privacy Procedural Requirements.

2.6.8 Project reviews for OMSI projects depend on the scale and scope of
the project. The review plan section of the project plan and the waiver
process established in section 6.2 are used to document the reviews that
will be conducted by the project. See Table 2-6 for OMSI project review
descriptions.

2.6.9 Program and project reviews identified in the life cycles are
convened by the Decision Authority (or designee) and the program or
project manager. The agenda and ground rules for the review are jointly
developed and a review board chairperson is appointed. The chairperson
organizes the review board and submits the names of proposed members to
the Decision Authority and program or project manager for joint
approval. Proposed members must be independent of the program and
project and some members must be independent of the Mission Directorate
or Mission Support Office responsible for the program or project.
Members of review boards are chosen based on their combined management,
technical, safety and mission assurance, and/or educational expertise
and/or qualifications (i.e., required certified, civil servant, etc.);
their objectivity; and their ability to make a broad assessment of the
implementation of the program or project that employs numerous technical
and other disciplines.

  ----------------- ---------------------------------------------------------
  **Review**        **Description**

  System/Project    The SCR establishes that the baseline project
  Concept Review    requirements are understood and the requirements for
  (SCR)             sub-projects (if any) have been determined. It also
                    verifies that the envisioned system/project design will
                    satisfy the requirements.

  System/Project    The SRR examines the functional and performance
  Requirements      requirements for the system/project and the preliminary
  Review (SRR)      Project Plan and ensures that the requirements and
                    selected concept will satisfy the project goals.

  Preliminary       The PDR demonstrates that the preliminary design meets
  Design Review     all system/project requirements with acceptable risk and
  (PDR)             within cost and schedule constraints, and establishes the
                    basis for proceeding with detailed design. It will show
                    that a correct design option has been selected and
                    verification methods have been described. Baseline costs
                    and schedules, as well as all risk assessment, management
                    systems, and metrics, will be presented.

  Critical Design   The CDR demonstrates that the maturity of the design is
  Review (CDR)      appropriate to support proceeding with full-scale
                    fabrication, assembly, integration, and test, and that
                    the technical effort is on track to complete the system
                    development and operations in order to meet performance
                    requirements within the identified cost and schedule
                    constraints. Progress against management plans, budget,
                    and schedule, as well as risk assessment will be
                    presented.

  Operational       The ORR examines the actual system characteristics, test
  Readiness Review  results, and the procedures used in the system or
  (ORR)             product's operation and ensures that all system and
                    support hardware, software, personnel, procedures, and
                    user documentation accurately reflects the deployed state
                    of the system.

  Decommissioning   The purpose of the DR is to confirm the decision to
  Review (DR)       terminate or decommission the system and assess the
                    readiness for the safe decommissioning and disposal of
                    system assets.
  ----------------- ---------------------------------------------------------

Table 2-6 OMSI Project Reviews

2.6.10 The MDAA, Mission Support Office Official-in-Charge or program
manager may also require special reviews as the need is determined.
Circumstances that may warrant these special reviews include variances
with respect to technical, cost or schedule requirements, inability to
develop an enabling technology, or some unanticipated change to the
program or project baseline. The process followed for these reviews is
the same as for other reviews. The review team will be dissolved
following resolution of the issue(s) that triggered the review.

2.6.11 For all types of projects in the scope of this document, if the
Decision Authority is considering the termination of a project at any
time in Phases B, C, D, or E, then a special termination KDP may be
requested. Circumstances such as the anticipated inability of the
project to meet its commitments, an unanticipated change in Agency
strategic planning, or an unanticipated change in the NASA budget may be
instrumental in triggering a termination KDP. The Decision Authority
commissions an Independent Assessment (IA), and following its
completion, the project Governing Body holds a Termination Review.

**2.7 Independent Assessment (IA)**

2.7.1 IAs occur as part of the program and project KDP processes. The
Decision Authority works with the program manager, project manager, and
the cognizant individuals within the Mission Directorate or Mission
Support Office, and the Office of Program Analysis and Evaluation, as
necessary, in developing the IA agenda and ground rules and selecting
the review chairperson. Review team members are independent of the
program and project line of authority. Program and project IAs are
separate from the program and project reviews and are generally
conducted in conjunction with them.

2.7.2 The first program IA is the Program Approval Review (PAR) which
occurs in conjunction with or following the PCDR. This assessment is
conducted to ensure that major issues are understood and resolved prior
to KDP I where program approval is given. The purpose and description of
this review is listed in Table 2-7.

2.7.3 Other program IAs are conducted at least every two years following
program approval. The IA looks at program performance and adherence or
progress to meeting Agency goals.

  ----------------- -----------------------------------------------------
  **Review**        **Description**

  Program Approval  The PAR examines the overall program concept, its
  Review (PAR)      relevance to the Agency strategic plan, the technical
                    and management approaches, and the readiness of the
                    program to provide oversight into the formulation of
                    the initial project(s) of the program. Key criteria
                    include: the feasibility and maturity of the
                    Technical Concept/Program Architecture; clarity,
                    completeness, and consistency of the program
                    requirements, and the flow down of these requirements
                    to initial and subsequent projects; the state of
                    interface identification; identification of
                    technology development needs; identification of risks
                    and mitigation approaches; program test and
                    verification policy; adequacy of resources to
                    implement the initial project(s) in the program,
                    including budget, reserves, and reserves policies;
                    sufficiency of program management staffing and
                    control mechanisms to manage initial and future
                    constituent projects and satisfy external
                    communication and reporting requirements throughout
                    the expected lifetime of the program.
  ----------------- -----------------------------------------------------

Table 2-7 Information Technology and Institutional Infrastructure
Program Approval Review

2.7.4 The first required project IA is the Non-Advocate Review (NAR) and
occurs in conjunction with or following the PDR. In addition, for all
new major projects with IT ("major IT projects"), OMB has directed an
Independent Validation for Reasonableness (IVR) of cost, schedule, and
performance objectives before beginning project development. This
requirement also applies to ongoing major IT projects that have
development, modernization, and enhancement efforts. NASA implements
this requirement as part of the NAR. The criteria for what constitutes a
major IT project changes from year to year depending upon the Agency's
needs and guidance provided by OMB. Typical criteria include
high-executive visibility or special management attention needed due to
its importance to the NASA mission/function (regardless of cost),
significant program or policy or privacy implications, a financial
management support system that will obligate more than \$500,000
annually, and others. The NASA Office of the CIO (OCIO), working in
conjunction with its IT governance structure, designates a particular
project as a major IT project during the capital planning process when
the initial decision is made to approve the formation of a project.
Following that determination, the OCIO informs the program/project
manager that the project is a major IT project and that an IVR and
additional reporting associated with a major IT project are required.
Since the criteria for a major IT project may change from year to year,
the OCIO may inform a program/project manager that a project which has
been underway for some time is now considered to be a major IT project
and that the IVR and additional reporting may be required, based on
where the project is in its life cycle. Table 2-8 provides the purpose
and description of the project NAR.

2.7.5 Other project IAs generally occur with or following project
reviews. The IAs look at project cost, schedule and performance, and
risk management processes. The required project IAs are documented in
the review plan section of the project plan. For large-scale projects
(\>250M LCC), an IA is required for each KDP. Project IAs may also be
required to support special reporting requirements from external sources
such as OMB and NASA authorization and appropriations laws.

2.7.6 If the Decision Authority is considering the termination of a
project in Phases B, C, D, or E, then an IA is conducted for the
termination KDP.

2.7.7 Results of all IAs culminate at the Governing Body review where
the program, project, Mission Directorate or Mission Support Office, and
the IA team present their status, findings, and recommendations.

  ---------------- ------------------------------------------------------
  **Review**       **Description**

  Non-Advocate     The NAR is an independent review of projects conducted
  Review (NAR)     at the end of Formulation (Phase B). It provides
                   Agency management with an independent assessment of
                   the project to proceed to Implementation (Phase C).
                   The review provides the Governing Body with
                   information that assists it in making recommendations
                   to the Decision Authority. For major IT projects, this
                   review also includes the IVR. Upon successful
                   completion of this review process, a project baseline
                   is established. Review criteria include assessment of
                   the project's preliminary design, plans for
                   implementation, and final implementation
                   documentation.
  ---------------- ------------------------------------------------------

Table 2-8 Information Technology and Institutional Infrastructure
Project Non-Advocate Review

**CHAPTER 3. Program and Project Management Roles and Responsibilities**

**3.1 Roles and Responsibilities**

3.1.1 The roles and responsibilities of senior management are defined in
NPD 1000.0, and NPD 1000.3, The NASA Organization. The key roles and
responsibilities specific to program and projects consistent with the
process described in section 1.2 can be summarized as follows:

a\. NASA Administrator - approves assignment of large (greater than
\$100 million) projects to performing organizations such as Mission
Support Offices or Centers.

b\. NASA Deputy Administrator - responsible for operations at the Agency
level, chairs the OMC, is the KDP Decision Authority for programs and
projects governed by the OMC, and approves the PCA for projects governed
by the OMC.

c\. NASA Associate Administrator - responsible for the technical and
programmatic integration of program portfolios at the Agency level,
chairs the Agency PMC, is the KDP Decision Authority for programs and
projects governed by the Agency PMC, and approves the PCA for projects
governed by the Agency PMC.

d\. Chief Engineer - responsible for policy, oversight, and assessment
of NASA engineering and program/project management capabilities, and
principal advisor to the Administrator on matters pertaining to the
technical capability and readiness of NASA programs and projects.

e\. Mission Directorate Associate Administrator - responsible for
managing program portfolios within the Mission Directorate, is the KDP
Decision Authority for programs and projects governed by the Mission
Directorate, and is responsible for all budgets, schedules, program
requirements, and program requirements on projects within the Mission
Directorate.

f\. Chief, Safety and Mission Assurance - assures the existence of
robust safety and mission assurance processes and activities through the
development, implementation, assessment, and functional oversight of
safety, reliability, maintainability, and quality policies and
procedures; serves as principal advisor to the Administrator and other
senior officials on safety, reliability, maintainability, and quality
assurance matters; performs independent program and project compliance
verification audits; and implements the SMA technical authority process.

g\. Mission Support Office Official-in-Charge - responsible for managing
program portfolios within the Mission Support Office, is the KDP
Decision Authority for programs and projects governed by the Mission
Support Office, and is responsible for all budgets, schedules, program
requirements, and program requirements on projects within the Mission
Support Office.

h\. NASA Chief Information Officer (CIO) - responsible for ensuring that
NASA's information assets are acquired and managed consistent with
Federal policies, procedures, and legislation and that the Agency's
Information Resource Management (IRM) strategy is in alignment with
NASA's vision, mission, and strategic goals, is principal advisor to the
Administrator on matters pertaining to IRM, and is responsible for
establishing IT policies, promoting standards, and developing a secure
architecture to support scientific, engineering, and administrative
information requirements. Implements the Information Technology
Authority process and serves as the Institutional Authority for
Information Technology as described in section 3.4.

i\. Center CIO - responsible for ensuring that Center IT plans, support,
services, architectures, policies, procedures, standards, guidelines,
and practices support the Agency's missions in a manner that aligns with
Federal and Agency requirements and directions, and in particular,
aligns with the Agency enterprise architecture. Supports the Agency CIO
in accordance with the NASA IT governance model.

j\. Program Manager - responsible for the formulation and implementation
of the program per the governing agreement with the sponsoring Mission
Directorate or Mission Support Office and all applicable NPDs, NPRs, and
other Agency policy documents.

k\. Project Manager - responsible for the formulation and implementation
of the project per the governing agreement with the program manager.

**3.2 Program and Project Managers**

3.2.1 The program manager works in concert with the project manager, who
may be supported by one or more NASA Centers. Each, however, is
responsible and accountable to the Mission Directorate and/or Mission
Support Offices for the safety, technical integrity, performance, and
success of the program or project, while also meeting programmatic (cost
and schedule) commitments and institutional requirements. Accomplishing
this requires a breadth and depth of skills, so the program and project
manager must be knowledgeable about governing laws, acquisition
regulations, policies affecting the project, training of direct-report
personnel, risk management, resource management, test facilities,
software management, and other aspects of program and project
management.

3.2.2 It is important for the program manager and project manager to
coordinate early and throughout the project's life cycle with mission
support organizations at NASA Headquarters and the Centers involved in
development and/or implementation of the program/project. These mission
support organizations include legal, procurement, security, finance,
export control, human resources, public affairs, international affairs,
property, facilities, environmental, IT security, and others. They
provide essential expertise and ensure compliance with relevant laws,
treaties, executive orders, and regulations.

3.2.3 The program and project manager establish periodic status
reporting processes and mechanisms. Project thresholds are established
for cost and schedule, which if exceeded, the project manager will
provide immediate written notice to the program manager. These
thresholds are documented in the project plan.

**3.3 Process for Handling Dissenting Opinions**

3.3.1 NASA teams must have full and open discussions with all facts made
available in order to understand and assess issues. Diverse views are to
be fostered and respected in an environment of integrity and trust with
no suppression or retribution.

3.3.2 Unresolved issues of any nature (e.g., programmatic, safety,
engineering, acquisition, accounting, etc.) within teams should be
quickly elevated to achieve resolution at the appropriate level. At the
discretion of the dissenting person(s), a decision may be appealed to
the next higher level of management for resolution.

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

3.3.4 Management's decision/action on the memorandum (or oral
presentation) is documented and provided to the dissenter and to the
notified managers and becomes part of the program/project record. If the
dissenter is not satisfied with the process or outcome, the dissenter
may appeal to the next higher level of management. The dissenter has the
right to take the issue upward in the organization, even to the NASA
Administrator, if necessary.

**3.4 Information Technology Authority**

3.4.1 NPD 1000.0, describes Mission Support Authorities as the
designated "official voices" of their institutional areas and the
associated requirements established by NASA policy, law, or other
external mandate. These authorities are asserted through leadership,
horizontally (across Headquarters) and vertically (Headquarters to
Centers, and within Centers). The NASA CIO exercises Mission Support
Authority for IT, and is the "IT Authority." The corresponding process
is designated as IT authority (where "authority" is not capitalized, to
distinguish between the process and the person exercising the
authority).

3.4.2 The need for IT authority stems from the inclusion and importance
of IT in almost all Agency programs and projects. The scope of IT
authority includes all IT with the exception of software engineering.
The Office of the Chief Engineer establishes policy and technical
standards for software engineering and has included software engineering
in its engineering technical authority process. The Office of Safety and
Mission Assurance establishes the policy and technical standards for
software safety and software assurance.

3.4.3 The requirements levied by this document on IT programs and
projects in its scope constitute the exercise of IT authority in the
area of program and project management. Additional aspects of IT
authority will be included in NPR 2800.1, Managing Information
Technology.

**CHAPTER 4. Information Technology (IT) Program and Project
Requirements by Phase**

**4.1 IT Programs - Formulation Phase**

4.1.1 Purpose: The purpose of program formulation activities is to
establish a cost-effective program that meets Agency and Mission
Directorate/Mission Support Office goals and objectives. The program FAD
authorizes a program manager to initiate the planning of a new program
and to perform the analyses required to formulate a program plan. Major
reviews leading to approval at KDP-I are the PCDR, and the program
Governing Body review (see Figure 2-1) .

#### 4.1.2 Requirements: During program formulation, the program manager and the program team shall:

a\. Support the Mission Directorate or Mission Support Office in
developing and obtaining approval of the FAD, PCA, and the Planning,
Programming, Budgeting, and Execution (PPBE) process.

b\. Prepare and obtain approval of the program plan that follows the
template in Appendix E.

c\. Obtain approval of interagency and international agreements.

d\. Plan, prepare for, and conduct a PCDR.

e\. Develop all required KDP-I gate products as indicated in Table 6-1.

f\. Plan, prepare for, and support the program Governing Body review
prior to KDP-I.

## 4.2 IT Programs - Implementation Phase 

#### 4.2.1 Purpose: During implementation, the program manager works with the stakeholders and the constituent projects to execute the program plan in a cost-effective manner on schedule. PIRs and periodic independent assessments ensure that the program continues to contribute to Agency and Mission Directorate or Mission Support Office goals and objectives within funding constraints.

#### 4.2.2 Requirements: During program implementation, the program manager and the program team shall:

a\. Execute the program plan.

b\. Conduct planning, program-level systems engineering, and
integration, as appropriate to the program.

c\. Support the Mission Directorate or Mission Support Office in
initiating the projects selection process.

d\. Support the MDAA or Mission Support Office Official-in-Charge in the
selection of projects, either assigned or through a competitive process.

e\. Approve project FADs and project plans.

f\. Plan, prepare for, and conduct biennial PIRs.

g\. Support Governing Body reviews prior to KDP-II, -III, -IV, etc.

h\. Support the MDAA or Mission Support Office Official-in-Charge in
updating the PCA.

i\. Update the program plan.

j\. Provide oversight of the projects within the program and report
their status periodically.

k\. Review project PPBE process inputs and prepare program PPBE process
input.

l\. Develop technologies and common solutions that cut across multiple
projects within the program.

m\. Develop all required gate products as indicated in Table 6-1 prior
to KDP-II, -III, -IV, etc.

n\. Plan, prepare for, and support the program Governing Body reviews
prior to

KDP-II, -III, -IV, etc.

## 4.3 IT Projects -- Pre-Phase A

#### 4.3.1 Purpose: During Pre-Phase A, a pre-project team studies a broad range of system-enabling concepts that contribute to program and Mission Directorate or Mission Support Office goals and objectives. These advanced studies along with interactions with customers and other potential stakeholders help identify a promising concept and tentative project-level requirements. The team conducts an enterprise architecture review with the NASA Chief Enterprise Architect or designee and assesses project alignment with gaps in the "As-Is" and "To-Be" architectures. These activities are focused toward a SCR and KDP-A. Pre-Phase A is optional; all other phases of the IT project life cycle are required.

4.3.2 Requirements: If a Pre-Phase A is conducted, then the pre-project
manager and team shall:

a\. Obtain an approved project FAD.

b\. Support the program manager in the development of the preliminary
program requirements on the project.

c\. Consider naming an Information System Security Official to assist
the team in identifying IT security issues with candidate system
concepts. Naming an Information System Security Official at this phase
of the project is optional, but recommended.

d\. Develop a preliminary system concept.

e\. Working with the Agency or Center Enterprise Chief Architect staff,
conduct an assessment of how the system fits into NASA's EA.

f\. Perform a preliminary IT security risk assessment of the system in
accordance with NPR 2810.1, Security of Information Technology.

g\. Prepare a preliminary assessment of the security categorization of
the information to be hosted on the system, as required by NPR 2810.1.

h\. Plan, prepare for, and conduct the SCR shown in Figure 2-4 in
accordance with Appendix G of this document.

i\. Baseline work agreements for Phase A.

j\. Prepare all required KDP-A gate products identified in Table 6-2.

k\. Plan, prepare for, and support the project Governing Body review
prior to KDP-A.

## 4.4 IT Projects -- Phase A

4.4.1 Purpose: During Phase A, a project team is formed to fully develop
a system concept and begin development of needed technologies. This
work, along with interactions with customers and other potential
stakeholders, helps to finalize a system concept and the project-level
requirements. These activities take place in preparation for SRR. The
phase culminates in KDP-B.

4.4.2 Requirements: During Phase A, the project manager and project team
shall:

a\. Obtain an approved project FAD, if a pre-Phase A was not conducted.

b\. During this and subsequent life-cycle phases, follow the
requirements of NASA Interim Directive (NID)-9250, Identifying Capital
Assets and Capturing Their Costs.

c\. Support the program manager in the development of the baseline
program requirements on the project.

d\. Establish the project structure.

e\. Name an Information System Security Official responsible for
ensuring that the information system complies with Federal and NASA IT
security requirements.

f\. Initiate the development of Memorandums of Understanding
(MOUs)/Memorandums of Agreement (MOAs) with domestic external partners,
as needed.

g\. Work with the program manager and HQ Office of External Relations to
initiate international agreements, as needed.

h\. Complete an AoA and select a preferred, baseline system concept.

i\. Develop preliminary system-level (and lower-level, as needed)
requirements.

j\. Develop a preliminary system operations concept.

k\. Working with the Agency or Center Enterprise Chief Architect staff,
determine how the system interfaces with, replaces, and/or supports
other systems documented in the NASA EA.

l\. Prepare the preliminary software development/management plan
required by

NPR 7150.2.

m\. Plan, prepare for, and conduct the SRR shown in Figure 2-4 in
accordance with Appendix G of this document.

n\. Plan, prepare for, and conduct the EAPR described in NPR 2830.1.

o\. Conduct the Information/System Security Categorization required by
NPR 2810.1.

p\. Further assess the information to be hosted on the system,
including:

\(1\) Determining if the system data includes personally identifiable
information and thus requires privacy protection in conformance with
statutes governing privacy information and enabling Agency policy.

\(2\) Developing or selecting the records retention for all information
related to the project and to be hosted on the system in accordance with
the requirements of NPR 1441.1.

q\. Determine the IT security controls that apply to the system in
accordance with

NPR 2810.1.

r\. Prepare a preliminary project plan that follows the template in
Appendix F.

s\. For contracts requiring Earned Value Management (EVM) (see Appendix
F, paragraph 3.1.e), conduct required Integrated Baseline Reviews
(IBRs).

t\. Develop and document a preliminary integrated baseline for all work
to be performed by the project that includes the following:

\(1\) A preliminary high-level WBS and associated WBS dictionary,
preliminary integrated master schedule, preliminary life-cycle cost
estimate, workforce estimates, and the project's technical baseline, all
consistent with the program requirements levied on the project.

\(2\) The preliminary life-cycle cost estimate uses the latest available
full-cost accounting guidance and practices, and including IT security
costs.

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

\(4\) The preliminary cost estimate is to be time-phased by Government
Fiscal Year (GFY) to WBS Level 2:

\(i\) For internal use software projects, develop the Level 2 WBS to
meet the requirements of NASA's Financial Management Requirements (FMR)
Volume 6, Chapter 4, 041206, Accounting, Property Plant and Equipment,
Software Policies and Procedures -- Capitalization.

u\. Incorporate life-cycle risk management principles in the project
plan in accordance with NPR 8000.4, Risk Management Procedural
Requirements.

v\. Working with the appropriate support organizations, develop an
initial IT infrastructure assessment of project needs and Agency-wide
and external capabilities to meet infrastructure needs.

w\. Baseline work agreements for Phase B.

x\. Develop all required KDP-B gate products as indicated in Table 6-2.

y\. Plan, prepare for, and support the project Governing Body review
prior to KDP-B.

## 4.5 IT Projects -- Phase B

4.5.1 Purpose: During Phase B, the project team completes its
preliminary design and technology development. These activities are
focused toward completing the project plan and PDR. In addition, the NAR
is supported prior to briefing the project Governing Body. The phase
culminates in KDP-C.

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

a\. Support the program manager in the update of the baseline program
requirements on the project.

b\. Finalize external agreements, such as interagency and international
agreements, procurements, MOUs, and facility resources.

c\. Implement the preliminary project plan.

d\. Develop the top-level system preliminary technical architecture,
identifying the

"as-is" and "to-be" architectures as they relate to the NASA EA.

e\. Baseline the system-level requirements and develop the subsystem and
lower-level technical requirements leading to the PDR baseline.

f\. Develop a set of system and associated subsystem preliminary
designs, including interface definitions, and document this work in a
preliminary design document.

g\. Develop the baseline operations concept.

h\. Complete make-or-buy decisions and initiate long-lead procurements.

i\. Conduct risk analyses and use the results to make IT risk informed
design decisions in accordance with NPR 8000.4, and document the
decisions in the risk management control part of the project plan.

j\. Develop a list of descope options, if applicable.

k\. Update the preliminary software development/management plan required
by

NPR 7150.2.

l\. Plan, prepare for, and conduct the PDR shown in Figure 2-4 in
accordance with Appendix G of this document.

m\. Complete and obtain approval of the baseline project plan that
follows the template in Appendix F.

n\. Develop, document, and maintain a project baseline integrated
baseline for all work performed by the project:

\(1\) The project's integrated baseline includes the project WBS and has
an associated WBS dictionary.

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

\(3\) The baseline life-cycle cost estimate uses the latest available
full-cost accounting guidance and practices, and includes IT security
costs.

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

\(5\) The baseline life-cycle cost estimate is to be time-phased by GFY
to WBS Level 2:

\(i\) For internal use software projects, develop the Level 2 WBS to
meet the requirements of NASA's FMR Volume 6, Chapter 4, 041206,
Accounting, Property Plant and Equipment, Software Policies and
Procedures -- Capitalization.

o\. For contracts requiring EVM, conduct required IBRs.

p\. Conduct the IT security risk assessment for the system required by
NPR 2810.1.

q\. Determine whether the project is subject to an IVR based on criteria
issued by the NASA OCIO and posted on the OCIO Web site. For those
projects subject to an IVR, prepare for and support the IVR as part of
the NAR.

r\. Plan, prepare for, and support the NAR independent review team.

s\. Baseline work agreements for Phase C.

t\. Develop the gate products required for KDP-C as indicated in Table
6-2.

u\. Plan, prepare for, and support the project Governing Body review
prior to KDP-C.

## 4.6 IT Projects -- Phase C

4.6.1 Purpose: During Phase C, the project completes the design that
meets the detailed requirements, begins early production of system
components requiring long-lead time, and makes acquisitions that may be
required.

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

a\. Implement the baseline project plan.

b\. Develop the baseline system technical architecture, identifying the
"as-is" and "to-be" architectures as they relate to the NASA EA.

c\. Develop baseline software architecture and detailed designs,
including the design of IT security controls required by NPR 2810.1.

d\. Develop/procure long lead-time software and hardware.

e\. Develop requisite system and subsystem test beds needed for
qualification and acceptance testing of the system(s).

f\. Initiate the qualification and acceptance testing of systems and/or
subsystems.

g\. Initiate all operational support and other enabling developments
(e.g., facilities, equipment, updated databases), including a
preliminary operations handbook to support the operations team.

h\. Plan, prepare for, and conduct the CDR shown in Figure 2-4 in
accordance with Appendix G of this document.

i\. Implement EVM as documented in the project plan.

j\. For contracts requiring EVM, conduct required IBRs.

k\. Develop the preliminary training plan and training materials.

l\. If the latest development cost Estimate at Completion (EAC) of the
project or a schedule milestone listed on the project life-cycle chart
in Figure 2-4 varies from the integrated baseline more than agreed upon
thresholds, provide immediate written notice and a recovery plan to the
program manager. These thresholds are documented in Section 3.1 of the
project plan.

m\. Use continuous risk management principles to manage IT risks in
accordance with NPR 8000.4.

n\. Update the project plan that follows the template in Appendix F.

o\. Baseline work agreements for Phase D.

p\. Develop the gate products required for KDP-D as indicated in Table
6-2.

q\. Plan, prepare for, and support the project Governing Body review
prior to KDP-D.

## 4.7 IT Projects -- Phase D

4.7.1 Purpose: During Phase D, the project performs system coding,
assembly, integration, and test.

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

a\. Implement the project plan.

b\. Prepare baseline test plans, test procedures, and test cases.

c\. Initiate coding, system assembly, integration, and test.

d\. Resolve all test, analysis, and inspection discrepancies.

e\. Document and implement all technical, management, and operational
security controls as required by NPR 2810.1.

f\. Prepare "as-built" and "as-deployed" hardware and software
documentation.

g\. Update the project plan that follows the template in Appendix F,
including finalizing the IT security plan.

h\. Complete all operational support and other enabling developments
(e.g., facilities, equipment, updated databases), including a baseline
operations handbook and a plan to transition system operations to the
operations team.

i\. Develop the baseline training plan and training materials.

j\. Conduct operational tests and training, including normal and
anomalous scenarios.

k\. Submit any changes to the system description for inclusion in the
NASA EA.

l\. Meet the IT security certification and accreditation requirements
specified in

NPR 2810.1.

m\. Plan, prepare for, and conduct the TRR and ORR shown in Figure 2-4
in accordance with Appendix G of this document.

n\. Establish and maintain an integrated logistics support capability,
including spares and system maintenance and operating procedures.

o\. Implement EVM as documented in the project plan.

p\. For contracts requiring EVM, conduct required IBRs.

q\. If the latest development cost EAC of the project or a schedule
milestone listed on the project life-cycle chart in Figure 2-4 varies
from the integrated baseline more than agreed upon thresholds, provide
immediate written notice and a recovery plan to the program manager.
These thresholds are documented in Section 3.1 of the project plan.

r\. Use continuous risk management principles to manage IT risks in
accordance with NPR 8000.4.

s\. Baseline work agreements for the Phase E.

t\. Develop the gate products required for KDP-E as indicated in Table
6-2.

u\. Plan, prepare for, and support the project Governing Body review
prior to KDP-E.

## 4.8 IT Projects -- Phase E

4.8.1 Purpose: During Phase E, the project deploys and operates the
system developed in previous phases. During this phase, the project team
that developed the system typically turns over responsibility for
operation of the system to an operations team.

4.8.2 Requirements: During Phase E, the project manager, the project
team, and/or the operations team shall:

a\. Implement the project plan.

b\. Deploy and operate the system.

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

d\. Continuously monitor the system to ensure IT security controls are
working properly and to detect and deter attempts to breach controls.

e\. Update the training plan and training materials.

f\. Provide sustaining engineering as necessary to enhance efficiency,
reduce costs, repair software problems, increase capacity, and take
advantage of the benefits of new technology.

g\. Document lessons learned.

h\. Conduct an annual IT security assessment of the system in
conformance to the requirements of NPR 2810.1.

i\. Re-certify the system every three years following the NIST standards
for IT security certification as required by NPR 2810.1.

j\. Update the "As-Is" and the "To-Be" information for this system in
the NASA EA annually, as necessary.

k\. Track the risks and mitigations identified in pre-Phase A and as
updated in later phases.

l\. Plan, prepare for, and support the EASR as shown in Figure 2-4 in
accordance with the requirements of NPR 2830.1.

m\. Prepare and document the system decommissioning/disposal
requirements and plans in accordance with NPR 4300.1, NASA Personal
Property Disposal Procedural Requirements, and the official records
associated with the project in accordance with NPR 1441.1.

n\. Use continuous risk management principles to manage IT risks in
accordance with NPR 8000.4.

o\. Baseline work agreements for Phase F.

p\. Plan, prepare for, and conduct the PCR, including the project
completion report, as shown in Figure 2-4 in accordance with Appendix G
of this document.

q\. Develop the gate products required for KDP-F as indicated in Table
6-2.

r\. Plan, prepare for, and support the project Governing Body review
prior to KDP-F.

## 4.9 IT Projects -- Phase F

4.9.1 Purpose: During Phase F, the project implements the system
decommissioning/

disposal plan.

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

a\. Plan, prepare for, and conduct the DR shown in Figure 2-4 in
accordance with Appendix G of this document.

b\. Safely and in accordance with applicable laws and regulations,
dispose of project system assets.

c\. Disposition all records and information only in accordance with the
applicable records retention schedule items from NPR 1441.1.

**CHAPTER 5. Other Mission Support Investment (OMSI) Program and Project
Requirements by Phase**

**5.1 OMSI Programs - Formulation Phase**

5.1.1 Purpose: The purpose of program formulation activities is to
establish a cost-effective program that meets Agency and Mission
Directorate/Mission Support Office goals and objectives. The program FAD
authorizes a program manager to initiate the planning of a new program
and to perform the analyses required to formulate a program plan. Major
reviews leading to approval at KDP-I are the PCDR, and the program
Governing Body review.

#### 5.1.2 Requirements: During program formulation, the program manager and the program team shall:

a\. Support the Mission Directorate or Mission Support Office in
developing and obtaining approval of the FAD, PCA, and the PPBE process.

b\. Prepare and obtain approval of the program plan that follows the
template in Appendix E.

c\. Obtain approval of interagency and international agreements, as
needed.

d\. Plan, prepare for, and conduct a PCDR.

e\. Develop all required KDP-I gate products as indicated in Table 6-1.

f\. Plan, prepare for, and support the program Governing Body review
prior to KDP-I.

## 5.2 OMSI Programs - Implementation Phase 

#### 5.2.1 Purpose: During implementation, the program manager works with the stakeholders and the constituent projects to execute the program plan in a cost-effective manner. PIRs and periodic independent assessments ensure that the program continues to contribute to Agency and Mission Directorate or Mission Support Office goals and objectives within funding constraints.

#### 5.2.2 Requirements: During program implementation, the program manager and the program team shall:

a\. Execute the program plan.

b\. Conduct planning, program-level systems engineering, and
integration, as appropriate to the program.

c\. Support the Mission Directorate or Mission Support Office in
initiating the projects selection process.

d\. Support the MDAA or Mission Support Office Official-in-Charge in the
selection of projects, either assigned or through a competitive process.

e\. Approve project FADs and project plans.

f\. Plan, prepare for, and conduct biennial PIRs.

g\. Support Program Governing Body reviews prior to KDP-II, -III, -IV,
etc.

h\. Support the MDAA or Mission Support Office Official-in-Charge in
updating the PCA.

i\. Update the program plan.

j\. Provide oversight of the projects within the program and report
their status periodically.

k\. Review project PPBE process inputs and prepare program process
input.

l\. Develop technologies and common solutions that cut across multiple
projects within the program.

m\. Develop all required gate products as indicated in Table 6-1 prior
to KDP-II, -III, -IV, etc.

n\. Plan, prepare for, and support the program Governing Body reviews
prior to

KDP-II, -III, -IV, etc.

**5.3 OMSI Projects -- Pre-Phase A**

#### 5.3.1 Purpose: During Pre-Phase A, a pre-project team studies a broad range of project concepts that contribute to program and Mission Directorate or Mission Support Office goals and objectives. These advanced studies along with interactions with customers and other potential stakeholders help identify a promising project-enabling concept and tentative project-level requirements. The team also identifies potential technology needs and assesses the gaps between such needs and current technology plans. These activities are focused toward a SCR and KDP-A. Pre-Phase A for OMSI projects is optional.

5.3.2 Requirements: If a Pre-Phase A is conducted, then the pre-project
manager and team shall:

a\. Obtain an approved project FAD.

b\. Support the program manager in the development of the preliminary
program requirements on the project.

c\. Develop a preliminary system/project concept.

d\. Develop a risk list and mitigation concepts.

e\. Plan, prepare for, and conduct the SCR.

f\. Baseline work agreements for Phase A.

g\. Prepare all required KDP-A gate products indicated in Table 6-2.

h\. Plan, prepare for, and support the project Governing Body review
prior to KDP-A.

## 5.4 OMSI Projects -- Phase A

#### 5.4.1 Purpose: During Phase A, a project team is formed to fully develop a project concept and begin development of needed technologies. This work, along with interactions with customers and other potential stakeholders, helps finalize a project concept and the project-level requirements. These activities are focused toward System/Project Requirements Review. The phase culminates in KDP-B. Phase A activities for OMSI projects of small scale or scope may be combined with Phase B activities with the approval of the program manager. 

5.4.2 Requirements: During Phase A, the project manager and project team
shall:

a\. Obtain an approved project FAD, if a pre-Phase A was not conducted.

b\. Support the program manager in the development of the baseline
program requirements on the project.

c\. Establish the project structure and controls.

d\. Initiate the development of MOUs/MOAs with domestic external
partners, as needed.

e\. Work with the program manager and HQ Office of External Relations to
initiate international agreements, as needed.

f\. Prepare a preliminary project plan that follows the template in
Appendix F.

g\. Complete an AoA and select a preferred baseline system/project
concept.

h\. Develop a preliminary system/project operations concept.

i\. Develop preliminary project requirements.

j\. Working with the appropriate support organizations, develop an
initial IT infrastructure assessment of project needs and Agency-wide
and external capabilities to meet infrastructure needs.

k\. Plan, prepare for, and conduct the SRR.

l\. Finalize work agreements for Phase B.

m\. Develop all required KDP-B gate products indicated in Table 6-2.

n\. Plan, prepare for, and support the project Governing Body review
prior to KDP-B.

## 5.5 OMSI Projects -- Phase B

5.5.1 Purpose: During Phase B, the project team completes its
preliminary design and technology development. These activities are
focused toward completing the project plan and PDR. In addition, the NAR
process is invoked prior to the project Governing Body review. The phase
culminates in KDP-C.

5.5.2 Requirements: During Phase B, the project manager and the project
team shall:

a\. Support the program manager in the update of the baseline program
requirements on the project.

b\. Finalize external agreements, such as interagency and international
agreements, procurements, MOUs, and facility resources.

c\. Implement the preliminary project plan.

d\. Finalize a project control tool set that includes a WBS and cost,
schedule, and periodic status reporting processes and mechanisms.

e\. Baseline project requirements.

f\. Develop the project preliminary technical architecture.

g\. Develop the project preliminary designs.

h\. Develop the baseline operations concept.

i\. Plan, prepare for, and conduct the PDR.

j\. Identify any risk drivers and proposed mitigation plans for each
risk.

k\. Complete and obtain approval of the baseline project plan that
follows the template in Appendix F.

l\. Plan, prepare for, and support the NAR independent review team.

m\. Baseline work agreements for Phase C.

n\. Develop the gate products required for KDP-C indicated in Table 6-2.

o\. Plan, prepare for, and support project Governing Body review prior
to KDP-C.

## 5.6 OMSI Projects -- Phase C

5.6.1 Purpose: During Phase C, the project completes the design that
meets the detailed requirements, begins early production of project
components requiring long-lead time, and makes acquisitions that may be
required.

5.6.2 Requirements: During Phase C, the project manager and the project
team shall:

a\. Implement the baseline project plan.

b\. Baseline the project technical architecture.

c\. Develop and test all requisite prototypes.

d\. Initiate all operational support and other enabling developments
(e.g., facilities, equipment), including a preliminary operations
handbook to support the operations team.

e\. Develop/procure long lead-time project components.

f\. Develop the preliminary training plan and training materials.

g\. Plan, prepare for, and conduct the CDR.

h\. Update the project plan that follows the template in Appendix F.

i\. Baseline work agreements for Phase D.

j\. Develop the gate products required for KDP-D as indicated in Table
6-2.

k\. Plan, prepare for, and support the project Governing Body review
prior to KDP-D.

## 5.7 OMSI Projects -- Phase D

5.7.1 Purpose: During Phase D, the project performs project component
assembly, integration, and test.

5.7.2 Requirements: During Phase D, the project manager and the project
team shall:

a\. Implement the project plan.

b\. Prepare baseline test plans, test procedures, and test cases.

c\. Initiate project component build, assembly, integration, and test.

d\. Resolve all integration and test discrepancies.

e\. Update the project plan that follows the template in Appendix F.

f\. Prepare "as-built" or "as-deployed" documentation.

g\. Develop the baseline training plan and materials.

h\. Complete all operational support and other enabling developments
(e.g., facilities, equipment, updated databases), including a baseline
operations handbook.

i\. Conduct operational tests and training.

j\. Plan, prepare for, and conduct the ORR.

k\. Baseline work agreements for Phase E.

l\. Develop the gate products required for KDP-E as indicated in Table
6-2.

m\. Plan, prepare for, and support the project Governing Body review
prior to KDP-E.

## 5.8 OMSI Projects -- Phase E

5.8.1 Purpose: During Phase E, the project implements the operations
plan developed in previous phases.

5.8.2 Requirements: During Phase E, the project manager and the project
team shall:

a\. Implement the project plan.

b\. Deploy and execute the project.

c\. Update the training plan and training materials.

d\. Document lessons learned.

e\. Prepare and document systems decommissioning/disposal requirements
and plans.

f\. Baseline work agreements for Phase F.

g\. Develop the gate products required for KDP-F as indicated in Table
6-2.

h\. Plan, prepare for, and support the project Governing Body review
prior to KDP-F.

## 5.9 OMSI Projects -- Phase F

5.9.1 Purpose: During Phase F, the project implements the project
decommissioning plan.

5.9.2 Requirements: During Phase F, the project manager and the project
team shall:

a\. Plan, prepare for, and conduct the DR.

b\. Safely and in accordance with all laws and regulations, dispose of
project assets.

**CHAPTER 6. Required Gate Products at Key Decision Points**

**6.1 Gate Products**

6.1.1 There are defined program and project management products (and
their maturities) expected to be completed before each KDP. These
products include documented project plans, design information, technical
analyses, project metrics, and documentation of independent assessments.
Program and project managers assemble this information in an orderly
manner for presentation and discussion at the reviews prior to the KDPs.

Table 6-1 lists the gate products required for programs and describes
their required maturity by KDP and major program review. Table 6-2 lists
the gate products required for IT and OMSI projects and describes their
required maturity by KDP and major project review. Products marked as
"Updated" must be analyzed by the program or project, and any required
changes made prior to the KDP. The date markings of the documents and
their revision histories must be changed to indicate that the analysis
occurred, even if changes to the content of the documents were not
needed.

  ----------------------- ----------------- -------------------- ----------- ----------
  **NPR 7120.7 Program                                                       
  Gate Products**                                                            

  **Products**            **Formulation**   **Implementation**               

                          **KDP I**         **KDP II**           **KDP III** **KDP n**

  FAD                     Approved                                           

  PCA                     Approved          Updated              Updated     Updated

  Program Plan            Approved          Updated              Updated     Updated

  Interagency and         Approved                                           
  International                                                              
  Agreements                                                                 

  PCDR Products           Final                                              

  PIR Products                              Final                Final       Final
  ----------------------- ----------------- -------------------- ----------- ----------

Table 6-1 Program Gate Products Maturity Matrix

**6.2 Waiver Approval Authority**

6.2.1 Waivers to requirements in this NPR may be granted by the
officials shown in Tables 6-3, 6-4, and 6.5. Waivers are used to adapt
the requirements to the scope and scale of Information Technology and
Institutional Infrastructure programs and projects.

6.2.2 Waivers with dissent are reviewed and dispositioned by the NASA
Deputy Administrator for programs and projects with a life-cycle cost
equal to or greater than 10 million dollars and by the OCE, cognizant
MDAA or Mission Support Office Official-in- Charge for all other
programs and projects, depending on the life-cycle cost.

  ------------------------ -------------- ------------- ------------- -------------- ---------- ---------- -------
  **NPR 7120.7 Project                                                                                     
  Gate Products**                                                                                          

  Products                 Pre-Phase A    Phase A       Phase B       Phase C        Phase D    Phase E    Phase F

                           KDP A          KDP B         KDP C         KDP D          KDP E      KDP F      

                           SCR            SRR           PDR           CDR            TRR/ ORR   PCR        

  **Project Planning,                                                                                      
  Cost, Schedule, and                                                                                      
  Communication Products**                                                                                 

  1\. FAD                  Approved       Approved (if                                                     
                                          there was no                                                     
                                          Pre-Phase A)                                                     

  2\. Program Requirements Preliminary    Baseline      Updated                                            
  on the Project                                                                                           

  3\. Work Agreements for  Baseline       Baseline      Baseline      Baseline       Baseline   Baseline   
  next phase                                                                                               

  4\. Integrated Baseline                 Preliminary   Baseline                                           

  5\. Governing Body       Final          Final         Final         Final          Final      Final      
  Review products                                                                                          

  6\. Software                            Preliminary   Final                                              
  Development/Management                                                                                   
  Plan as required by NPR                                                                                  
  7150.2, NASA Software                                                                                    
  Engineering Requirements                                                                                 
  (IT Projects only)                                                                                       

  7\. Project Plan (refer                 Preliminary   Baseline      Updated        Updated               
  to Chapter 4; Appendix F                                                                                 
  provides a template;                                                                                     
  individual sub-plans can                                                                                 
  be stand-alone                                                                                           
  documents)                                                                                               

  **Project Technical                                                                                      
  Products**                                                                                               

  1\. System Concept       Preliminary    Baseline                                                         

  2.Information/System      Preliminary   Baseline                                                         
  Security Categorization                                                                                  
  (IT Projects Only)                                                                                       

  3\. System Level                        Preliminary   Baseline                                           
  Requirements                                                                                             

  4\. System Technical                                  Preliminary   Baseline                             
  Architecture                                                                                             

  5\. Operations Concept                  Preliminary   Baseline                                           

  6\. Preliminary Design                                Baseline                                           

  7\. Detailed Design                                                 Baseline                             

  8\. Test Plan, Test                                                                Baseline              
  Procedures, and Test                                                                                     
  Cases                                                                                                    

  9\. Training Plan and                                               Preliminary    Baseline   Updated    
  Training Materials                                                                                       

  10\. As-built and                                                                  Baseline              
  As-deployed Hardware and                                                                                 
  Software Documentation                                                                                   

  11\. Operations Handbook                                             Preliminary   Baseline              

  12\. Project Completion                                                                       Final      
  Report                                                                                                   

  13\. Decommissioning                                                                                     Final
  Plan                                                                                                     
  ------------------------ -------------- ------------- ------------- -------------- ---------- ---------- -------

Table 6-2 Project Gate Products Maturity Matrix

  --------------- ----------- ------- -------- -------- --------- ----------- -------
  **IT Project                                                                
  Certification                                                               
  Products (IT                                                                
  Projects                                                                    
  Only)**                                                                     

  Products        Pre-Phase A Phase A Phase B  Phase C  Phase D   Phase E     Phase F

                  KDP A       KDP B   KDP C    KDP D    KDP E     KDP F       

  1\.             Final       Final   Final    Final    Final     Final       
  Certification                                                               
  that project is                                                             
  ready to                                                                    
  transition to                                                               
  the next phase                                                              

  2\. IT Security                                       Initial   Triennial   
  Certification                                                   renewal     
  and                                                                         
  Accreditation                                                               
  of System                                                                   
  --------------- ----------- ------- -------- -------- --------- ----------- -------

Table 6-2 Project Gate Products Maturity Matrix (continued)

Note: The products shown in Table 6-2 are a minimal set. Depending on
the nature of the project, other products (e.g., a Disaster Recovery
Plan) called out in other policy documents may be required.

6.2.3 Requests for waivers to requirements in this NPR are documented
and submitted for approval using the NPR 7120.7 Waiver Form. Prior to
the KPD I for programs and KDP B and KDP C for projects, these requests
may be documented and attached to a single waiver to assure proper
routing and control. Waivers impacting formulation or

requiring long lead time may be submitted individually early in
formulation. Following KDP I for programs and KDP C for projects,
waivers must be submitted individually to the appropriate authorities.

  --------- --------- --------- -------------- ----- -------- ----------------
  Project   Project   Program   MDAA or        CIO   OCE &    Approval
  Type      Manager   Manager   Mission              OSMA     Authority for
                                Support Office                Waivers with
                                Official-in-                  Dissent
                                Charge                        

  IT        R         A         A              A     A        NASA Deputy
                                                              Administrator

  OMSI      R         A         A                    A        NASA Deputy
                                                              Administrator
  --------- --------- --------- -------------- ----- -------- ----------------

R = Recommends A = Approves I = Informed

Table 6-3 Waiver Approval for Programs and Projects ≥ \$10 million
Life-Cycle Cost (LCC)

  --------- --------- --------- --------------- ----- -------- --------------
  Project   Project   Program   MDAA or Mission CIO   OCE &    Approval
  Type      Manager   Manager   Support Office        OSMA     Authority for
                                Official-                      Waivers with
                                in-Charge                      Dissent

  IT        R         A         A               A     I        OCE

  OMSI      R         A         A                     A\*      OCE
  --------- --------- --------- --------------- ----- -------- --------------

R = Recommends A = Approves I = Informed

\*If the project is implemented at a Center, Center level SMA Approval
is required.

Table 6-4 Waiver Approval for Programs and Projects ≥ \$1 million but
\<\$10M LCC

  --------- --------- --------- -------------------- ----- -------- --------------------
  Project   Project   Program   MDAA or Mission      CIO   OCE &    Approval Authority
  Type      Manager   Manager   Support Office             OSMA     for Waivers with
                                Official-in-Charge                  Dissent

  IT        R         A         I                    I              MDAA or Mission
                                                                    Support Office
                                                                    Official-in-Charge

  OMSI      R         A         I                          A\*      MDAA or Mission
                                                                    Support Office
                                                                    Official-in-Charge
  --------- --------- --------- -------------------- ----- -------- --------------------

R = Recommends A = Approves I = Informed

\*If the project is implemented at a Center, Center level SMA Approval
is required.

Table 6-5 Waiver Approval for Programs and Projects \< \$1 million LCC

6.2.4 Waivers to requirements in NPRs referenced in this NPR may be
granted according to the process established by the NPR's Responsible
Office.

NPR 7120.7 Waiver Form

+-----------------------------+-------------------+----+-----+--------+
| Name of Program or Project  | Date of Request:  | Da |     |        |
| Requesting Waiver:          |                   | te |     |        |
|                             |                   | Wa |     |        |
|                             |                   | iv |     |        |
|                             |                   | er |     |        |
|                             |                   | is |     |        |
|                             |                   | N  |     |        |
|                             |                   | ee |     |        |
|                             |                   | de |     |        |
|                             |                   | d: |     |        |
+-----------------------------+-------------------+----+-----+--------+
| Name and Organization of    | Requirement to be |    |     |        |
| Initiator :                 | Waived:           |    |     |        |
+-----------------------------+-------------------+----+-----+--------+
| Project Deliverable         | Waiver To:        |    |     |        |
| Affected:                   |                   |    |     |        |
|                             | € Policy €        |    |     |        |
|                             | Procedure €       |    |     |        |
|                             | Requirement €     |    |     |        |
|                             | Other             |    |     |        |
|                             |                   |    |     |        |
|                             | € Additional      |    |     |        |
|                             | information is    |    |     |        |
|                             | attached          |    |     |        |
+-----------------------------+-------------------+----+-----+--------+
| Original Requirement of     |                   |    |     |        |
| Document to be Waived (list |                   |    |     |        |
| Appropriate Sections or     |                   |    |     |        |
| Text):                      |                   |    |     |        |
+-----------------------------+-------------------+----+-----+--------+
| Waiver Requested:           |                   |    |     |        |
+-----------------------------+-------------------+----+-----+--------+
| Reason/Justification        |                   |    |     |        |
| (Attach additional          |                   |    |     |        |
| information, if necessary): |                   |    |     |        |
+-----------------------------+-------------------+----+-----+--------+
| Risk Assessment of the      |                   |    |     |        |
| Program and Project if      |                   |    |     |        |
| Waiver is Approved:         |                   |    |     |        |
+-----------------------------+-------------------+----+-----+--------+
| Required Signatures         | Signature         |    | D   | Ap     |
|                             |                   |    | ate | proved |
|                             |                   |    |     | (Y     |
|                             |                   |    |     | es/No) |
+-----------------------------+-------------------+----+-----+--------+
| Project Manager             |                   |    |     |        |
+-----------------------------+-------------------+----+-----+--------+
| Program Manager             |                   |    |     |        |
+-----------------------------+-------------------+----+-----+--------+
| Mission Directorate AA or   |                   |    |     |        |
| Mission Support Office      |                   |    |     |        |
| Official-in-Charge (if      |                   |    |     |        |
| needed)                     |                   |    |     |        |
+-----------------------------+-------------------+----+-----+--------+
| NASA Chief Information      |                   |    |     |        |
| Officer (if needed)         |                   |    |     |        |
+-----------------------------+-------------------+----+-----+--------+
| NASA Chief Engineer (if     |                   |    |     |        |
| needed)                     |                   |    |     |        |
+-----------------------------+-------------------+----+-----+--------+
| Safety and Mission          |                   |    |     |        |
| Assurance                   |                   |    |     |        |
+-----------------------------+-------------------+----+-----+--------+
| NASA Deputy Administrator   |                   |    |     |        |
| (if needed)                 |                   |    |     |        |
+-----------------------------+-------------------+----+-----+--------+

# APPENDIX A. Definitions

**Acceptable Risk**. The risk that is understood and agreed to by the
program/project, program/project Governing Body, Mission Directorate
and/or Mission Support Office, and other customer(s) sufficient to
achieve the defined success criteria within the approved level of
resources.

**Activity**. An operation that sustains NASA as an organization. Unlike
projects, which are temporary and unique, activities are ongoing and
repetitive.

**Acquisition.** The acquiring, by contract, of supplies or services
(including construction) through purchase or lease, whether the supplies
or services are already in existence or must be created, developed,
demonstrated, or evaluated. Acquisition begins at the point when Agency
needs are established and includes the description of requirements to
satisfy Agency needs, solicitation, and selection of sources, award of
contracts, contract financing, performance, administration, technical,
and management functions directly related to the process of fulfilling
Agency needs by contract.

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

**Analysis of Alternatives (AoA).** A formal analysis method that
compares alternatives by estimating their ability to satisfy mission
requirements through an effectiveness analysis and by estimating their
life-cycle costs (LCC) through a cost analysis. The results of these two
analyses are used together to produce a cost-effectiveness comparison
that allows decision makers to assess cost and effectiveness
simultaneously. An AoA broadly examines multiple elements of
program/project alternatives (including technical performance, risk,
LCC, and programmatic aspects), and is typically an important part of
formulation studies. The terms, trade studies, trades, and tradeoff
analyses, are often used in lieu of AoA, when the scope of the analysis
is more limited.

**Approval.** The acknowledgement by the responsible official that the
program/project has met expectations and formulation requirements and is
ready to proceed to implementation.

**Certification.** A confirmation in formal documentation that an
accepted standard has been met.

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

**Concurrence.** The individual(s) reviewing and providing agreement
within their span of responsibility of a document, product, or service
that has yet to be approved.

**Contract.** A mutually binding legal relationship obligating the
seller to furnish the supplies or services (including construction) and
the buyer to pay for them. In addition to bilateral instruments,
contracts include, but are not limited to: awards and notices of awards;
job orders or task letters initiated under basic ordering agreements;
letter contracts; orders, such as purchase orders, under which the
contract becomes effective by written acceptance or performance; and
bilateral contract modifications.

**Customer.** Any individual, organization, or other entity to which a
program or project provides a product(s) and/or service(s).

**Decision Authority**. The individual responsible for evaluating IA and
program and project Governing Body recommendations, assessing program
and project deliverables, and making the decision at a KDP that
authorizes a program or project to transition to the next life-cycle
phase.

**Earned Value Management (EVM).** A tool for measuring and assessing
project performance through the integration of technical scope with
schedule and cost objectives during the execution of the project. EVM
provides quantification of technical progress, enabling management to
gain insight to project status and project completion costs and
schedules. Two essential characteristics of successful EVM are EVM
system data integrity and carefully targeted monthly EVM data analyses
(i.e., risky WBS elements).

**Enterprise Architecture (EA).** An explicit description and
documentation of the current and desired relationships among business
and management processes and information technology. An EA includes
principles, an architecture framework, a technical standards profile,
current and target architectures, and a transition strategy to move from
the current to target architecture.

**Environmental Impact.** The direct, indirect, or cumulative beneficial
or adverse effect of an action on the environment.

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

**Estimate at Completion.** The sum of project actual costs to date,
estimated to complete (ETC), and reserves. Contractor financial
information is included in the project Estimate at Completion.

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

**Formulation.** The assessment of feasibility, technology and concepts,
risk assessment, team building, development of operations concepts and
acquisition strategies, establishment of high-level requirements and
success criteria, the preparation of plans, budgets, and schedules
essential to the success of a program or project, and the identification
of how the program or project supports the Agency's strategic needs,
goals, and objectives.

**Formulation Authorization Document (FAD).** The document issued by the
MDAA or Mission Support Office Official-in-Charge to authorize the level
of formulation of a program whose goals will fulfill part of the
Agency's Strategic Plan, Mission Directorate Strategies, or Mission
Support Office Functional Leadership Plans. In addition, a FAD or
equivalent is used to authorize the level of formulation of a project.

**Governing Body.** The council, committee, or other Agency body that
has responsibility for the oversight of programs and projects,
conducting reviews before KDPs, and making recommendations to the
program and project Decision Authority on the program or project
readiness to transition to the next phase of the program or project life
cycle. In many cases it is the OMC for IT and institutional
infrastructure programs and projects.

**Highly Specialized Information Technology**. Highly specialized IT is
a part of, internal to, or embedded in a Mission platform. The
platform's function (e.g., avionics, guidance, navigation, flight
controls, simulation, radar, etc.) is enabled by IT but not driven by IT
itself (e.g., computer hardware and software to automate internal
functions of a spacecraft or spacecraft support system such as
spacecraft control and status, sensor signal and data processing, and
operational tasking.) Highly specialized IT acquisitions may include
full development (where the information technology is a primary issue)
to modification of existing systems (information architecture is firm
and demonstrated in an operational environment) where information
technology is not an issue. Real time is often critical - and few
opportunities exist to use Commercial Off The Shelf (COTS) or Government
Off The Shelf (GOTS) beyond microprocessors and operating systems
because these systems are largely unprecedented or largely unique
applications. Certain IT are considered mission critical because the
loss would cause the stoppage of mission operations supporting real-time
on-orbit mission operations and are identified as "highly specialized"
by the Directorate Associate Administrator. Highly specialized IT is
largely custom, as opposed to COTS or commodity IT systems or
applications, and includes coding/applications that are integral parts
of the research or science requirements, e.g., Shuttle Avionics Upgrade.
Common engineering IT tools such as Product Lifecycle Management (PLM)
systems, Computer-Aided Design (CAD) systems, and collaborative
engineering systems and environments are not highly specialized IT.

Representative examples of highly specialized IT include:

Avionics software, real-time control systems, onboard processors, Deep
Space Network, spacecraft instrumentation software, wind tunnel control
system, human physiology monitoring systems, ground support environment,
experiment simulators, Mission Control Center, and launch cameras.

**Implementation.** The execution of approved plans for the development
and operation of programs and projects, the establishment of control
systems to ensure performance to plan, and alignment with current Agency
strategies.

**Independent Assessment (IA).** The general term referring to an
evaluation of a program or project conducted by experts outside the
advocacy chain. Specifically, a review or evaluation that results in an
assessment of the program's or project's readiness (technical, schedule,
cost, risk) to proceed to the next phase in the life cycle that is
reported to a program or project Governing Body and Decision Authority.

**Information Technology (IT).** Any equipment or interconnected
system(s) or subsystem(s) of equipment that is used in the automatic
acquisition, storage, analysis, evaluation, manipulation, management,
movement, control, display, switching, interchange, transmission, or
reception of data or information by the Agency.

**Information Technology Authority.** The articulation of the role in
the IT governance model of the Mission Directorates in relation to that
of the Agency and Center CIOs and the checks and balances between them.

**Integrated Baseline.** The project's technical performance and
content, technology application, schedule milestones, and budget. The
integrated baseline includes the WBS, WBS Dictionary, integrated master
schedule, preliminary life-cycle cost estimate, and workforce estimate,
consistent with the program requirements on the project.

**Integrated Baseline Review (IBR).** An IBR is a review that includes
total project (contracted as well as in-house NASA) efforts. It is
conducted jointly with personnel responsible for the efforts.
Specifically, an IBR verifies that the technical content of the
performance measurement baseline is consistent with the contract scope,
work breakdown structure, and actual budget and schedule; ensures that
effort personnel have identified all risks and are aware of their
responsibilities for their management; ensures that there is a logical
sequence of effort planned consistent with the contract schedule;
ensures the disciplined implementation of all project EVMS; establishes
a forum through which the program/project manager and the technical
staff gain a sense of ownership of the cost/schedule management process;
and establishes the baseline for the life of the contract.

**Internal Use Software.** Software that is COTS, internally developed
or contractor developed to meet NASA\'s internal needs, e.g., financial
and administrative software, or communications software independent of a
mission (space flight and associated ground support), with a projected
life-cycle cost of \$1,000,000 or more and a useful life of five years
or more.

**Investment.** Resources, usually funding, along with a decision on how
to apply those resources that results in a capability, product, or
service that helps NASA achieve its Mission. Generally, the benefits of
an investment exceeds the cost of the investment.

**Key Decision Point (KDP).** The event at a point in time in the
program or project life cycle, usually at the end of a program or
project life-cycle phase, when the program or project Decision Authority
makes the decision (or not) to authorize the program or project to
transition to its next life-cycle phase. Program KDPs are designated
with Roman numerals, e.g., KDP II, and project KDPs are designated with
letters,

e.g., KDP B.

**Lessons Learned.** The significant knowledge or understanding gained
through past or current programs and projects that is documented and
collected to benefit current and future programs and projects.

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

**Margin.** The difference between the resource allocation to a cost,
schedule, or technical performance parameter and the current actual or
expected value of the parameter.

**Metric.** A measurement taken over a period of time that communicates
vital information about a process or activity. A metric should drive
appropriate action.

**Mission Directorate**. A primary implementer of a NASA mission area.
Each Mission Directorate is led by an Associate Administrator who leads
their respective mission area. Listed in the order they appear on the
NASA organizational chart, the current Mission Directorates are as
follows: Aeronautics Research Mission Directorate, Exploration Systems
Mission Directorate, Science Mission Directorate, and Space Operations
Mission Directorate.

**Mission Support Office.** Headquarters organizations that establish
and disseminate policy and leadership strategies within assigned areas
of responsibility in support of all NASA programs and activities. Refer
to NPD 1000.3, for the list of offices included in this designation. As
used in this document, the term refers to any Headquarters non-Mission
Directorate office that initiates a program or project.

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

**OMB Exhibit 300.** Exhibit 300, also called the Business Case, is the
mechanism by which the Office of Management and Budget (OMB) measures an
agency\'s level of compliance with laws and mandated management
practices in its investment portfolio of major Information Technology
and capital asset investments. OMB uses the Exhibit 300 to make both
quantitative decisions about budgetary resources consistent with the
Administration's program priorities and qualitative assessments about
whether the Agency's programming processes are consistent with OMB
policy and guidance.

**Program.** A strategic investment by a Mission Directorate or Mission
Support Office that has a defined architecture and/or technical
approach, requirements, funding level, and a management structure that
initiates and directs one or more projects. A program defines a
strategic direction that the Agency has identified as critical.

**Program Commitment Agreement (PCA).** The contract between the
Associate Administrator and the cognizant Mission Directorate or Mission
Support Office for implementation of a program.

**Program Management Council (PMC).** One of the hierarchy of forums
composed of senior management that assesses program or project planning
and implementation, and provides oversight and direction as appropriate.
These are established at the Agency or Mission Directorate levels.

**Program Plan.** The document that establishes the baseline for
implementation, signed by the MDAA or Mission Support Office
Official-in-Charge, Center Director(s) (if appropriate), and program
manager.

**Program (Project) Team.** All participants in program (project)
formulation and implementation. This includes all direct reports and
others that support meeting program (project) responsibilities.

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

**Project Plan.** The document that establishes the baseline for
implementation, signed by the cognizant program manager, Center Director
(if appropriate), and project manager.

**Project Success Criteria.** Standards against which the program or
project will be deemed a success. Project success criteria may be both
qualitative and quantitative, and may cover mission cost, schedule, and
performance results, as well as actual mission outcomes.

**Quality Assurance.** A planned and systematic set of actions necessary
to provide confidence that the products or services conform to
documented requirements.

**Reserves.** Resources (funding, schedule, performance, manpower, and
services) held back by a project manager, which can be allocated for
expansion, unforeseen events, or other project adjustments when they
occur.

**Risk.** The combination of the probability that a program or project
will experience an undesired event (some examples include a cost
overrun, schedule slippage, malicious activities, environmental impact,
failure to achieve a needed technological breakthrough or project
success criteria) and the consequences, impact, or severity of the
undesired event, were it to occur. Both the probability and consequences
may have associated uncertainties.

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

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

**Safety.** Freedom from those conditions that can cause death, injury,
occupational illness, damage to or loss of equipment or property, or
damage to the environment.

**Security.** Protection of people, property, and information assets
owned by NASA which covers physical assets, personnel, IT,
communications, and operations.

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

**Success Criteria.** That portion of the top-level requirements that
define what will be achieved to successfully satisfy the Strategic Plan
objectives addressed by the program, project, or technology
demonstration.

**System.** The combination of elements that function together to
produce the capability required to meet a need. The elements include all
hardware, software, equipment, facilities, personnel, processes, and
procedures needed for this purpose.

**Systems Engineering.** A disciplined approach for the definition,
implementation, integration, and operation of a system (product or
service). The emphasis is on achieving stakeholder functional, physical,
and operational performance requirements in the intended use
environments over its planned life within cost and schedule constraints.
Systems engineering includes the engineering processes and technical
management processes that consider the interface relationships across
all elements of the system, other systems, or as a part of a larger
system.

**Termination Review.** A review initiated by the Decision Authority for
the purpose of securing a recommendation as to whether to continue or
terminate a program or project. Exceeding the parameters or levels
specified in controlling documents will result in consideration of a
termination review.

**Validation.** Proof that the product accomplishes the intended
purpose. May be determined by a combination of test, analysis, and
demonstration.

**Verification.** Proof of compliance with specifications. May be
determined by a combination of test, analysis, demonstration, and
inspection.

**Waiver.** A written authorization granting relief from a requirement
that results in more risk than is inherent in the original requirement.
Waivers grant permanent or temporary relief after the original
requirement is baselined for the specific product or process.

**Work Agreement.** A formal agreement between the program/project and
its supporting organizations, prepared for each program/project cost
account and used to document agreements and commitments for the work to
be performed, including scope of work, receivables/deliverables,
schedule, budget, and assumptions.

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

# APPENDIX B. Acronyms

AoA Analysis of Alternatives

CCB Configuration Control Board

CDR Critical Design Review

CIO Chief Information Officer

CoF Construction of Facilities

COOP Continuity of Operations Planning

DR Decommissioning Review

DME Development, Modification, or Enhancement

EA Enterprise Architecture

EAPR Enterprise Architecture Project Review

EAC Estimate at Completion

EASR Enterprise Architecture Service Review

ECR Environmental Compliance and Restoration

EVM Earned Value Management

EVMS Earned Value Management System

FAD Formulation Authorization Document

FMR Financial Management Requirements

FAR Federal Acquisition Regulation

GFY Government Fiscal Year

IA Independent Assessment

IBR Integrated Baseline Review

IRM Information Resource Management

IT Information Technology

ITMB Information Technology Management Board

IVR Independent Validation for Reasonableness

KDP Key Decision Point

LCC Life-Cycle Cost

MDAA Mission Directorate Associate Administrator

MdM Metadata Manager

MOA Memorandum of Agreement

MOU Memorandum of Understanding

NAR Non-Advocate Review

NFS NASA Federal Acquisition Regulation (FAR) Supplement

NOA New Obligational Authority

NPD NASA Policy Directive

NPR NASA Procedural Requirements

OCE Office of Chief Engineer

OMC Operations Management Council

OMSI Other Mission Support Investments

O&M Operations and Maintenance

ORR Operational Readiness Review

PAR Program Approval Review

PCA Program Commitment Agreement

PCDR Program Concept and Definition Review

PCR Project Completion Review

PDR Preliminary Design Review

PIR Program Implementation Review

PMB Program Management Board

PMC Program Management Committee

PPBE Planning, Programming, Budgeting, and Execution

RFA Request for Action

RFP Request for Proposal

SCR System Concept Review

SMC Strategic Management Council

SIB Strategy and Investment Board

SRR System Requirements Review

TRR Test Readiness Review

V&V Verification and Validation

WBS Work-Breakdown Structure

# APPENDIX C. Formulation Authorization Document Template

## C.1 Program FAD Title Page

**Program**

**Formulation Authorization Document**

(Provide a title for the candidate program and designate a short title
or proposed acronym in parenthesis, if appropriate.)

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_

Mission Directorate or Mission Support Office Official Date

Figure C-1 Program Formulation Title Page

## C.2 Project FAD Title Page

**Project**

**Formulation Authorization Document**

(Provide a title for the candidate project and designate a short title
or proposed acronym in parenthesis, if appropriate.)

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_

Mission Directorate or Mission Support Office Official Date

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_

Program Manager Date

Figure C-2 Project Formulation Authorization Document Title Page

## C.3. Program/Project FAD Template

**PROGRAM/PROJECT**

**FORMULATION AUTHORIZATION DOCUMENT\
(PROGRAM/PROJECT TITLE)**

**1.0 PURPOSE**

Describe the purpose of the program/project. Identify the
program/project goals and objectives to be met.

**2.0 AUTHORITY**

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

**3.0 PROGRAM PROJECT GOALS AND OBJECTIVES**

Describe the level or scope of work, goals, and objectives to be
accomplished in the formulation phase, cost targets and constraints, the
time available, and any other constraints.

**4.0 INTERNAL PARTICIPANTS**

Identify Mission Directorates, Mission Support Offices, Centers, and
other NASA organizations to be involved in the activity, their scope of
work, and any known constraints related to their efforts (e.g.,
program/project funding interdependencies).

**5.0 EXTERNAL PARTICIPANTS**

Identify participation external to NASA to be involved in the activity,
their scope of work, and any known constraints related to their efforts
(e.g., the program/project must be cofunded by the external
participant).

**6.0 INFORMATION TYPES**

In conformance with NPR 2810.1, Security of Information Technology,
identify the FIPS 199 information that IT investments and systems will
be processing and handling.

**7.0 FUNDING**

Identify, by fiscal year, the funding that will be committed for
formulation.

**8.0 REVIEWS**

Describe the reviews, including independent reviews according to the
Reviews Table in Chapter 2, required during the formulation phase.
Describe the criteria for triggering a termination review.

# APPENDIX D. Program Commitment Agreement Template

## D.1 PCA Title Page

**Program Commitment Agreement**

(Provide a title for the candidate program and designate a short title
or proposed acronym in parenthesis, if appropriate.)

It is the responsibility of each of the signing parties to notify the
other in the event that a commitment cannot be met and to initiate the
timely renegotiations of the terms of this agreement.

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_

Mission Directorate or Mission Support Office Official Date

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_

Associate or Deputy Administrator Date

Figure D-1 Program Commitment Agreement Title Page

## D.2 PCA Template

**PROGRAM COMMITMENT AGREEMENT**

**(PROGRAM TITLE)**

**1.0 PROGRAM OBJECTIVES**

Identify the broad program objectives. Describe the program's
relationship to Mission Directorate or Mission Support Office
requirements. Convey the public good of the program to the taxpayer,
stated in a way that can be understood by the average citizen.

**2.0 PROGRAM OVERVIEW**

Describe the strategy to achieve the above-mentioned objectives.
Relationships with external organizations, other agencies, or
international partners should be addressed if achievement of the program
objectives is dependent on their performance. Identify the associated
projects governed by the program.

**3.0 PROGRAM AUTHORITY**

Describe the NASA organizational structure for managing the program and
projects from the Mission Directorate or Mission Support Office to the
NASA Centers, other internal organizations, and project managers.
Include lines of authority and reporting, organizational
responsibilities, the Governing Body (e.g., OMC) for the oversight of
the program and its projects, and the approving official for new
projects.

**4.0 TECHNICAL PERFORMANCE COMMITMENT**

Summarize the performance metrics with goal and minimum thresholds
needed to achieve the program objectives. If the objectives include a
technical performance target (goal) in addition to a threshold
requirement, the commitment could be stated as a range.

**5.0 SCHEDULE COMMITMENT**

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

1.  Start of Formulation.

2.  Target date or timeframe for the NAR.

3.  Start of Implementation.

4.  End of Implementation.

5.  Other milestones or time periods, as appropriate for the specific
    program.

**6.0 COST COMMITMENT**

Provide the maximum estimated cost for the program. This will
incorporate programmatic constraints and can be demonstrated by
including a table of all projects in Formulation and Implementation for
the current year and nine-year horizon. (The actual cost plan is
developed during the annual PPBE process.) The cost commitment includes
all full-cost data necessary to perform the program, including, but not
limited to, standard project activities, facilities costs, deployment,
sustaining operations maintenance, data analysis, and decommissioning.
For more information on full cost and practices, see Volume 7 of the
NASA Financial Management Requirements.

**7.0 ACQUISITION STRATEGY**

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

**8.0 HIGH-RISK AREAS**

Identify the areas of highest risk for the program (covering safety,
technical, institutional, cost, or schedule issues) in which failure may
result in changes to the program baseline cost, schedule, or technical
performance requirements. This section should identify, where possible,
the specific risk drivers, such as high-risk technologies upon which the
program is dependent.

**9.0 INTERNAL AGREEMENTS**

If the program is dependent on other NASA activities outside the Mission
Directorate or Mission Support Office's control to meet program
objectives, identify the required support and list any formal agreements
required.

**10.0 EXTERNAL AGREEMENTS**

Explain the involvement of external organizations, other agencies, or
international support necessary to meet the program objectives. Include
a brief overview of the program relationships with such external
organizations. Include an identification of the commitments being made
by the external organizations, other agencies, or international partners
and a listing of the specific agreements to be concluded. Any unique
considerations affecting implementation of required NASA policies and
processes necessitated by the external involvement should be clearly
identified.

**11.0 INDEPENDENT ASSESSMENTS**

Specify the type of independent assessments that will be performed
during the program life cycle.

**12.0 OUTCOMES**

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

**13.0 WAIVERS**

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

**14.0 PCA ACTIVITIES LOG**

Provide and maintain a log of all PCA activities, including revisions
that reflect all deviations to the original PCA. This log includes the
information shown in Figure D-2 and may be supplemented with an attached
addendum for each change, describing the change. The PCA should be
updated to add approved projects or whenever substantial change makes it
necessary.

  ---------- -------------- ------------ -------------- ------------------ --------------- -----------------
                                                        **Cancellation**   **Mission       **Associate or
                                                                           Directorate or  Deputy
                                                                           Mission Support Administrator**
                                                                           Office          
                                                                           Official**      

  **Date**   **Event**      **Change**   **Addendum**   **Review Req'd**   **Signature**   **Signature**

  dd/mm/yy   Revalidation   None         N/A            No                                 

  dd/mm/yy   Revalidation   None         N/A            No                                 

  dd/mm/yy   Approval of    Addition of  Ref. #1        No                                 
             new project    Project N                                                      
  ---------- -------------- ------------ -------------- ------------------ --------------- -----------------

Figure D-2 Sample Program Commitment Agreement Activities Log

# APPENDIX E. Program Plan Template

## E.1 Template Instructions

The program plan is an agreement between the MDAA or the Mission Support
Office Official-in-Charge and the program manager. As appropriate,
Center Directors also concur with the program plan under separate cover
to signify their commitment to supply required resources. The program
plan defines the goals and objectives of the program, the environment
within which the program operates, and the baseline commitments of the
program. The program plan is used by the Governing Body (e.g., OMC) in
the review process to assess whether the program is fulfilling its
agreement and during independent assessments, to determine if the
program is fulfilling its agreement. The program plan is to be updated
and approved during the program life cycle if warranted by changes in
the stated baseline commitments.

In this program plan template, all subordinate plans, collectively
called control plans, are required. They are based on requirements in
NASA Policy Directives (NPDs) and NASA Procedural Requirements (NPRs)
that affect program/project planning. The 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 and the approval authority for the stand-alone control plan is
the program manager.

Each section of the program plan template is required. If a section is
not applicable to a particular program, indicate by stating so in the
appropriate section and provide a rationale. If a section is applicable
but the program desires to omit the section or parts of a section, then
a waiver must be obtained in accordance with the waiver process for this
NPR.

## E.2 Program Plan Title Page

**Program Plan**

(Provide a title for the candidate program and designate a short title
or proposed acronym in parenthesis, if appropriate.)

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_

Mission Directorate or Mission Support Office Official Date

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_

Program Manager Date

Figure E-1 Program Plan Title Page

## E.3 Program Plan Template

**PROGRAM PLAN**

**(PROGRAM TITLE)**

**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 Vision, Mission, and strategic goals. Program
performance goals and their relationship to NASA program goals and
objectives set forth in NPD 1000.1, should be expressed in an objective,
quantifiable, and measurable form. Goals and objectives should include
specific commitments to program 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.

Provide a summary-level technical description of the program, including
constituent projects.

Describe how the program will relate to other organizations within NASA
and outside NASA. Reference the Acquisition Plan of this document, or
provide the following information here:

a\. For organizations within NASA, describe the roles of each in the
program, including cross-cutting technology efforts and institutional
infrastructure needs.

b\. For organizations outside NASA, describe the role of each in the
program, including other government agencies, academia, industry, and
international partners as they are known at the start of the program.
List the internal and external agreements necessary for program success
and their projected dates of approval.

**1.4 CUSTOMER AND STAKEHOLDER DEFINITION**

State the main customers and stakeholders of the program (e.g., science
community, technology, community, public, education community, Mission
Directorate or Mission Support Office sponsor(s)) and the process to be
used to ensure customer and stakeholder advocacy.

**1.5 PROGRAM AUTHORITY**

Identify the location (Headquarters or Centers) where the program
manager resides. Identify the approving official for projects. Describe
the chain of accountability and decision path that outlines the roles
and responsibilities of the Mission Directorate or Mission Support
Office sponsor(s), program manager, Center Director, and other
authorities as required.

**1.6 MANAGEMENT APPROACH AND GOVERNANCE STRUCTURE**

Describe the program management structure, including each participating
organization's responsibilities, integration into the sponsoring Mission
Directorate or Mission Support Office, and NASA Center(s) participation.
Describe clear lines of authority from projects and Centers to the
program to the Mission Directorate or Mission Support Office and
frequency of reporting for each. Illustrate the organization
graphically. Identify the responsibilities of each participating
organization as they relate to their respective requirement allocations
referenced in the REQUIREMENTS BASELINE below. Describe the process by
which projects are formulated, approved, and terminated.

Identify all significant interfaces with other contributing
organizations. Describe the process for problem reporting at the program
level and subsequent decision making, clearly describing the roles and
responsibilities of all organizations. Identify specific management
tools to support management in planning and controlling the program.
Describe any use of special boards and committees.

Describe the Mission Directorate or Mission Support Office, program
manager, and project manager responsibilities for developing,
concurring, and approving principal program documents, such as the FAD
(or equivalent), the program plan, project plans, and
acquisition-related documents, reports associated with major reviews,
and other key program activities.

**1.7 IMPLEMENTATION APPROACH**

Describe briefly the implementation approach of the program, including
the acquisition strategy (e.g., NASA HQ offices, NASA Centers, in-house,
contractor primes), partners, and partner contributions, if appropriate.
Include make-or-buy plan and trade studies.

**2.0 PROGRAM BASELINE**

**2.1 REQUIREMENTS BASELINE**

Document the program requirements, including performance requirements
and programmatic requirements. Describe the process by which program
requirements are validated for compliance. Describe the process for
controlling changes to the requirements. Link the requirements to the
program success criteria.

For multiple projects within a program, describe how program
requirements will be allocated to the respective projects. Document the
objectives and the program requirements on the projects as they are
formulated and how the requirements flow down from the program.

Document the traceability of requirements and flow-down to projects. If
the program characteristics indicate a greater emphasis is necessary on
maintaining either technical, cost, or schedule, then this section also
identifies which is more important. Programmatic success criteria such
as cost, schedule, and technical performance goals are linked to program
requirements and are expressed in objective, quantifiable, and
measurable form. Goal and threshold values are established for each
success criterion.

**2.2 WBS BASELINE**

Provide the program's WBS and WBS dictionary to the second level. For
Internal Use Software projects, develop the Level 2 WBS to meet the
requirements of NASA's FMR Volume 6, Chapter 4, 041206, Accounting,
Property Plant and Equipment, Software Policies and Procedures --
Capitalization.

**2.3 SCHEDULE BASELINE**

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

**2.4 RESOURCE BASELINE**

Present the program's funding requirements by fiscal year. State the New
Obligational Authority (NOA) in full-cost, real-year dollars for the
prior, current, and remaining years. 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. The
funding baseline provides separate funding requirements for each WBS
Level 2 element.

Present the program-specific (i.e., not individual project) workforce
requirements by fiscal year, consistent with the program funding
requirements and WBS. Identify, if possible, the elements of work that
may be done in-house or contractor, as well as the Centers that perform
the work.

Describe the program infrastructure requirements (acquisition,
renovations, and/or use of real property/facilities, aircraft, personal
property, 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.

**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:

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

b\. Describe the program's performance metrics in objective,
quantifiable, and measurable terms and document how the metrics are
traced from the program's high-level requirements. Establish goal and
threshold values for the performance metrics to be achieved at each KDP,
as appropriate. In addition, document the minimum program success
criteria associated with the high-level program requirements that, if
not met, trigger consideration of a Termination Review.

c\. Describe the plan to control the requirements, technical design,
schedule, and cost of the program to high-level program requirements.

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

e\. Describe how the program will monitor and control the integrated
master schedule.

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

g\. Describe how the program plans to report technical, schedule, and
cost status to the Mission Directorate or Mission Support Office,
including frequency and the level of detail.

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

**3.2 RISK MANAGEMENT PLAN**

Summarize how the program will implement the NASA continuous risk
management process in accordance with NPR 8000.4. Include the initial
Significant Risk List and appropriate actions to mitigate each risk.
Include hazard analysis to identify safety risks. Programs with
international contributions plan for, assess, and report on risks due to
international partners and plan for contingencies.

**3.3 ACQUISITION PLAN**

The Program Acquisition Plan is developed by the program manager,
supported by the Office of Procurement. It documents an integrated
acquisition strategy that enables the program to meet its objectives,
provides the best value to NASA, and complies with the FAR and the NASA
FAR Supplement. The Acquisition Plan should:

a\. Identify all major proposed acquisitions (such as design studies,
hardware and software development, and operations support) in relation
to the program WBS. Provide summary information on each such proposed
acquisition, including a Contract WBS; major deliverable items; type of
procurement (competitive, sole source); type of contract (cost
reimbursable, fixed-price); source (institutional, contractor, other
Government organizations); procuring activity; and, surveillance
approach.

b\. Describe completed or planned studies supporting make-or-buy
decisions, considering NASA's in-house capabilities and the maintenance
of NASA's core competencies.

c\. Describe all agreements, memoranda of understanding, barters,
in-kind contributions, and other arrangements for collaborative and/or
cooperative relationships. List all such agreements (the configuration
control numbers and the date signed or projected dates of approval)
necessary for program success. Include or reference all agreements
concluded with the authority of the program manager and reference
agreements concluded with authority above the program manager.

**3.4 TECHNOLOGY DEVELOPMENT PLAN**

Describe the technology assessment, development, management, and
acquisition strategies needed to achieve the program's objectives. In
the Technology Development Plan:

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

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

c\. Describe the program's alternative development strategies for
technologies that do not mature as expected.

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

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

**3.5 REVIEW PLAN**

*S*ummarize the program's approach for conducting a continuum of reviews
for the program life cycle. Explain the reporting requirements for
program reviews. Provide the technical, scientific, schedule, cost and
other criteria, which will be utilized in the consideration of a
termination review.

**3.6 INFORMATION AND CONFIGURATION MANAGEMENT PLAN**

Describe the configuration management approach that the program team
will implement. Describe the structure of the configuration management
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 configuration
management will be audited and how contractor configuration management
processes will be integrated with the program. Reference the stand-alone
program Configuration Management Plan, if applicable.

Explain the program's approach to management of information across its
life cycle, including the development and maintenance of an electronic
program library and designation of a program records manager. Describe
the organization, tools, and procedures to be used to ensure program
records identification, control, and disposition in accordance with NPR
1441.1.

Describe the program's approach to knowledge capture as well as the
methods for contributing knowledge to other entities and systems,
including compliance with

NPD 2200.1, Management of NASA Scientific and Technical Information, and

NPR 2200.2B, Requirements for Documentation, Approval, and Dissemination
of NASA Scientific and Technical Information.

Describe the program's approach to capturing lessons learned in
accordance with

NPR 7120.6, Lessons Learned Process.

**3.7 EXPORT CONTROL PLAN**

Describe how the program will comply with U.S. export control laws and
regulations and NASA\'s Export Control Program as documented in NPR
2190.1, NASA Export Control Program. It should describe the partners'
(international, contractors, universities) roles and responsibilities,
show the schedule of anticipated transfers, describe a plan to comply
with NASA export-control transfer requirements (identification and
classification of controlled data/articles, exemptions/exceptions,
licensing, documentation, recordkeeping, and reporting). Program
managers must consult with the NASA Export Administrator/

Center Export Administrator during plan development.

**3.8 EDUCATION AND PUBLIC OUTREACH PLAN**

Describe planned efforts and activities to improve science literacy by
engaging the public in understanding the program, its objectives, and
benefits. Summarize plans to stimulate interest in science, engineering,
and technology through program-related outreach activities. Summarize
plans to flow the education and public outreach requirements to projects
within the program.

**4.0 WAIVERS LOG**

Identify requirements for which a waiver has been requested and
approved. Include the rationale for the request.

**5.0 CHANGE LOG**

Record changes to the program plan.

**6.0 APPENDICES**

Appendix A - Acronyms

Appendix B - Definitions

# APPENDIX F. Project Plan Template

## F.1 Template Instructions

The project plan is an agreement between the project manager, program
manager, and the Mission Directorate or Mission Support Office. 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
used by the project Governing Body in the review process and during
independent assessments to determine if the project is fulfilling its
agreement. 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 project-level requirements or the baseline
commitments.

In this project plan template, all subordinate plans, collectively
called control plans, are required. They are based on requirements in
NASA NPDs and NPRs that affect program/project planning. The control
plans can either be part of the project plan or separate stand-alone
documents referenced in the appropriate part of the project plan. In the
case of the latter, the project plan contains a summary of and reference
to the stand-alone document and the approval authority for the
stand-alone control plan is the project manager.

Each section of the project plan is required for all projects. If a
section is not applicable to a particular project, indicate by stating
so in the appropriate section and provide a rationale. If a section is
applicable but the project desires to omit the section or parts of a
section, then a waiver must be obtained in accordance with the waiver
process for this NPR.

## F.2 Project Plan Title Page

**\[*Project Name*\] Project Plan**

**(*short title or acronym)***

(Provide a title for the candidate project and designate a short title
or proposed acronym in parenthesis, if appropriate.)

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Mission Directorate or Mission Support Office Official Date

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Center Director, if appropriate Date

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Program Manager Date

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Project Manager Date

Figure F-1: Project Plan Title Page

## F.3 Project Plan Template

**\[*PROJECT NAME*\] PROJECT PLAN**

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

**1.2 OBJECTIVES**

State the specific project objectives, high-level performance goals, and
their relationship to the program objectives. Include performance,
schedule, cost, and technology development objectives, as applicable.

**1.3 PROJECT DESCRIPTION AND TECHNICAL APPROACH**

Describe briefly the project and the project design. Include key
characteristics of the project and the key phases and events on the
project timeline. Use drawings, figures, charts, etc., for
clarification. Describe planned project results, assessment, and
reporting. For IT projects, describe the system's relationship to the
NASA Enterprise Architecture.

Provide a brief description of the technical approach. Describe the
systems to be developed (hardware and software systems, constraints,
system interfaces, and facilities). Identify major constraints affecting
system development (e.g., cost, schedules, agreements, etc.).

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

Identify the organization where the project manager resides. Describe
the governance structure. Identify the governing body responsible for
oversight of the project (e.g., SMC, OMC, PMC, other committee).
Describe Centers' responsibilities, if any. Identify the project's
Decision Authority. Describe the chain of accountability and decision
path that outlines the roles and responsibilities of the project
manager, program manager, and other authorities.

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

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

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

**1.5 CUSTOMER AND STAKEHOLDER DEFINITION**

Describe the customers and stakeholders of the project (e.g., business
community, science community, technology community, public, education
community, parent program, and Mission Directorate or Mission Support
Office sponsor) and the process to be used to ensure customer advocacy
within the project.

**2.0 PROJECT BASELINE**

**2.1 REQUIREMENTS BASELINE**

Link the objectives described in the previous section to the
project-level requirements.

**2.2 WBS BASELINE**

Provide the project's WBS and WBS dictionary to the Level 2 elements. In
developing the WBS, meet the requirements of NID-9250, Identifying
Capital Assets and Capturing Their Cost and, for projects which include
internal use software, the requirements of NASA's FMR Volume 6, Chapter
4, 041206, Accounting, Property Plant and Equipment, Software Policies
and Procedures -- Capitalization.

**2.3 SCHEDULE BASELINE**

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

**2.4 RESOURCE BASELINE**

Present the project funding requirements by fiscal year. State the
funding in full-cost, real-year dollars for the prior, current, and
remaining years. 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. The funding baseline provides
separate funding requirements for each WBS Level 2 element.

Present the project's workforce requirements by fiscal year, consistent
with the project funding requirements and WBS. The estimate encompasses
all work required to achieve project objectives. Include full accounting
of civil service workforce requirements on the providing organizations
for the prior (e.g., actuals), current, and remaining years of the
project life cycle. Identify, if possible, the elements of work that may
be done by contractors and the Centers that perform the work.

Describe the project infrastructure requirements (acquisition,
renovations, and/or use of real property/facilities, aircraft, personal
property, 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.

**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 its project-level
requirements. This control plan will include the following:

a\. Describe the plan to monitor the requirements, technical design,
schedule, and cost of the project.

b\. Describe the project's performance metrics in objective,
quantifiable, and measurable terms, and document how the metrics are
traced from the project-level requirements. Establish goal and threshold
values for the performance metrics to be achieved at each KDP, as
appropriate. Establish the thresholds for the difference between the
development cost EAC or a schedule milestone listed on the project life
cycle chart in Figure 2-4 of this NPR that will trigger a written notice
and a recovery plan to the program manager. In addition, document the
minimum project success criteria associated with the project-level
requirements that, if not met, trigger consideration of a Termination
Review.

c\. Describe the plan to control the requirements, technical design,
schedule, and cost of the project to project-level requirements.

d\. Describe how the project will address safety issues, if any,
associated with project execution and implementation.

e\. Describe the project\'s implementation of Earned Value Management
(EVM). The

following requirements apply:

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

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

\(3\) Project EVM reporting begins within 60 days after the start of
Phase C.

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

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

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

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

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

management agency.

\(iii\) EVM is not required for grants, nondevelopmental level-of-effort
engineering support services, steady-state operations, basic and applied
research, and routine services such as janitorial services or grounds
maintenance services; however, application is at the discretion of the
program/project manager.

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

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

f\. Describe any additional specific tools the project will use to
implement the project control processes, e.g., the requirements
management system, the project scheduling system, the project
information management systems, and the budgeting and cost accounting
system.

g\. Describe how the project will monitor and control the integrated
master schedule.

h\. Describe how the project will utilize its technical, schedule, and
cost reserves to control the baseline.

i\. Describe how the project plans to report technical, schedule, and
cost status to the program manager, including frequency and the level of
detail.

j\. Describe how the project will address technical waivers and how
dissenting opinions will be handled.

**3.2 RISK MANAGEMENT PLAN**

Summarize how the project will implement a continuous risk management
process in accordance with NPR 8000.4. Include the initial Significant
Risk List and appropriate actions to mitigate each risk. Include hazard
analysis to identify safety risks. Projects with international
contributions plan for, assess, and report on risks due to international
partners and plan for contingencies.

**3.3 ACQUISITION PLAN**

The Project Acquisition Plan is developed by the project manager and
supported by the Center's Office of Procurement. It documents an
integrated acquisition strategy that enables the project to meet its
objectives, provides the best value to NASA, and complies with the FAR
and the NASA FAR Supplement. The Acquisition Plan should:

a\. Identify all major proposed acquisitions (such as design studies,
hardware and software development, and operations support) in relation
to the project WBS. Provide summary information on each such proposed
acquisition, including a Contract WBS; major deliverable items; type of
procurement (competitive, sole source); type of contract
(cost-reimbursable, fixed-price); source (institutional, contractor,
other Government organizations); procuring activity; and surveillance
approach.

b\. Describe completed or planned studies supporting make-or-buy
decisions, considering NASA's in-house capabilities and the maintenance
of NASA's core competencies.

c\. If systems contain software, describe the project's approach for
complying with NPR 7150.2.

d\. Describe all agreements, memoranda of understanding, barters,
in-kind contributions, and other arrangements for collaborative and/or
cooperative relationships. List all such agreements (the configuration
control numbers and the date signed or projected dates of approval)
necessary for project success. Include or reference all agreements
concluded with the authority of the project manager and reference
agreements concluded with the authority of the program manager and
above.

**3.4 TECHNOLOGY DEVELOPMENT PLAN**

Describe the technology assessment, development, management, and
acquisition strategies needed to achieve the project's objectives. In
the Technology Development Plan:

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

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

c\. Describe the project's alternative development strategies for
technologies that do not mature as expected.

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

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

**3.5 REVIEW PLAN**

*S*ummarize the project's approach for conducting a continuum of reviews
for the project life cycle, including peer reviews. Explain the
reporting requirements for project reviews. Provide the management,
technical, schedule, cost, and other criteria, which will be utilized in
the consideration of a termination review.

For IT projects, use Appendix G of this document for guidance to provide
the names, purposes, content, and timing of the critical milestone
project reviews.

**3.6 INFORMATION AND CONFIGURATION MANAGEMENT PLAN**

Describe the configuration management approach that the project team
will implement. Describe the structure of the configuration management
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 the project's approach to knowledge capture, as well as the
methods for contributing knowledge to other entities and systems. This
includes the development and maintenance of an electronic project
library.

Describe the program's approach to capturing lessons learned in
accordance with

NPR 7120.6.

**3.7 IT SECURITY PLAN**

Describe the project's plans for ensuring security and address the
following elements:

a\. IT Security Requirements: Document the project's approach to
implementing IT security requirements in accordance with NPR 2810.1.

**3.8 DATA CONVERSION PLAN**

Describe the plan that the project will execute to ensure that required
data from existing electronic and/or manual systems are included in the
new information system, including at a minimum the following elements:

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

b\. The scope of the data conversion plan as it relates to the project.

c\. An overview of security considerations associated with the data
conversion, including the IT security categorizations of the data to be
converted.

d\. A description of the data, including its IT security categorization
that will be converted from existing systems (electronic and manual) to
the new systems.

e\. A description of data cleansing or other operations that will be
conducted on the data prior to its conversion.

f\. A description of the data, including its IT security categorization,
that will not be moved from existing systems (electronic and manual) to
the new system, with rationale for not moving the data to the new system

g\. A description of how the data that will not be moved to the new
system will be dispositioned in accordance with the requirements of NPR
1441.1 and other Agency requirements.

h\. A description of the tools, facilities, and approaches that will be
used for converting data from existing systems to the new systems.

i\. Roles and responsibilities of organizations that will perform data
conversion.

j\. A description of how the project will determine that the data have
been converted successfully, including the role of the data owner in
ensuring successful conversion.

k\. The timeframes for when data conversion will begin and when it will
be completed, following the life-cycle designations of this document and
integrated with the overall project schedule.

l\. Methods (e.g., meetings and communications) for keeping all
organizations informed about the status of the data conversion plan.

**3.9 EXPORT CONTROL PLAN**

Describe how the project will comply with U.S. export control laws and
regulations and NASA\'s Export Control Program as documented in NPR
2190.1. It should describe the partners' (international, contractors,
universities) roles and responsibilities, show the schedule of
anticipated transfers, describe a plan to comply with NASA
export-control transfer requirements (identification and classification
of controlled data/articles, exemptions/exceptions, licensing,
documentation, recordkeeping, and reporting). Project managers must
consult with the NASA Export Administrator/Center Export Administrator
during plan development.

**4.0 WAIVERS LOG**

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

**5.0 CHANGE LOG**

Track and document changes to the project plan.

**6.0 APPENDICES**

Appendix A - Acronyms

Appendix B - Definitions

# Appendix G. Technical Review Entrance and Success Criteria for IT Projects {#appendix-g.-technical-review-entrance-and-success-criteria-for-it-projects .unnumbered}

This appendix describes the recommended best practices for technical
reviews conducted as a part of information technology projects. During
creation of the project plan, the project manager works with the program
manager to appropriately tailor the project-level review entrance
criteria and success criteria. The final set of required entrance and
success criteria should reflect the nature of the system under
development; be appropriate for the project's size, risk, and
importance; and be achievable with approved project resources and on an
acceptable schedule. The review plan section of the project plan
documents the tailoring of the reviews.

**G.1 System Concept Review**

The SCR evaluates the scope, cost benefit analysis, and a recommended
solution/concept for the product or service to be delivered for the
purpose of receiving approval, formalized via the Formulation
Authorization Document, to proceed to the Formulation Phase. Assesses
the effect on the "as-is" and "to-be" enterprise architecture. Ensures
applicable security controls have been considered.

Table G-1 -- SCR Entrance and Success Criteria

+----------------------------+-----------------------------------------+
| **System Concept Review**  |                                         |
+----------------------------+-----------------------------------------+
| **Entrance Criteria**      | **Success Criteria**                    |
+----------------------------+-----------------------------------------+
| 1.  System goals and       | 1.  System objectives are clearly       |
|     objectives.            |     defined and stated and are          |
|                            |     unambiguous and internally          |
| 2.  Analysis of            |     consistent.                         |
|     alternative concepts   |                                         |
|     to show at least one   | 2.  The preliminary set of requirements |
|     is feasible.           |     satisfactorily provides a system    |
|                            |     which will meet the system          |
| 3.  Concept of operations. |     objectives.                         |
|                            |                                         |
| 4.  Preliminary risk       | 3.  The system is feasible. A solution  |
|     assessment, including  |     has been identified which is        |
|     technologies and       |     technically feasible. A rough cost  |
|     associated risk        |     estimate is within an acceptable    |
|     management/            |     cost range.                         |
|                            |                                         |
| mitigation strategies and  | 4.  The concept evaluation criteria to  |
| options.                   |     be used in candidate systems        |
|                            |     evaluation have been identified and |
|                            |     prioritized.                        |
|                            |                                         |
|                            | 5.  The need for the system has been    |
|                            |     clearly identified.                 |
|                            |                                         |
|                            | 6.  The cost and schedule estimates are |
|                            |     credible.                           |
|                            |                                         |
|                            | 7.  A technical search was done to      |
|                            |     identify existing assets or         |
|                            |     products that could satisfy the     |
|                            |     mission or parts of the system.     |
|                            |                                         |
|                            | 8.  Technical planning is sufficient to |
|                            |     proceed to the next phase.          |
|                            |                                         |
|                            | 9.  Risk and mitigation strategies have |
|                            |     been identified and are acceptable. |
+----------------------------+-----------------------------------------+

[]{.mark}

## G.2 System Requirements Review {#g.2-system-requirements-review .unnumbered}

## The SRR examines the functional, technical, performance, and security requirements for the system and the preliminary project plan and ensures that the requirements and the selected concept will satisfy the system objectives. {#the-srr-examines-the-functional-technical-performance-and-security-requirements-for-the-system-and-the-preliminary-project-plan-and-ensures-that-the-requirements-and-the-selected-concept-will-satisfy-the-system-objectives. .unnumbered}

Table G-2 -- SRR Entrance and Success Criteria

+-----------------------------------------+----------------------------+
| **System Requirements Review**          |                            |
+-----------------------------------------+----------------------------+
| **Entrance Criteria**                   | **Success Criteria**       |
+-----------------------------------------+----------------------------+
| 1.  A preliminary SRR agenda, success   | 1.  The project utilizes a |
|     criteria, and charge to the board   |     sound process for the  |
|     have been agreed to by the          |     allocation and control |
|     technical team, project manager,    |     of requirements        |
|     and review chair prior to the SRR.  |     throughout all levels, |
|                                         |     and a plan has been    |
| 2.  The following technical products    |     defined to complete    |
|     for hardware and software system    |     the definition         |
|     elements are available to the       |     activity within        |
|     cognizant participants prior to the |     schedule and cost      |
|     review:                             |     constraints.           |
|                                         |                            |
| ```{=html}                              | 2.  Top-level requirements |
| <!-- -->                                |     definition is          |
| ```                                     |     complete, and          |
| a.  System requirements document.       |     interfaces with        |
|                                         |     external entities and  |
| b.  System software functionality       |     between major internal |
|     description.                        |     elements have been     |
|                                         |     defined.               |
| c.  Concept of operations.              |                            |
|                                         | 3.  Requirements           |
| d.  Preliminary system requirements     |     allocation and flow    |
|     allocation to the next lower-level  |     down of key driving    |
|     system.                             |     requirements have been |
|                                         |     defined down to        |
| e.  Updated cost estimate.              |     subsystems.            |
|                                         |                            |
| f.  Risk assessment and mitigations.    | 4.  Preliminary approaches |
|                                         |     have been determined   |
| g.  Configuration management plan.      |     for how requirements   |
|                                         |     will be verified and   |
| h.  Initial document tree.              |     validated down to the  |
|                                         |     subsystem level.       |
| i.  Verification and validation         |                            |
|     approach.                           | 5.  Major risks have been  |
|                                         |     identified, and viable |
| j.  Information/system security         |     mitigation strategies  |
|     categorization.                     |     have been defined.     |
|                                         |                            |
| k.  Identification of personally        | 6.  IT security, privacy,  |
|     identifiable information.           |     and records retention  |
|                                         |     requirements are       |
| l.  Identification of records retention |     complete and have been |
|     requirements.                       |     incorporated into      |
|                                         |     project requirements   |
| m.  Identification of required system   |     documentation.         |
|     security controls.                  |                            |
|                                         | 7.  The preliminary        |
| n.  Preliminary software                |     software               |
|     development/management plan.        |     development/management |
|                                         |     plan meets the         |
| o.  Other specialty disciplines, as     |     requirements of        |
|     required.                           |                            |
|                                         | NPR 7150.2.                |
+-----------------------------------------+----------------------------+

**G.3 Preliminary Design Review**

The PDR demonstrates that the preliminary design meets all system
requirements with acceptable risk and within the cost and schedule
constraints and establishes the basis for proceeding with detailed
design. It will show that the correct design options have been selected,
interfaces have been identified, and verification methods have been
described.

Table G-3 -- PDR Entrance and Success Criteria

+---------------------------------------+------------------------------+
| **Preliminary Design Review**         |                              |
+---------------------------------------+------------------------------+
| **Entrance Criteria**                 | **Success Criteria**         |
+---------------------------------------+------------------------------+
| 1.  Successful completion of the SRR  | 1.  Agreement exists for the |
|     and responses have been made to   |     top-level requirements,  |
|     all SRR Requests for Action       |     including success        |
|     (RFAs), or a timely closure plan  |     criteria and any         |
|     exists for those remaining open.  |     sponsor-imposed          |
|                                       |     constraints, and ensures |
| 2.  A preliminary PDR agenda, success |     that these are           |
|     criteria, and charge to the board |     finalized, stated        |
|     have been agreed to by the        |     clearly, and are         |
|     technical team, project manager,  |     consistent with the      |
|     and review chair prior to the     |     prelim. design.          |
|     PDR.                              |                              |
|                                       | 2.  The flow down of         |
| 3.  PDR technical products listed     |     verifiable requirements  |
|     below for both hardware and       |     is complete and proper   |
|     software system elements have     |     or, if not, an adequate  |
|     been made available to the        |     plan exists for timely   |
|     cognizant participants prior to   |     resolution of open       |
|     the review:                       |     items. Requirements are  |
|                                       |     traceable to system      |
|     a.  Updated baselined             |     goals and objectives.    |
|         documentation, as required.   |                              |
|                                       | 3.  The preliminary design   |
|     b.  Preliminary subsystem design  |     is expected to meet the  |
|         specifications for each       |     requirements at an       |
|         configuration item (hardware  |     acceptable level of      |
|         and software) with supporting |     risk.                    |
|         tradeoff analyses and data,   |                              |
|         as required. The preliminary  | 4.  Definition of the        |
|         software design specification |     technical interfaces is  |
|         needs to include a completed  |     consistent with the      |
|         definition of the software    |     overall technical        |
|         architecture and a            |     maturity and provides an |
|         preliminary database design   |     acceptable level of      |
|         description as applicable.    |     risk.                    |
|                                       |                              |
|     c.  Updated risk assessment and   | 5.  Adequate technical       |
|         mitigation.                   |     margins exist with       |
|                                       |     respect to performance   |
|     d.  Updated cost and schedule     |     requirements.            |
|         data.                         |                              |
|                                       | 6.  Any required new         |
|     e.  Updated logistics             |     technology has been      |
|         documentation, as required.   |     developed to an adequate |
|                                       |     state of readiness, or   |
|     f.  Applicable technical plans    |     back-up options exist    |
|         (e.g., technical performance  |     and are supported to     |
|         measurement plan, reliability |     make them a viable       |
|         program plan, quality         |     alternative.             |
|         assurance plan).              |                              |
|                                       | 7.  The project risks are    |
|     g.  Operational concept.          |     understood, and plans    |
|                                       |     and a process and        |
|     h.  Applicable standards.         |     resources exist to       |
|                                       |     effectively manage them. |
|     i.  Engineering drawing tree.     |                              |
|                                       | 8.  The operational concept  |
|     j.  Interface control documents.  |     is technically sound. It |
|                                       |     includes (where          |
|     k.  Verification/validation plan. |     appropriate) human       |
|                                       |     factors that apply, and  |
|     l.  Plans to respond to           |     requirements for its     |
|         regulatory requirements       |     execution flow down.     |
|         (e.g., Section 508), as       |                              |
|         required.                     |                              |
|                                       |                              |
|     m.  Requirements traceability     |                              |
|         matrix.                       |                              |
|                                       |                              |
|     n.  Disposal plan.                |                              |
|                                       |                              |
|     o.  Technical resource            |                              |
|         utilization estimates and     |                              |
|         margins.                      |                              |
+---------------------------------------+------------------------------+

##  G.4 Critical Design Review {#g.4-critical-design-review .unnumbered}

The CDR confirms that the maturity of the design is appropriate to
support proceeding and that it was developed in conjunction with
stakeholders, demonstrates that the design meets detailed requirements,
and identifies open design issues for the purpose of obtaining a
decision to proceed with development and deployment. It reviews the
technical architecture to ascertain the effect on the enterprise
architecture and reviews the application security design and the
inclusion of security controls.

Table G-4 -- CDR Entrance and Success Criteria

+-------------------------------------------+--------------------------+
| **Critical Design Review**                |                          |
+-------------------------------------------+--------------------------+
| **Entrance Criteria**                     | **Success Criteria**     |
+-------------------------------------------+--------------------------+
| 1.  Successful completion of the PDR and  | 1.  The detailed design  |
|     responses has been made to all PDR    |     is expected to meet  |
|     RFAs, or a timely closure plan exists |     the requirements     |
|     for those remaining open.             |     with adequate        |
|                                           |     margins at an        |
| 2.  A preliminary CDR agenda, success     |     acceptable level of  |
|     criteria, and charge to the board     |     risk.                |
|     have been agreed to by the technical  |                          |
|     team, project manager, and review     | 2.  Interface control    |
|     chair prior to the CDR.               |     documents are        |
|                                           |     appropriately        |
| 3.  CDR technical work products listed    |     matured to proceed   |
|     below for both hardware and software  |     with development,    |
|     system elements have been made        |     integration, and     |
|     available to the cognizant            |     test, and plans are  |
|     participants prior to the review:     |     in place to manage   |
|                                           |     any open items.      |
|     a.  Updated baselined documents, as   |                          |
|         required.                         | 3.  High confidence      |
|                                           |     exists in the        |
|     b.  Product build-to specifications   |     product baseline,    |
|         for each hardware and software    |     and adequate         |
|         configuration item, along with    |     documentation exists |
|         supporting trade-off analyses and |     and/or will exist in |
|         data.                             |     a timely manner to   |
|                                           |     allow proceeding     |
|     c.  Development, integration, and     |     with development,    |
|         test plans and procedures.        |     integration, and     |
|                                           |     test.                |
|     d.  Technical Data Package (e.g.,     |                          |
|         Integrated Schematics, Spares     | 4.  The product          |
|         Provisioning List, Interface      |     verification and     |
|         Control Documents, engineering    |     product validation   |
|         analyses, specifications).        |     requirements and     |
|                                           |     plans are complete.  |
|     e.  Operational limits and            |                          |
|         constraints.                      | 5.  The testing approach |
|                                           |     is comprehensive,    |
|     f.  Preliminary operations handbook.  |     and the planning for |
|                                           |     system development,  |
|     g.  Technical resource utilization    |     integration, test,   |
|         estimates and margins.            |     and operations is    |
|                                           |     sufficient to        |
|     h.  Acceptance criteria.              |     progress into the    |
|                                           |     next phase.          |
|     i.  Verification plan (including      |                          |
|         requirements and specification).  | 6.  Adequate technical   |
|                                           |     and programmatic     |
|     j.  Validation plan.                  |     margins and          |
|                                           |     resources exist to   |
|     k.  Disposal plan (including          |     complete the         |
|         decommissioning or termination).  |     development within   |
|                                           |     budget, schedule,    |
|     l.  Updated risk assessment and       |     and risk             |
|         mitigation.                       |     constraints.         |
|                                           |                          |
|     m.  Updated cost and schedule data.   | 7.  Risks to system      |
|                                           |     success are          |
|     n.  Updated logistics documentation.  |     understood, and      |
|                                           |     plans and resources  |
|     o.  Software design document(s)       |     exist to effectively |
|         (including interface design       |     manage them.         |
|         documents).                       |                          |
|                                           |                          |
|     p.  Systems and subsystem             |                          |
|         certification plans and           |                          |
|         requirements (as needed).         |                          |
+-------------------------------------------+--------------------------+

##   {#section .unnumbered}

## G.5 Test Readiness Review {#g.5-test-readiness-review .unnumbered}

The TRR evaluates the project's readiness to proceed with testing,
ensuring adequate schedule, resources, and management processes are in
place. It ensures the completion of an integration test plan and the
system's readiness for execution of integration testing.

Table G-5 -- TRR Entrance and Success Criteria

+---------------------------------------+------------------------------+
| **Test Readiness Review**             |                              |
+---------------------------------------+------------------------------+
| **Entrance Criteria**                 | **Success Criteria**         |
+---------------------------------------+------------------------------+
| 1.  The objectives of the testing     | 1.  Adequate test plans are  |
|     have been clearly defined and     |     completed and approved   |
|     documented, and all of the test   |     for the system under     |
|     plans, procedures, environment,   |     test.                    |
|     and the configuration of the test |                              |
|     system support those objectives.  | 2.  Adequate identification  |
|                                       |     and coordination of      |
| 2.  Configuration of system under     |     required test resources  |
|     test has been defined and agreed  |     are complete.            |
|     to. All interfaces have been      |                              |
|     placed under configuration        | 3.  Previous component,      |
|     management or have been defined   |     subsystem, and system    |
|     in accordance with an agreed-to   |     test results form a      |
|     plan, and a version description   |     satisfactory basis for   |
|     document has been made available  |     proceeding into planned  |
|     to TRR participants prior to the  |     tests.                   |
|     review.                           |                              |
|                                       | 4.  Risk level is identified |
| 3.  All applicable functional, unit   |     and accepted by          |
|     level, subsystem, system, and     |     program/competency       |
|     qualification testing has been    |     leadership, as required. |
|     conducted successfully.           |                              |
|                                       | 5.  Plan to capture any      |
| 4.  All TRR specific materials such   |     lessons learned from the |
|     as test plans, test cases, and    |     test program is          |
|     procedures have been available to |     established.             |
|     all participants prior to         |                              |
|     conducting the review.            | 6.  The objectives of the    |
|                                       |     testing have been        |
| 5.  All known system discrepancies    |     clearly defined and      |
|     have been identified and          |     documented, and the      |
|     dispositioned in accordance with  |     review of all the test   |
|     an agreed-upon plan.              |     plans, as well as the    |
|                                       |     procedures, environment, |
| 6.  All previous design review        |     and the configuration of |
|     success criteria and key issues   |     the test item, provide a |
|     have been satisfied in accordance |     reasonable expectation   |
|     with an agreed-upon plan.         |     that the objectives will |
|                                       |     be met.                  |
| 7.  All required test                 |                              |
|     resources---people (including a   | 7.  The test cases have been |
|     designated test director),        |     reviewed and analyzed    |
|     facilities, test articles, test   |     for expected results,    |
|     instrumentation, and other test   |     and the results are      |
|     enabling products---have been     |     consistent with the test |
|     identified and are available to   |     plans and objectives.    |
|     support required tests.           |                              |
|                                       | 8.  Test personnel have      |
| 8.  Roles and responsibilities of all |     received appropriate     |
|     test participants are defined and |     training in test         |
|     agreed to.                        |     operation.               |
|                                       |                              |
| 9.  Test contingency planning has     |                              |
|     been accomplished, and all        |                              |
|     personnel have been trained.      |                              |
+---------------------------------------+------------------------------+

## G.6 Operational Readiness Review {#g.6-operational-readiness-review .unnumbered}

The ORR determines that the project is ready to go-live with the system
or service: requirements have been met; the functionality, performance,
and security controls have been thoroughly tested; procedures are in
place for operations; and that the organization responsible for
operations and sustaining engineering is ready to assume responsibility.
It ensures a security plan is in place and that system authorization has
been received.

Table G-6 -- ORR Entrance and Success Criteria

+----------------------------------------+-----------------------------+
| **Operational Readiness Review**       |                             |
+----------------------------------------+-----------------------------+
| **Entrance Criteria**                  | **Success Criteria**        |
+----------------------------------------+-----------------------------+
| 1.  All validation testing has been    | 1.  The system, including   |
|     completed.                         |     any enabling products,  |
|                                        |     is determined to be     |
| 2.  Test failures and anomalies from   |     ready to be placed in   |
|     validation testing have been       |     an operational status.  |
|     resolved and the results           |                             |
|     incorporated into all supporting   | 2.  All applicable lessons  |
|     and enabling operational products. |     learned for             |
|                                        |     organizational          |
| 3.  All operational supporting and     |     improvement and systems |
|     enabling products (e.g.,           |     operations have been    |
|     facilities, equipment, documents,  |     captured.               |
|     maintenance, and updated           |                             |
|     databases) that are necessary for  | 3.  All waivers and         |
|     the nominal and contingency        |     anomalies have been     |
|     operations have been tested and    |     closed.                 |
|     delivered/installed at the site(s) |                             |
|     necessary to support operations.   | 4.  Systems hardware,       |
|                                        |     software, personnel,    |
| 4.  Approved operations handbook.      |     and procedures are in   |
|                                        |     place to support        |
| 5.  Training has been provided to the  |     operations.             |
|     users and operators on the correct |                             |
|     operational procedures for the     |                             |
|     system.                            |                             |
|                                        |                             |
| 6.  Operational contingency planning   |                             |
|     has been accomplished, and all     |                             |
|     personnel have been trained.       |                             |
+----------------------------------------+-----------------------------+

## G.7 Project Completion Review {#g.7-project-completion-review .unnumbered}

The PCR provides assurance that the implemented system is performing as
expected and that all necessary support requirements are in place and
functioning properly. It confirms that the system is operating properly
in its production environment and primary responsibility for the system
is turned over to the operations and sustaining engineering teams. It is
the official closeout of the project and project team. The final project
schedule is published, and remaining open risks are transferred, closed,
or accepted. At the conclusion of the PCR, the system is considered
fully operational.

Table G-7 --Project Completion Review

+-------------------------------------------+--------------------------+
| **Project Completion Review**             |                          |
+-------------------------------------------+--------------------------+
| **Entrance Criteria**                     | **Success Criteria**     |
+-------------------------------------------+--------------------------+
| 1.  A preliminary agenda has been         | 1.  Required tests and   |
|     coordinated prior to the PCR.         |     analyses are         |
|                                           |     complete and         |
| 2.  The following PCR technical products  |     indicate that the    |
|     have been made available in a final   |     system performs      |
|     project report to the cognizant       |     properly in the      |
|     participants prior to the review:     |     operational          |
|                                           |     environment.         |
|     a.  System verification results.      |                          |
|                                           | 2.  Risks are known and  |
|     b.  System validation results.        |     manageable.          |
|                                           |                          |
|     c.  Documentation that the delivered  | 3.  System meets the     |
|         system complies with the          |     established          |
|         established acceptance criteria.  |     acceptance criteria. |
|                                           |                          |
|     d.  Documentation that the system     | 4.  All operations and   |
|         performs properly in the expected |     training             |
|         operational environment.          |     documentation is     |
|                                           |     complete and         |
|     e.  Technical data package as updated |     sufficient for       |
|         to include all test results.      |     production use of    |
|                                           |     the system.          |
|     f.  Certification package.            |                          |
|                                           | 5.  Technical data       |
|     g.  Updated risk assessment and       |     package is complete  |
|         mitigation.                       |     and reflects the     |
|                                           |     delivered system.    |
|     h.  Previous milestone reviews have   |                          |
|         been successfully completed.      | 6.  All applicable       |
|                                           |     lessons learned for  |
|     i.  Remaining liens or unclosed       |     organizational       |
|         actions and plans for closure.    |     improvement and      |
|                                           |     system operations    |
|                                           |     are captured.        |
+-------------------------------------------+--------------------------+

##   {#section-1 .unnumbered}

##  {#section-2 .unnumbered}

## G.8 Decommissioning Review {#g.8-decommissioning-review .unnumbered}

The DR confirms the decision to terminate or decommission the system and
assesses the readiness of the system for the safe decommissioning and
disposal of system assets.

Table G-8 -- DR Entrance and Success Criteria

+----------------------+-----------------------------------------------+
| **Decommissioning    |                                               |
| Review**             |                                               |
+----------------------+-----------------------------------------------+
| **Entrance           | **Success Criteria**                          |
| Criteria**           |                                               |
+----------------------+-----------------------------------------------+
| 1.  Requirements     | 1.  The reasons for decommissioning disposal  |
|     associated with  |     are documented.                           |
|     decommissioning  |                                               |
|     and disposal are | 2.  The decommissioning and disposal plan is  |
|     defined.         |     complete, approved by appropriate         |
|                      |     management, and compliant with applicable |
| 2.  Plans are in     |     Agency policies.                          |
|     place for        |                                               |
|     decommissioning, | 3.  All personnel have been properly trained  |
|     disposal, and    |     for the nominal and contingency           |
|     any other        |     procedures.                               |
|     removal from     |                                               |
|     service          | 4.  Risks associated with the disposal have   |
|     activities.      |     been identified and adequately mitigated. |
|                      |     Residual risks have been accepted by the  |
| 3.  Resources are in |     required management.                      |
|     place to support |                                               |
|     decommissioning  | 5.  Plans for disposition of system-related   |
|     and disposal     |     assets (i.e., hardware, software,         |
|     activities,      |     facilities) have been defined and         |
|     plans for        |     approved.                                 |
|     disposition of   |                                               |
|     project assets,  | 6.  Plans for archival and subsequent         |
|     and archival of  |     analysis of system data have been defined |
|     essential data   |     and approved. Arrangements have been      |
|     and official     |     finalized for the execution of such       |
|     records.         |     plans. Plans for the capture and          |
|                      |     dissemination of appropriate lessons      |
| 4.  Current system   |     learned during system operation have been |
|     capabilities are |     defined and approved. Adequate resources  |
|     described.       |     (schedule, budget, and staffing) have     |
|                      |     been identified and are available to      |
| 5.  The NASA         |     successfully complete all                 |
|     Enterprise       |     decommissioning, disposal, and            |
|     Architecture     |     disposition activities, including the     |
|     team has been    |     dispositioning of official records as     |
|     notified that a  |     required by NPR 1441.1.                   |
|     DR is planned    |                                               |
|     for the system   | 7.  IT infrastructure, including              |
|     and will be      |     documentation and systems that interface  |
|     notified of the  |     with the decommissioned system, are       |
|     results of the   |     planned to be modified to reflect the     |
|     DR.              |     system termination.                       |
+----------------------+-----------------------------------------------+