NASA Systems Engineering Handbook

6.0 Crosscutting Technical Management
Tightly coupled programs (e.g., Constellation Program)
have multiple projects that execute portions of
a mission or missions. No single project is capable of
implementing a complete mission. Typically, multiple
NASA Centers contribute to the program. Individual
projects may be managed at diferent Centers. Te
program may also include other Agency or international
partner contributions.
Regardless of the type, all programs are required to undergo
the two technical reviews listed in Table 6.7-1. Te
main diference lies between uncoupled/loosely coupled
programs that tend to conduct “status-type” reviews on
their projects afer KDP I and single-project/tightly coupled
programs that tend to follow the project technical
life-cycle review process post KDP I.
Table 6.7‑1 Program Technical Reviews
Review Purpose
Program/ The P/SRR examines the functional
System and performance requirements
Requirements defned for the program (and its
Review constituent projects) and ensures that
the requirements and the selected
concept will satisfy the program
and higher level requirements. It is
an internal review. Rough order of
magnitude budgets and schedules are
presented.
Program/ The P/SDR examines the proposed
System program architecture and the
Defnition fowdown to the functional elements
Review of the system.
Afer KDP I, single-project/tightly coupled programs
are responsible for conducting the system-level reviews.
Tese reviews bring the projects together and help ensure
the fowdown of requirements and that the overall
system/subsystem design solution satisfes the program
requirements. Te program/program reviews also help
resolve interface/integration issues between projects. For
the sake of this handbook, single-project programs and
tightly coupled programs will follow the project life-cycle
review process defned afer this table. Best practices and
lessons learned drive programs to conduct their “concept
and requirements-type” reviews prior to project concept
and requirements reviews and “program design and acceptance-type”
reviews afer project design and acceptance
reviews.
170 NASA Systems Engineering Handbook
Project Technical Life‑Cycle Reviews
Te phrase “project life cycle/project milestone reviews”
has, over the years, come to mean diferent things to
various Centers. Some equate it to mean the project’s
controlled formal review using RIDS and pre-boards/
boards, while others use it to mean the activity tied to
RFAs and SRB/KDP process. Tis document will use the
latter process to defne the term. Project life-cycle reviews
are mandatory reviews convened by the decision
authority, which summarize the results of internal technical
processes (peer reviews) throughout the project
life cycle to NASA management and/or an independent
review team, such as an SRB (see NPR 7120.5). Tese
reviews are used to assess the progress and health of a
project by providing NASA management assurance that
the most satisfactory approach, plan, or design has been
selected, that a confguration item has been produced to
meet the specifed requirements, or that a confguration
item is ready for launch/operation. Some examples of
life-cycle reviews include System Requirements Review,
Preliminary Design Review, Critical Design Review, and
Acceptance Review.
Specifed life-cycle reviews are followed by a KDP in
which the decision authority for the project determines,
based on results and recommendations from the lifecycle
review teams, whether or not the project can proceed
to the next life-cycle phase.
Standing Review Boards
Te SRB’s role is advisory to the program/project and the
convening authorities, and does not have authority over
any program/project content. Its review provides expert
assessment of the technical and programmatic approach,
risk posture, and progress against the program/project
baseline. When appropriate, it may ofer recommendations
to improve performance and/or reduce risk.
Internal Reviews
During the course of a project or task, it is necessary
to conduct internal reviews that present technical approaches,
trade studies, analyses, and problem areas to
a peer group for evaluation and comment. Te timing,
participants, and content of these reviews is normally
defned by the project manager or the manager of the
performing organization with support from the technical
team. In preparation for the life-cycle reviews a
project will initiate an internal review process as defned
in the project plan. Tese reviews are not just meetings