The project team continues developing the concept and architecture of the project, its major components, and the way they will be integrated, including its operations concepts. This includes continuing to work with the Launch Services Program at KSC to refine the viable launch service options, if appli- cable. In this phase, the LSP begins to refine spacecraft customer require- ments, prepare the acquisition strategy for the launch service, identify support services and estimated costs, establish dates for spacecraft delivery and complete a launch service assessment. System engineering plays a major role during Formulation as described in NPR 7123.1. The project performs the iterative and recursive process of functional analysis, requirements allo- cation, trade studies, preliminary synthesis, evaluation, and requirements analysis. As the project approaches the SRR, the project documents the updated concept and mission and spacecraft architecture and defines and documents the preliminary ground and payload architectures and prelimi- nary operations concept.
Based on the leading concept, the project finalizes the initial mission objec- tives and project-level requirements, including allocated and derived requirements down to at least the system level. If not already defined, the project team identifies the payload risk classification as described in NPR 8705.4. The project needs to continue to update and maintain the requirements traceability matrix initially developed in Pre–Phase A. The project team assesses the ability of the project and all contributors to the project, including contractors, industrial partners, and other partners
The Basis of Estimate (BoE) documents the ground rules, assumptions, and drivers used in developing the cost and schedule estimates, including applicable model inputs, rationale or justification for analogies, and details supporting cost and schedule estimates. The BoE is contained in material available to the Standing Review Board (SRB) and management as part of the life-cycle review and Key Decision Point (KDP) process. Good BoEs are well-documented, comprehensive, accurate, credible, traceable, and executable. Sufficient information on how the estimate was developed needs to be included to allow review team members, including independent cost analysts, to reproduce the estimate if required. Types of information can include estimating techniques (e.g., bottoms-up, vendor quotes, analogies, parametric cost models), data sources, inflation, labor rates, new facilities costs, operations costs, sunk costs, etc.
4.3 Project Formulation
commonly known as the metric system of measurement). This assessment determines an approach that maximizes the use of SI while minimizing short- and long-term risk to the extent practical and economically feasible or to the extent that the supply chain can support utilization without loss of markets to U.S. firms. Use of the SI or metric system of measurement is especially encouraged in cooperative efforts with international part- ners. This assessment documents an integration strategy if both SI and U.S. customary units are used in a project. The assessment is completed and documented in the preliminary Project Plan no later than the SDR/MDR. To the degree possible, projects need to use consistent measurement units throughout all documentation to minimize the risk of errors. Where full implementation of the metric system of measurement is not practical, hybrid configurations (i.e., a controlled mix of metric/nonmetric system elements) may be used to support maximum practical use of metric units for design, development, and operations. Where hybrid configurations are used, the project describes the specific requirements established to control interfaces between elements using different measurement systems.
Following the SRR, the project updates the concept documentation, archi- tectures, and operations plans based on the results of the SRR and continues to perform analyses and trades in support of concept/design refinement. It prepares the preliminary design documentation for use during the peer reviews, subsystem reviews, and system reviews leading to the project’s SDR/MDR. The project updates the design documentation as changes are made during this process in accordance with the project team’s and Center’s standard practices.
Projects that plan to develop technologies initiate the development of tech- nologies as agreed to in the Formulation Agreement. As the technologies develop, the project monitors, assesses, and reports the status of technology readiness advancement. Projects update their technology development plans, including assessment points to terminate development of technologies that are not maturing adequately with corresponding alternate approaches. Projects implement engineering development plans, heritage hardware and software assessments (using the Systems Engineering Handbook, NASA/
SP-2007-6105 Rev 1, Appendix G), and risk mitigation plans identified in the
project Formulation Agreement for Phase A. As these risk reduction plans are executed, the project monitors, assesses, and reports the status of engi- neering development results and heritage assessments. Projects update their plans when needed.
In accordance with NPR 2190.1, NASA Export Control Program, the project supports the appropriate NASA export control officials to identify and assess export-controlled technical data that potentially will be provided to
4.3 Project Formulation
International Partners and the approval requirements for release of that data as a part of developing the project’s preliminary Technology Transfer Control Plan.
To provide additional options in the event that development begins to exceed the resources allocated, the project typically begins to refine the list of descope options. Documentation of the project’s descope plans typi- cally includes a detailed description of the potential descope, the effect of the descope on the project’s success criteria, the cost and schedule savings resulting from the descope, and key decision dates by when the descope needs to be exercised to realize these savings.
The Project Plan contains a number of required control plans, many of which are technical. NPR 7120.5E, Appendix I, Table I-5, and Table 4-7 at the end of this chapter, show the control plans that are required during Phase A and when they need to be developed. Each of the technical control plans is described in this handbook section.
The project team baselines at SRR the preliminary SEMP developed at MCR and updates the SEMP at SDR/MDR. The SEMP is required to be a stand- alone plan unless an alternate approach is approved.
If applicable, in accordance with NPR 7123.1B, the project baselines the Human Systems Integration (HSI) Plan at SRR. The HSI Plan is updated at SDR/MDR.
The project baselines a SMA Plan by SRR and updates the plan at SDR/ MDR. The SMA Plan addresses life-cycle SMA functions and activities. The plan identifies and documents project-specific SMA roles, responsibilities, and relationships. This is accomplished through a project-unique mission assurance process map and matrix developed and maintained by the project with appropriate support and guidance from the Headquarters and/ or Center-level SMA organizations. The plan addresses areas that include procurement, management, design and engineering, design verification and test, software design, software verification and test, manufacturing, manu- facturing verification and test, operations, and preflight verification and test. The plan also addresses specific critical SMA disciplines, including the following as a minimum:
⦁ Safety per NPR 8715.3; NPR 8715.5, Range Flight Safety Program; NPR
8715.7, Expendable Launch Vehicle Payload Safety Program; local range
requirements; and NPR 8621.1, NASA Procedural Requirements for
Mishap and Close Call Reporting, Investigating, and Recordkeeping.
⦁ Human rating requirements per NPR 8705.2, Human-Rating Require-
The Mission Assurance Process Map is a high-level graphic representation of governing SMA policy and requirements, processes, and key participant roles, responsibilities, and interactions. It also includes the reporting structure that constitutes a project’s SMA functional flow. The Mission Assurance Process Matrix is constructed to identify project life-cycle assurance agents and specific assurance activities, processes, responsibilities,
accountability, depth of penetration, and independence. The matrix includes key assurance personnel in engineering, manufacturing, project
4.3 Project Formulation
⦁ Quality assurance per NPD 8730.5, NASA Quality Assurance Program
Policy; NPD 8730.2, NASA Parts Policy; and NPR 8735.1, Procedures for Exchanging Parts, Materials, Software, and Safety Problem Data Utilizing the Government-Industry Data Exchange Program (GIDEP) and NASA Advisories.
⦁ Limiting the generation of orbital debris per NPR 8715.6;
⦁ Compliance verification, audit, SMA reviews and SMA process maps per
NPR 8705.6, Safety and Mission Assurance (SMA) Audits, Reviews, and Assessments.
⦁ Reliability and maintainability per NPD 8720.1, NASA Reliability and
Maintainability (R&M) Program Policy.
⦁ Software safety and assurance per NASA-STD-8719.13, NASA Software
Safety Standard and NASA-STD-8739.8, Software Assurance Standard.
⦁ Software engineering requirements for safety critical software per
NPR 7150.1, NASA Software Engineering Requirements.
⦁ Quality Assurance functions per NPR 8735.2, Management of Govern-
ment Quality Assurance Functions for NASA Contracts.
⦁ Other applicable NASA procedural safety and mission success require- ments.
In the SMA Plan, the project describes how it will develop and manage a closed-loop corrective action system/problem reporting and resolution system and how it develops, tracks, and resolves problems. The process needs to include a well-defined process for data collection and a data collec- tion system for hardware and software problem and anomaly reports, problem analysis, and corrective action. The SMA Plan is required to be a stand-alone plan unless an alternate approach is approved.
At SDR/MDR, the project updates the Technology Development Plan, base- lined at MCR. This plan may be part of the Formulation Agreement rather than a separate plan.
The project develops the preliminary Information Technology Plan by SRR and baselines the plan by SDR/MDR. This plan describes how the project will acquire and use IT. It documents the project’s approach to imple- menting IT security requirements in accordance with NPR 2810.1, Secu-
rity of Information Technology with emphasis on conducting the Informa-
tion/System Security Categorization required by NPR 2810.1 for IT systems during Phase A of the project. The plan describes:
⦁ The steps the project will take to ensure that the information technology it acquires and/or uses complies with NPR 2830.1, NASA Enterprise
4.3 Project Formulation
⦁ How the project will manage information throughout its life cycle, including the development and maintenance of an electronic project library;
⦁ How the project will ensure identification, control, and disposition of project records in accordance with NPD 1440.6, NASA Records Manage-
ment and NPR 1441.1, NASA Records Retention Schedules;
⦁ The project’s approach to knowledge capture, as well as the methods for contributing knowledge to other entities and systems, including compli- ance with NPD 2200.1, Management of NASA Scientific and Technical
Information and NPR 2200.2, Requirements for Documentation, Approval, and Dissemination of NASA Scientific and Technical Information.
The project develops one or more preliminary Software Management Plan(s) by SRR and baselines them by SDR/MDR. This plan summa- rizes how the project will develop and/or manage the acquisition of soft- ware required to achieve project and mission objectives. It is developed as a stand-alone Software Management Plan that includes the content required by NPR 7150.2, NASA Software Engineering Requirements and NASA-
STD-8739.8, Software Assurance Standard, unless approved otherwise. The
plan needs to be aligned with the SEMP.
The project develops a preliminary Verification and Validation Plan by SDR/MDR. (This plan is baselined at PDR.) This plan summarizes the project team’s approach for performing V&V of the project products. It indi- cates the methodology to be used in the V&V (test, analysis, inspection or demonstration) as defined in NPR 7123.1. At this point in time, the level of detail is consistent with the level of detail of the concept/design.
The project updates the preliminary Review Plan presented at MCR, base- lines the plan at SRR, and updates it at SDR/MDR. This plan summarizes the project’s approach for conducting a series of reviews, including internal reviews and project life-cycle reviews in accordance with Center best prac- tices, program review requirements, and the requirements in NPR 7123.1 and NPR 7120.5. The Review Plan identifies the life-cycle reviews the project plans to conduct and the purpose, content, and timing of those life-cycle reviews, and documents any planned deviations or waivers granted from the requirements in NPR 7123.1 and NPR 7120.5E. It also provides the tech- nical, scientific, schedule, cost, and other criteria that will be utilized in the consideration of a Termination Review.
The project baselines the Environmental Management Plan by SDR/MDR. This plan describes the activities to be conducted at all project locations with support from the responsible Environmental Management Office to comply
For projects that are part of tightly coupled programs, project life-cycle reviews and Key Decision Points (KDPs) are planned in accordance with the project life cycle and KDP sequencing guidelines in the Program Plan. The Review Plan documents the sequencing of each project life-cycle review and KDP with respect to the associated program life-cycle review and KDP. In addition, the Review Plan documents which project KDPs are conducted simultaneously with other projects’ KDPs and which project KDPs are conducted simultaneously with the associated program KDPs. The sequencing of project life-cycle reviews and KDPs with respect to program life-cycle reviews and KDPs is especially important for project Preliminary Design Review (PDR) life-cycle reviews that precede KDP Cs. Since changes to one project can easily impact other projects’ technical, cost, and schedule baselines, and potentially impact other projects’ risk assessments and mitigation plans, projects and their program generally need to proceed
4.3 Project Formulation
with NPR 8580.1, NASA National Environmental Policy Act Management
Requirements and Executive Order 12114. Specifically, the plan:
⦁ Identifies all required permits, waivers, documents, approvals, or concur- rences required for compliance with applicable Federal, State, and Tribal Government, and local environmental laws and regulations;
⦁ Plans the level of National Environmental Policy Act (NEPA) documen- tation required to satisfy NEPA requirements prior to KDP C and Project Implementation; e.g., the Environmental Checklist and Record of Envi- ronmental Consideration (REC), Environmental Assessment (EA), and Environmental Impact Statement (EIS). The project’s plans are based on the program’s NEPA strategy at all affected Centers, which is devel- oped in consultation with the NASA Headquarters NEPA coordinator to ensure the most effective, least resource-intensive strategy to meet NEPA requirements across the program and its constituent projects.
⦁ Describes the documentation and schedule of events for complying with these regulations, including identifying any modifications to the Center’s Environmental Management System (EMS) that would be required for compliance; and
⦁ Defines the critical milestones associated with complying with these regulations that need to be inserted into the project schedule. Smaller projects and projects with limited environmental impacts may be able to satisfy this requirement, with approval from the requirements holder, using the “Project Environmental Management Planning Checklist,” which can be found on the EPPMD Community of Practice. A checklist is completed for each NASA Center or facility that the project will use. The project develops a preliminary Integrated Logistics Support (ILS) Plan by SRR and updates it at SDR/MDR (the plan is baselined at PDR). This plan describes how the project will implement NPD 7500.1, Program
and Project Life Cycle Logistics Support Policy, including a maintenance and
support concept; participation in the design process to enhance support- ability; supply support; maintenance and maintenance planning; packaging, handling, and transportation; technical data and documentation; support and test equipment; training; manpower and personnel for ILS functions; facilities required for ILS functions; and logistics information systems for the life of the project.
The project develops a preliminary Integration Plan by SDR/MDR. This plan defines the integration and verification strategies and is structured to show how components come together to assemble each subsystem and how the subsystems are assembled into the system/product. The primary purposes of the Integration Plan are to: (1) describe this coordinated
4.3 Project Formulation
integration effort that supports the implementation strategy, (2) describe for the participants what needs to be done in each integration step, and (3) iden- tify the required resources and when and where they will be needed. The project baselines the Configuration Management Plan by SRR and updates it at SDR/MDR. This plan describes the configuration management approach that the project team will implement, consistent with NPR 7123.1 and NASA-STD-0005, NASA Configuration Management (CM) Standard. It describes:
⦁ The structure of the configuration management organization and tools to be used;
⦁ The methods and procedures to be used for configuration identification, configuration control, interface management, configuration traceability, and configuration status accounting and communications;
⦁ How configuration management will be audited; and
⦁ How contractor configuration management processes will be integrated with the project.
The project develops a preliminary Security Plan by SDR/MDR. This plan describes the project’s plans for ensuring security and technology protec- tion. It includes three types of requirements: security, IT security, and emer- gency response. It describes the project’s approach for planning and imple- menting the requirements for information, physical, personnel, industrial, and counterintelligence/counterterrorism security and for security aware- ness/education requirements in accordance with NPR 1600.1, NASA Security
Program Procedural Requirements and NPD 1600.2, NASA Security Policy. It
includes provisions to protect personnel, facilities, mission-essential infra- structure, and critical project information from potential threats and other vulnerabilities that may be identified during the threat and vulnerability process. IT security requirements document the project’s approach to imple- menting requirements in accordance with NPR 2810.1, Security of Informa-
tion Technology. The plan also describes the project’s emergency response
plan to meet the emergency response requirements in NPR 1040.1, NASA
Continuity of Operations (COOP) Planning Procedural Requirements and
defines the range and scope of potential crises and specific response actions, the timing of notifications and actions, and the responsibilities of key indi- viduals.
The project manager ensures development of a preliminary Project Protec- tion Plan by SDR/MDR. For more information on about Project Protection Plan specifics, go to the Community of Practice for Space Asset Protection at https://nen.nasa.gov/web/sap. The project develops a preliminary Tech-
4.3 Project Formulation
will control its technology to implement the export control requirements specified in NPR 2190.1, NASA Export Control Program.
The project develops a preliminary Knowledge Management Plan by SDR/ MDR. This plan describes the project’s approach to creating the knowledge management strategy and processes, including practices and approaches for identifying, capturing and transferring knowledge; and capturing and docu- menting lessons learned throughout the project life cycle in accordance with NPD 7120.4 and as described in NPD 7120.6, Knowledge Policy on Programs
and Projects and other appropriate requirements and standards documenta-
tion.
The Human Rating Certification Package (HRCP) is required for human space flight missions. If the program has done an HRCP, the project may refer to the program HRCP. The initial HRCP is developed by SRR and updated at SDR/MDR. The HRCP is developed per NPR 8705.2. Human rating certification focuses on the integration of the human into the system, preventing catastrophic events during the mission, and protecting the health and safety of humans involved in or exposed to space activities, specifically the public, crew, passengers, and ground personnel.
The project prepares a Planetary Protection Plan by SDR/MDR that speci- fies management aspects of the planetary protection activities of the project. Planetary protection encompasses: (1) the control of terrestrial microbial contamination associated with space vehicles intended to land, orbit, flyby,