NASA Procedures and Guidelines
This Document is Obsolete and Is No Longer Used. Check the NODIS Library to access the current version: http://nodis3.gsfc.nasa.gov
NPR 7120.5D Eff. Date: March 06, 2007 Cancellation Date: March 12, 2007	NASA Space Flight Program and Project Management Requirements
| TOC | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | AppendixF | AppendixG | AppendixH | AppendixI | Figure2-2 | ALL |

CHAPTER 2. NASA Life Cycles for Space Flight Programs and Projects

2.1       Defining Programs and Projects

2.1.1       Space flight programs and projects are often the most visible and complex of NASA's strategic investments. These programs and projects flow from the implementation of national priorities, defined in the Agency's Strategic Plan, through the Agency's Mission Directorates as part of the Agency's general work breakdown hierarchy shown in Figure 2-1. This hierarchical relationship of programs to projects shows that programs and projects are different, and their management involves different activities and focus. The following definitions are used to distinguish 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 identified in a Program Plan 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.

Figure 2-1 Agency Work Breakdown Hierarchy

2.1.2       NASA's strategic acquisition planning and authorization is a continuous process requiring the earliest possible informed decisions to ensure programs and projects have the proper budget authorization and Agency commitment. To facilitate this decision process, three discrete acquisition events are required: the Acquisition Strategy Planning (ASP) meeting that provides the forum for senior Agency management to review major acquisitions before authorizing budget expenditures; the Acquisition Strategy Meeting (ASM) that examines the Agency's acquisition approach (e.g., internal make-or-buy, Center assignments, etc.); and the Procurement Strategy Meeting ⁵ (PSM) that approves the procurement approach for each procurement. The ASP meeting and ASM occur during the program and project formulation and approval processes. The ASP meeting is used to approve programs and projects for formulation. The ASM is program- or project-specific and is more detailed than the ASP meeting. The PSM is project- or contract-specific and is developed by the Project Manager, supported by the Contracting Officer, and approved as prescribed in the NASA FAR Supplement (NFS). These events are part of the normal program and project formulation and implementation activities described in the following paragraphs and chapters.

2.1.3       Within NASA, programs are initiated and implemented to accomplish scientific or exploration goals that generally require a collection of mutually supporting projects. Programs integrate and manage these projects over time and provide ongoing enabling systems, activities, methods, technology developments, and feedback to projects and stakeholders. Programs are generally created by a Mission Directorate with a long-term time horizon in mind, though as the Agency's strategic direction changes, a Mission Directorate must occasionally re-baseline its programs or combine related programs to increase effectiveness. Programs are generally executed at NASA Centers under the direction of the Mission Directorate and are assigned to Centers based on decisions made by Agency senior management at the Agency's strategic acquisition planning meetings. Because the scientific and exploration goals of programs vary significantly, different program implementation strategies are required, ranging from very simple to very complex. To accommodate these differences, NASA identifies four basic types of programs that may be employed:

a.             Single-project programs (e.g., James Webb Space Telescope Program) tend to have long development and/or operational lifetimes, represent a large investment of Agency resources in one program/project, and have contributions to that program/project from multiple organizations/agencies.

b.             Uncoupled programs (e.g., Discovery Program) are implemented under a broad scientific theme and/or a common program implementation concept, such as providing frequent flight opportunities for cost-capped projects selected through Announcements of Opportunity or NASA Research Announcements. Each such project is independent of the other projects within the program.

c.             Loosely coupled programs (e.g., Mars Exploration Program or Lunar Precursor and Robotic Program) address specific scientific or exploration objectives through multiple space flight projects of varied scope. While each individual project has an assigned set of mission objectives, architectural and technological synergies and strategies that benefit the program as a whole are explored during the formulation process. For instance, Mars orbiters designed for more than one Mars year in orbit are required to carry a communication system to support present and future landers.

d.             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 different Centers. The program may also include other agency or international partner contributions.

2.1.4       As with programs, projects vary in scope and complexity and thus require varying levels of management requirements and Agency attention and oversight. Consequently, project categorization will be used in the remainder of this document. Project categorization defines Agency expectations of project managers by determining both the oversight council and the specific approval requirements. Projects are either Category 1, 2, or 3 and are assigned to a category based initially on (1) the project life-cycle cost (LCC) estimate, the use of nuclear power sources, and whether or not the system being developed is for human space flight; and (2) priority level, which is related to the importance of the activity to NASA, the extent of international participation (or joint effort with other government agencies), the degree of uncertainty surrounding the application of new or untested technologies, and spacecraft/ payload development risk classification (see NPR 8705.4, Risk Classification for NASA Payloads). Guidelines for determining project categorization are shown in Table 2-1, but categorization may be changed based on recommendations by the Mission Directorate Associate Administrator (MDAA) that consider additional risk factors facing the project. The NASA Associate Administrator (AA) approves final project categorization. The Office of the Chief Engineer (OCE) is responsible for the official listing of NASA programs and projects and their categorization⁶. For purposes of project categorization, the project life-cycle cost estimate includes Phases A through F, all WBS Level 2 elements (see Appendix G), and is measured in real-year (nominal) dollars.

Table 2-1 Project Categorization Guidelines

2.1.5       When projects are initiated, they are assigned to a NASA Center by the MDAA in two general manners as part of the strategic acquisition planning process. They are either assigned directly to a Center by the Mission Directorate, or are selected through a competitive process such as an Announcement of Opportunity (AO).⁷ For Category 1 projects, the assignment is with the concurrence of the NASA AA. For Category 2 and 3 projects within tightly coupled programs, the assignment may be recommended by the Program Manager with the concurrence of the MDAA. Once assigned, projects may be performed wholly in-house, by government-industry-academia teams, or nearly completely under contract to industry.

2.1.6       Figure 2-2 is a summary of the NASA life cycles for space flight programs and projects and provides an overview of their interrelated life cycle management processes with pointers for key events to sections in this document where more information is provided.

Figure 2-2 NASA life cycles for space flight programs and projects (Click for Larger Size Image)

2.2       Program Life Cycle

2.2.1       As a strategic management structure, the program construct is extremely important within NASA. Programs provide the critically important linkage between the Agency's ambitious needs, goals, and objectives and the projects that are the specific means for achieving them. Although programs vary significantly in scope, complexity, cost, and criticality, within NASA they have a generic life-cycle management process that is divided into two distinct phases:

a.             Formulation -Pre-Program Acquisition, in which a technical approach is derived from an Analysis of Alternatives (AoA); program requirements are developed and allocated to initial projects; project pre-formulation is initiated; organizational structures are developed and work assignments initiated; program acquisition strategies are defined and approved; interfaces to other programs are developed; required annual funding levels are established, initial cost estimates are derived and a program budget is approved; a plan for implementation is designed and management systems put in place; and formal program documentation is approved, all consistent with the NASA Strategic Plan and other higher-level requirements.

b.             Implementation -Program Acquisition, Operations and Sustainment, in which constituent projects are initiated through direct assignment or competitive process (e.g., RFP, AO) and their formulation, approval, implementation, integration, operation, and ultimate decommissioning are constantly monitored; the program is adjusted as resources and requirements change. For tightly coupled programs, the implementation phase will coincide with the project life cycle to ensure that the program and all its projects are properly integrated, including proper interface definition and resource allocation across all internal projects and with external programs and organizations.

2.2.2       To formalize the management process, the program life cycle is established in Figure 2-3. This figure is used to illustrate:

a.             The program life-cycle phases;

b.             Program life-cycle gates and major events, including Key Decision Points (KDPs) (see Section 2.4); and

c.             Major program reviews (see Section 2.5) that precede the KDPs.

2.2.2.1    The formulation phase for all program types is the same, involving one or more program reviews, followed by KDP I, where a decision is made in regards to program approval to begin implementation. As shown in Figure 2-3, the program life cycle has two different implementation paths, depending on program type. Each implementation path has different types of major reviews. For uncoupled and loosely coupled programs, the implementation phase only requires Program Status Reviews (PSRs)/Program Implementation Reviews⁸ (PIRs) to assess the program's performance and authorize its continuation at biennial KDPs.

Figure 2-3 The NASA Program Life Cycle

2.2.2.2     Single-project and tightly coupled programs are more complex. For single-project programs, the implementation phase program reviews shown in Figure 2-3 are synonymous (not duplicative) with the project reviews in the project life cycle (see Figure 2-4 in Section 2.3) through Phase D. Once in operations, these programs have biennial KDPs preceded by attendant PSRs/PIRs. Tightly coupled programs during implementation have program reviews tied to the project reviews to ensure the proper integration of projects into the larger system. Once in operations, tightly coupled programs also have biennial PSRs/PIRs/KDPs to assess the program's performance and authorize its continuation.

2.2.3       Program formulation and implementation require the preparation and approval of three key documents - a program Formulation Authorization Document (FAD), a Program Commitment Agreement (PCA), and a Program Plan — each of which is now described.

2.2.3.1     To initiate planning for individual programs, a Mission Directorate prepares a program FAD following an ASP meeting. The program FAD authorizes a Program Manager to initiate the planning of a new program, and to perform the Analysis of Alternatives (AoA) required to formulate a sound Program Plan that contains project elements, requirements, schedules, risk assessments, and budgets. The FAD template is found in Appendix C. Because the creation of a new program represents a major commitment of the Agency and may require coordination with OMB and/or the Congress, the FAD requires the approval of the MDAA. The program FAD contains a statement of purpose for the proposed program and defines its relationship to the Agency's strategic goals and objectives; establishes the scope of work to be accomplished; provides initial constraints (including resources and schedule) and proposed program participants within and external to NASA (including international partnerships); and defines the approach and resources required to conduct program formulation.

2.2.3.2    The Program Commitment Agreement (PCA) is the agreement between the MDAA and the NASA AA (Decision Authority) that authorizes transition from formulation to implementation (KDP I). The PCA is prepared by the Mission Directorate with support from the Program Manager, as requested. The PCA documents Agency requirements, program objectives, management and technical approach and associated architecture, technical performance, schedule, cost, safety and risk factors, internal and external agreements, independent reviews, and all attendant top-level program requirements. A PCA can be considered an executive summary of the Program Plan and is updated and approved during the program life cycle, as appropriate. At a minimum, a significant change in program content, including the addition or deletion of a constituent project, warrants a change in the PCA. Changes to the PCA must remain consistent with the NASA Strategic Plan, higher-level architectures, and budget authority. The content of the initial PCA baselined at KDP I reflects the maturity of the program at that point in time and includes acknowledgment of those areas (such as schedule and cost) that cannot be defined without further development. The PCA is updated for subsequent KDPs and re-baselined as the program matures. The PCA template is found in Appendix D.

2.2.3.3    The Program Plan is an agreement between the MDAA (who has approval authority for the plan), the Center Director(s), and the Program Manager that documents at a high level the program's objectives and requirements, scope, implementation approach, interfaces with other programs, the environment within which the program operates, budget by fiscal year, and the commitments of the program. The Program Plan is prepared by the Program Manager with the support of program personnel. Implementation of a program, project, or task at a NASA Center is performed in accordance with the Program Plan and consistent with that Center's best practices, as negotiated and documented in the Program Plan. The agreements between the Program Manager and Center Directors of participating NASA Centers are documented in the Program Plan along with the Program Manager's approach to ensuring that interfaces do not increase risk to mission success. Program Plan concurrence by the participating NASA Center Directors demonstrates their commitment to support the program in terms of Center resources needed by the program.

2.2.3.3.1 The Program Plan is used by the governing PMC in the review process to determine if the program is fulfilling its agreements. The draft Program Plan is reviewed at KDP 0 (when required) and approved at KDP I. It is updated and approved during the program life cycle, as appropriate, similar to PCA updates. The content of the initial Program Plan baselined at KDP I reflects the maturity of the program at that point in time and acknowledges those areas (such as schedule and cost) that cannot be fully defined without further development. The Program Plan is updated for subsequent KDPs and re-baselined, if necessary, as the program matures.

2.2.3.3.2 The Program Plan details how the program will be managed, and contains the list of specific projects (updated as needed) that are officially approved as part of the program and, therefore, subject to the requirements on projects in this document. The Program Plan also documents the high-level program requirements, including performance, safety and programmatic requirements, correlated to Agency and Mission Directorate strategic objectives. These requirements are documented in the Program Plan, in a subsequent appendix, or in a separate, configuration-controlled program requirements document. The Program Plan template is found in Appendix E.

2.3       Project Life Cycle

2.3.1       For NASA space flight projects, the NASA life-cycle phases of formulation and implementation are divided into incremental pieces that allow managers to assess management and technical progress. The NASA Project Life Cycle is shown in Figure 2-4. The phases are separated by major reviews and KDPs. In practice, however, the activities described for each phase below are not always exclusively carried out in that phase; their timing will depend on the particular schedule requirements of the project. For example, some projects procure long-lead flight hardware in Phase B to enable them to achieve their launch dates.

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

2.3.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 Fabrication) and D (System Assembly, Integration and Test, and Launch), the primary activities are developmental in nature, including acquisition contract execution. Phase C includes the fabrication and testing of components, assemblies, and subsystems. All activities are executed as per the Project Plan developed during formulation. The transition from Phase C to Phase D is uniquely a "soft gate," in which the project may initiate Phase D work immediately upon completion of the Phase C work products, absent a notice of discontinuance by the Program Manager (rather than waiting for affirmative direction from the Program Manager to begin Phase D). The start of Phase E (Operations and Sustainment) marks the transition from system development and acquisition activities to primarily systems operations and sustainment activities. In Phase F (Closeout), project systems are taken out of service and safely disposed, although scientific and other analyses might still continue under project funding. Independent evaluation activities occur throughout all phases.

2.3.2       To initiate a new project, a Mission Directorate, 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 mission analysis, feasibility studies, technology needs analyses, and analyses of alternatives 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.

2.3.2.1      An MDAA 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 draft project FAD or equivalent (such as a Program Plan section, MDAA letter selecting a specific AO proposal, or a Program Directive that is used in the Space Station and Shuttle Programs). Following an ASP meeting, the updated project FAD is forwarded to the MDAA for final signature. Once the MDAA signs the project FAD, a project formally enters formulation.

2.3.2.2      Some Mission Directorates have chosen to establish several new space flight programs that use a one or two-step Announcement of Opportunity (AO) process to initiate projects. In a one-step AO process, projects are competed and selected for implementation in a single step. In two-step competitions, several projects may be selected in Step 1 and given time to mature their concepts in a funded Phase A before the Step 2 down-selection to one or more projects for further formulation. Program resources are invested (following Step 1 selections) to bring these projects to a state in which their science content, cost, schedule, technical performance, project implementation strategies, safety and mission assurance strategies, and management approach can be better judged.⁹ These projects are often referred to as competed or "AO-driven."

2.3.3       The Project Manager supports, as requested, the Mission Directorate and Program Manager in the development of program-level documentation and flows information down into project-level documentation. If requested by the Program Manager, the Project Manager assists in preparing a revised PCA and/or Program Plan. The Project Manager also supports, as requested, generation of the program requirements on the project and their formal documentation in the Program Plan (or as an appendix to the Program Plan). After the program requirements on the project are established, the Project Manager and the project team develop technical approaches and management plans to implement the requirements; these products are formally documented in the Project Plan. The Project Manager is then responsible for the evolution of the project concept and ultimate project success.

Figure 2-4 The NASA Project Life Cycle

2.3.4       NASA places significant emphasis on project formulation because adequate preparation of project concepts and plans is vital to success. During formulation, the project establishes performance metrics, explores the full range of implementation options, defines an affordable project concept to meet requirements specified in the Program Plan, develops needed technologies, and develops and documents the Project Plan. Formulation is an iterative set of activities rather than discrete linear steps. System engineering plays a major role during formulation, exercising an iterative set of activities as described in NPR 7123.1, NASA Systems Engineering Processes and Requirements. Activities include developing the system architecture and system design; flowing down requirements to the system/subsystem level; establishing the internal management control functions that will be used throughout the life of the project; assessing the technology requirements and developing the plans for achieving them; identifying options for partnering and commercialization; performing life-cycle cost (LCC) and mission effectiveness analyses for concepts deemed to have a high degree of technical and operational feasibility; and identifying margins and reserves consistent with project risk. 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, Center Director, and MDAA.

2.3.4.1      The Project Plan is an agreement among the Program Manager, participating Center Director(s), the Project Manager, and for AO-driven missions, the Principal Investigator (PI). (The MDAA may be added to the signature list for the plan at his/her discretion.) The Project Plan is prepared by the Project Manager with the support of the project team. It defines, at a high level, the project's objectives, technical and management approach, the environment within which the project operates, and the commitments of the project to the program. The Project Plan is required by the governing PMC and is used 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 if warranted by changes in the stated commitments or program requirements on the project.

2.3.4.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, and the Project Plan itself serves as the single source for such information. The Project Plan template is found in Appendix F.

2.4       Program and Project Oversight and Approval

2.4.1       This section describes NASA's oversight approach for programs and projects, and defines Key Decision Points (KDPs), when approval is given or denied, and identifies the Decision Authority (DA), the responsible official who provides that approval or disapproval.

2.4.2       The DA is the Agency's responsible individual who authorizes the transition at a KDP to the next life-cycle phase for a program/project. For programs and Category 1 projects, the DA is the NASA Associate Administrator (AA). For Category 1 projects, this authority may be delegated to the MDAA. For Category 2 and 3 projects, the DA is the MDAA. This authority may also be delegated to a lower level. The delegation of authority for projects is documented in the PCA.

2.4.3       To ensure the appropriate level of management oversight, NASA has established two levels of Program Management Councils (PMCs)- the Agency PMC and Mission Directorate PMCs. The PMCs have the responsibility of periodically evaluating the cost, schedule, risk, technical performance, and content of a program or project under its purview. The evaluation focuses on whether the program or project is meeting its commitments to the Agency. Each program and project has a governing PMC, which acts as the highest PMC for that program or project. For all programs, the governing PMC is the Agency PMC; for projects, the governing PMC is determined by the established project category. Table 2-2 shows the relationship between programs and projects (by category) and the PMCs.

Table 2-2 Relationship Between Programs/Projects and PMCs

2.4.3.1      The Agency PMC is the governing PMC for all programs and Category 1 projects. In that capacity, it evaluates them immediately prior to KDPs and then recommends approval or disapproval to the Decision Authority regarding entrance to the next life-cycle phase. The Agency PMC also performs program oversight during implementation by means of Quarterly Status Reports (QSRs) provided by the cognizant MDAA, and biennial Program Implementation Reviews (PIRs).

2.4.3.2      A Mission Directorate PMC (MDPMC) evaluates all programs and projects executed within that Mission Directorate and provides input to the MDAA. For programs and Category 1 projects, the MDAA carries forward the MDPMC findings and recommendations to the Agency PMC. For Category 2 and 3 projects, the MDPMC serves as the governing PMC and recommends approval or disapproval to the DA regarding entry to the next phase. For Category 3 projects, the DA may designate a division within the Mission Directorate or Program Office as the governing authority, and may even delegate decision authority to the chairperson of the designated governing board. Such designations and delegations are described in the relevant Program Plan.

2.4.4       Oversight of programs and projects is also performed by a Center Management Council (CMC), which evaluates all program and project work (regardless of category) executed at that Center. The CMC evaluation focuses on whether Center engineering, SMA, and management best practices (i.e., resources, procurement, institutional) are being followed by the program/project under review, and whether Center resources can support program/project requirements. The CMC also assesses program and project risk and evaluates the performance of activities to identify trends and provide technical guidance to the Agency and affected programs and projects. The CMC provides its findings and recommendations to Program/Project Managers and to the appropriate PMCs regarding the technical and management viability of the program/project prior to KDPs.¹⁰ For tightly coupled programs, the MDAA, Center Director(s), and NASA Chief Engineer establish the program approach for the CMC-equivalent process and documents the approach in the Program Plan.

2.4.5       A KDP is an event where the Decision Authority determines the readiness of a program/project to progress to the next phase of the life cycle. As such, KDPs serve as gates through which programs and projects must pass. KDPs associated with programs are enumerated with numerals, starting with zero; KDPs associated with projects are labeled with capital letters, the letter corresponding to the project phase that will be entered after successfully passing through the gate. Within each phase, the KDP is preceded by one or more reviews, including the governing PMC review. These reviews enable a disciplined approach to assessing programs and projects. Allowances are made within a phase for the differences between human and robotic space flight programs and projects, but phases always end with the KDP. The potential outcomes at a KDP include:

a.             Approval for continuation to the next KDP.

b.             Approval for continuation to the next KDP, pending resolution of actions.

c.             Disapproval for continuation to the next KDP. In such cases, follow-up actions may include a request for more information and/or a delta independent review; a request for a Termination Review for the program or the project (Phases B, C, D, and E only); direction to continue in the current phase; or re-direction of the program/project.

2.4.6       To support the decision process, appropriate supporting materials are submitted to the Decision Authority. These materials include:

a.             The governing PMC review recommendation.

b.             The Standing Review Board report (see Section 2.5).

c.             The MDAA recommendation (for programs and Category 1 projects).

d.             The Program Manager recommendation.

e.             The Project Manager recommendation (for project KDPs).

f.             The CMC recommendation.

g.             Program/project documents (FAD, Program Plan, PCA, Project Plan, or updates) that are ready for signature and agreements (MOUs, MOAs, waivers, etc.).

2.4.7       The Decision Authority makes his/her decision by considering a number of factors, including continued relevance to Agency strategic needs, goals, and objectives; continued cost affordability with respect to the Agency's resources; the viability and the readiness to proceed to the next phase; and remaining program or project risk (cost, schedule, technical, management, programmatic, and safety).

2.4.8       To complete formal actions at a KDP, the Decision Authority makes and documents the decision and its basis (including materials presented, major issues, options, and open action items) and archives the documents. Following the decision, the Decision Authority signs the required agreement(s) if no changes are required; if changes are required, the agreement(s) are revised, all necessary signatures obtained, and the agreement(s) resubmitted to the Decision Authority for final signature. Appeals must go to the next higher Decision Authority.

2.5       Program and Project Reviews

2.5.1       The program and project reviews identified in the life cycles are essential elements of conducting, managing, evaluating, and approving space flight programs/projects. In preparation for these reviews, programs and projects conduct internal reviews to initially establish and then manage the program/project baseline. These internal reviews are the decisional meetings wherein the program/projects solidify their plans, technical approaches, and programmatic commitments. This is accomplished as part of the normal systems engineering work processes of the program/project as defined in NPR 7123.1, NASA Systems Engineering Processes and Requirements. Major technical and programmatic requirements are assessed along with the system design and other implementation plans. Major technical and programmatic performance metrics are reported and assessed against predictions.

2.5.2       At the completion of the internal technical and programmatic reviews described in paragraph 2.5.1, an independent life-cycle review is conducted by a Standing Review Board (SRB).¹¹ The independent life-cycle review is conducted under documented Agency and Center review processes. Programs and projects are required to document in their Program and Project Plans their approach to conducting program/project internal reviews and how they will support the independent life-cycle reviews. Consistent with these processes and plans, the Terms of Reference (ToR) for each independent life-cycle review are jointly developed and approved/concurred by the respective individuals in Table 2-3.

2.5.2.1      The independent life-cycle review is convened by the same individuals (see Table 2-3) who develop the ToR to objectively assess the program/project's progress against the Program/Project Plan; its readiness to proceed to the next phase; compliance with NPR 7120.5 requirements; and for projects, the adequacy and credibility of the Integrated Baseline (at PDR and later). For the program and project reviews leading to program and project approval- P/SRR (PPAR) and P/SDR (PAR) for programs, and SRR/SDR/MDR (PNAR) and PDR (NAR) for Projects - a more integrated technical and programmatic review and evaluation is conducted, using the following criteria:¹²

a.             Alignment with and contributing to Agency needs, goals, and objectives, and the adequacy of requirements flow-down from those.

b.             Adequacy of technical approach, as defined by NPR 7123.1 entrance and success criteria.

c.             Adequacy of schedule.

d.             Adequacy of estimated costs (total and by fiscal year), including Independent Cost Analyses (ICAs) and Independent Cost Estimates (ICEs), against approved budget resources.

e.             Adequacy/availability of resources other than budget.

f.             Adequacy of risk management approach and risk identification/mitigation.

g.             Adequacy of management approach.

2.5.2.2      The 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 offer recommendations to improve performance and/or reduce risk. Its outputs are briefed to the program/project under review prior to being reported to the next higher level of management. Required ICAs/ICEs will be reconciled internally within the SRB and with the program/project prior to the PMC review.

2.5.2.3      The SRB has a single chairperson and a NASA¹⁴ Review Manager (RM). The chairperson and the RM are approved/concurred by the same individuals who convened the independent life-cycle review (see Table 2-3). The RM for programs, Category 1 projects, and Category 2 projects that are $250M and above is assigned by the Associate Administrator for PA&E; the RM for Category 2 projects below $250M and Category 3 projects is assigned by the Technical Authority. The chairperson, with support from the RM, organizes the review board, and submits the names of proposed board members to the same individuals who convened the independent life-cycle review for approval/ concurrence.

                  * Only for Category 2 projects that are $250M or above.

Table 2-3 Standing Review Board Protocols

2.5.2.4      The SRB remains intact, with the goal of having the same core membership for the duration of the program or project, although it may be augmented over time with specialized reviewers as needed. Board members must be independent of the program and project, and some members must be independent of the program's or project's participating Centers. Board members are chosen based on their management, technical, safety and mission assurance expertise, their objectivity, and their ability to make a broad assessment of the implementation of the program/project that employs numerous engineering and other disciplines. For programs, board members responsible for the Independent Cost Analysis (ICA) are provided by the Independent Program Assessment Office (IPAO). For Category 1 and 2 projects, board members responsible for the Independent Cost Estimate (ICE) are also provided by the IPAO. For Category 3 projects, board members responsible for the ICE may be provided by the IPAO, the Center Systems Management Office (SMO), or Center systems management function, as appropriate.

2.5.2.5      The RM actively supports each program/project independent life-cycle review by assisting the SRB chairperson, DA, MDAA (if not the DA), and TA in preparing the ToR; preparing team nomination letters; interfacing with the Program/Project Manager; managing review team administrative functions; ensuring that documented Agency and Center review policies and practices are followed; ensuring that Review Item Discrepancies (RIDs) and Requests for Action (RFAs) are tracked and closed; documenting and distributing SRB findings and recommendations; and preparing management briefings and reports.

2.5.2.6      Following each review, the SRB issues a board report within 30 days or as specified in the ToR for the review, and each such report is submitted to the relevant individuals (e.g., Decision Authority, MDAA, Program Manager, Project Manager, Technical Authority, Associate Administrator for PA&E, and participating Center Director(s)), along with recommended actions. Dissenting opinions are documented in the board report. The program/project assesses and dispositions the findings and recommendations of the SRB. Once program/project internal reviews and the SRB independent life-cycle review are complete, the life-cycle review milestone is considered complete.

2.5.2.7      For independent life-cycle reviews that do not directly precede a KDP (e.g., CDR), the CMC findings and recommendations, Program/Project Manager recommendations, and the SRB report are presented to the Mission Directorate PMC. At the discretion of the NASA AA, these review results for programs and Category 1 projects may be further reported to the Agency PMC.

2.5.2.8      A summary of the review process discussed above is shown in Figure 2-5. See Tables 2-4, 2-5, and 2-6 for a brief description of acquisition, program, and project reviews, respectively, with the caveat that not all reviews are applicable to every program and project.

2.5.2.9      The SRB is used for all independent life-cycle reviews shown on the program and project life cycles with the following exceptions:

a.               The ASP meeting and the ASM.

b.               The SMSR.

c.               The FRR and PFAR for tightly coupled programs at the discretion of the MDAA. (Rather than utilizing a complete independent review board for these flight and mission operations reviews, the program SRB chair and project SRB chairs that are part of the mission are included as advisory members to the flight and mission operations review boards. The SRB input is provided during the board meeting.)

d.               For human space flight, the PLAR and CERR, which are conducted by the Mission Management Team (MMT).

Figure 2-5 Program/Project Independent Life-Cycle Review Process

2.5.3       The Office of the Administrator, MDAA, or the Technical Authority may also convene special reviews as they determine the need. Circumstances that may warrant 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. In these cases, the MDAA or the Technical Authority forms a special review team composed of relevant members of the SRB and additional outside expert members, as needed. The MDAA or the Technical Authority provides the chair of the review with the ToR for the special review. The process followed for these reviews is the same as for other reviews. The special review team is dissolved following resolution of the issue(s) that triggered its formation.

2.5.4       NASA HQ SMA also has a Programmatic Audit and Review (PA&R) process described in NPR 8705.6, Safety and Mission Assurance Audits, Reviews, and Assessments. That process provides independent compliance verification for the applicable NASA SMA process and technical requirements within the program/project safety and mission assurance plan, the program baseline requirements set, and appropriate contract documentation. Program/Project Managers directly support the PA&R process (either Headquarters-led or Center-led) by providing logistics and resource support required for the successful execution of and response to PA&R process activities. They also coordinate with Center SMA and Center procurement officials to ensure that contracts provide for adequate contractor support for all PA&R activities, and they direct and authorize program/project contractors to support PA&R process activities.

2.5.5       If the Decision Authority is considering the termination of a program or a project in Phases B, C, D, or E, then a special termination KDP may be initiated. Circumstances such as the anticipated inability of the program or 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. For Category 2 and 3 projects, the Decision Authority notifies the NASA Associate Administrator at least 45 days (Category 2 projects) or 21 days (Category 3 projects) in advance of a termination KDP; for programs and Category 1 projects, the MDAA provides recommendations to the Decision Authority on the need for a termination KDP. The Decision Authority commissions an independent assessment, and following its completion, the governing PMC holds a Termination Review. For operating missions, terminations are handled in accordance with NPD 8010.3, Notification of Intent to Decommission or Terminate Operating Space Missions and Terminate Missions.

2.5.6       At the Termination Review, the program and the project teams present status, including any material requested by the Decision Authority. A Center assessment is presented as the Technical Authority (see Section 3.4) at the program or project level, or an OCE assessment is presented as the Technical Authority for tightly coupled programs with multiple Centers implementing the projects. Appropriate support organizations are represented (e.g., procurement, external affairs, legislative affairs, and public affairs), as needed. The decision and basis of decision are fully documented and reviewed with the NASA Associate Administrator prior to final implementation.

* This review is not subject to a SRB independent review.

Table 2-4 Space Flight Program and Project Acquisition Reviews

*This review is not subject to an SRB independent review.

Table 2-5 Space Flight Program Reviews

* This review is not subject to an SRB independent review.

Table 2-6 Space Flight Project Reviews

DISTRIBUTION:
NODIS