![[NASA Logo]](../Images/nasaball.gif) |
NASA Procedures and Guidelines |
||||
This Document is Obsolete and Is No Longer Used.
|
|||||
|
|
|||||
|
|
||||
| | TOC | Preface | Change_Log | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | Chapter6 | Chapter7 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | AppendixF | AppendixG | AppendixH | AppendixI | AppendixJ | AppendixK | AppendixL | AppendixM | AppendixN | AppendixO | ALL | | |||||
6.1.a Flight systems and ground support projects are often the most visible and complex of NASA's product lines. Because of this, these projects must emphasize safety and mission success as primary drivers in order to justify the substantial time and resources they require. These projects typically have formulation periods of one to three years because of the need to conduct system analyses, select the best mission concept, and retire technological risks to the point where implementation can begin. They typically have even longer implementation periods for design, development, testing, and operations. Due to this, NASA has found it useful to decompose the project life cycle for flight systems and ground support projects into more incremental pieces that allow managers to assess management and engineering progress. Consequently, this document re-institutes the NASA project life cycle consisting of Phases A through F.
6.1.b Project formulation consists of two sequential phases, traditionally denoted as Phases A and B, while project implementation consists of Phases C, D, E and F. Approval marks the transition from Phase B of formulation to Phase C of implementation. The start of Phase E marks the transition from primarily development activities to primarily systems operations and sustaining and maintenance activities. Independent evaluation activities occur throughout all the phases. 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.
6.1.c Some of these flight systems and ground support projects have long-term operations and sustainment periods, lasting decades.36 In these cases, the Project Manager needs to maintain a strategic view and value flexibility while managing established operations and sustainment activities. The new Vision for Space Exploration also envisions an evolving system-of-systems, in which established operations and sustainment activities will likely exist along side new flight systems and ground support projects seeking enhanced capabilities in an evolutionary acquisition approach ("spirals").
6.1.d In recent times, NASA has chosen to establish several new flight projects using a one or two-step Announcement of Opportunity (AO) process. These projects are often referred to as "AO-driven." AO solicitations are often used for the development of small and mid-sized scientific spacecraft, and are cost-capped and highly competitive. Several PI-led teams prepare detailed proposals aimed at meeting program-level requirements, and a winner is selected at the end of a rigorous selection process. Pre-Phase A includes the development of Step 1 proposals and Phase A develops Step 2 proposals. Since the selection process involves a great deal of independent assessment, the normal requirements for a preliminary NAR are waived, and the emphasis shifts to the NAR (or equivalent, often referred to as the Confirmation Review (CR)) at the end of Phase B for review and approval.
6.1.e As a result of these different approaches to acquisition, this document recognizes variations from the traditional flight systems and ground support project cycle. Figure 6-1 shows the project lifecycle and GPMC milestone decision reviews for these different approaches.
Figure 6-1. Flight Systems and Ground Support Project Lifecycle
Phases
and Milestone Decision Reviews
6.1.f New cost estimation requirements for flight systems and ground support projects are another important addition to this document. Category I and II projects must develop a CADRe. Cost-risk identification and quantification of medium- and high-risks are an integral new addition to project lifecycle cost estimates. Consistent with Continuous Cost Risk Management (CCRM), these medium- and high-risks are identified for performance measurement reporting in the application of earned value management. While conceptually related to the DoD CARD, the CADRe is NASA's unique response to the need to improve cost estimates during formulation, and to do project grass roots and independent cost estimation based on the same information. The CADRe is a comprehensive document, developed and configuration controlled by the project, that provides a technical and quantitative description of the project in terms that permit the development of a LCCE. Typically, the contractor and/or NASA project engineers, assisted by cost estimators and the Center SMO, construct the CADRe. The CADRe should be considered a "living document", which is matured at major milestones.
6.1.g With the CADRe as a basis, each flight systems and ground support project is expected to develop a risk-based LCCE, and to manage that as part of the Project Baseline through a process called CCRM (Continuous Cost Risk Management), described in Reference L.2.c(1). At the end of the project lifecycle, the project's actual cost, schedule, and technical parameters by WBS are then captured in the ONCE (One NASA Cost Engineering) database as part of the project library.
6.1.h Flight systems and ground support projects shall meet the requirements of the four-part management process described in Chapter 3 and the requirements in this chapter. For projects for which the concept of operations requires activities such as extensive refurbishment of a flight system, extensive re-supply or maintenance (ground and on-orbit), additional requirements are imposed to cover additional planning, analysis and other activities necessary for a successful Phase E. These will generally be preceded with the phrase "For projects with long-term operations and sustainment" in italics. These additional requirements are not intended for projects with extended cruise time.
6.2.a Because of the challenges and uncertainties associated with developing these projects, it is essential that formulation activities fully prepare the project for implementation, and where applicable, long-term operations and sustainment. During formulation, the Project Manager performs and orchestrates the following activities:
6.2.1 Project Planning Requirements: The Project Manager and the project team shall:
6.2.1.a Structure the detailed product-based project WBS and WBS dictionary based on the standard WBS in Appendix J, or shall obtain approval for WBS tailoring from the OCFO and OCE.
6.2.1.b Generate a Contract WBS that supports cost/schedule control requirements for each contract following contractor selection or authority to proceed to implementation (see paragraph 3.4.3.2 for detailed EVM requirements).
6.2.1.c Generate and maintain an Integrated Master Schedule (IMS) in the form of a detailed, logic-driven, highly-integrated network schedule using an automated project management (automated time phasing of tasks, critical path determination, schedule assessment, trend analysis, sort, select, and summarization capabilities, etc.) tool.
6.2.1.d Obtain the additional approval of the cognizant MDAA for the Project Plan, at the discretion of the Mission Directorate.
6.2.1.e Develop a Software Management Plan in accordance with NPR 7150.2, NASA Software Engineering Requirements.
6.2.1.f Form an operations team organization compatible with the operations portion of the WBS and the project's flight and ground operations concept. This team shall include expertise in the following areas: flight operations, ground operations, safety, mission assurance, logistics, sustaining engineering, and any other expertise required for a successful Phase E, and/or Phase F.
6.2.1.g Assure that the project team seeks to learn and apply relevant lessons from successful flight systems and ground support projects, mission anomalies and mishaps.
6.2.1.h Maintain the project team awareness of emergency response plans and procedures. The Project Manager and project team shall develop, maintain and test their project-specific plans (e.g., ground and mission emergency/contingency/failure plans) to ensure the team is adequately trained and prepared.
6.2.2 Cost Estimation Requirements: The following requirements apply to both AO-driven and non-AO-driven flight systems and ground support projects, with exceptions for AO-driven projects noted:
6.2.2.a For Category I and II projects, the Project Manager shall complete a preliminary CADRe (Parts A and B), in accordance with Table H-4 in Appendix H. Appendix E contains the initial CADRe DRD, but the latest CADRe DRD, available in the on-line NASA Cost Estimation Handbook (http://www.ceh.nasa.gov/), should be used. For AO-driven projects, the requirement for a preliminary end-of-Phase A CADRe is waived in lieu of the submission of a copy of the winning proposal and concept study report.
6.2.2.b For Category I and II projects, the Project Manager shall develop a risk-based LCCE (including a project cost S-curve) consistent with the preliminary CADRe for presentation at the preliminary NAR. This LCCE is called the project estimate and is appended to the CADRe as Part C.
6.2.2.c For Category I and II projects, the Project Manager shall develop a Baseline CADRe and a risk-based LCCE (including a project cost S-curve) consistent with the Baseline CADRe for presentation at the NAR. This LCCE is called the NAR estimate and is appended to the CADRe as Part C. AO-driven Category I and II projects shall develop a risk-based LCCE (including a project cost S-curve) consistent with the Baseline CADRe for presentation at their Confirmation Review. This LCCE is called the CR estimate and is appended to the CADRe as Part C.
6.2.2.d Category I and II projects shall provide updated CADRe submissions (all parts37 ) at:
6.2.2.e For projects with long-term operations and sustainment, the Project Manager shall work with the OCFO to establish a nominal project end date for the purpose of estimating operations and sustainment costs.
6.2.3 Systems Engineering Requirements: The Project Manager and the project team shall:
6.2.3.a Working with the Mission Directorate, Program Manager, customers and stakeholders, define a validated set of project requirements that are levied by the program and that include mission success criteria. These high-level project requirements shall be placed under configuration control in Phase A
6.2.3.b Develop operations scenarios and concepts, mission profiles, and mission operational modes for the purpose of fostering a better understanding of operational requirements, including LCC drivers for logistics and maintenance. The concept of operations describes the "who, what, when, where, and how" of the system.
6.2.3.c Define the internal and external operational environments for the flight system.
6.2.3.d For projects with long-term operations and sustainment, the concept of operations shall include the operational KPPs; the sustaining engineering, mission operations, ground operations, and integrated logistics support (e.g., maintenance concepts(s), sparing philosophy) concepts necessary for a successful Phase E.
6.2.3.e For projects with long-term operations and sustainment, complete planned cost-performance trades, Analysis of Alternatives (AoA) studies, Cost As an Independent Variable (CAIV) assessments, and other systems analyses that include these operational KPPs as measures of effectiveness/measures of performance.
6.2.3.f Define a validated set of flight and ground system requirements, including interface requirements and specialty engineering (e.g., safety, reliability) requirements.
6.2.3.g Define a validated set of enabling system requirements, especially for integrated logistics support. (See NPD 7500.1, Program and Project Logistics Policy.)
6.2.3.h Ensure that the requirements flow hierarchy is consistent with the Work Breakdown Structure.
6.2.3.i Establish and maintain a (configuration-managed) requirements baseline in an established database.
6.2.3.j Evaluate major changes to the requirements baseline through the systems analysis process as needed prior to any approval of such changes.
6.2.3.k Ensure that trade studies are documented as part of the project library.
6.2.3.l Ensure that models and simulations used to support these trade studies have been validated. Early in formulation, the project team should identify, develop, or otherwise acquire and implement the models (including prototypes and simulations) needed to accomplish all trade studies.
6.2.3.m Identify and plan a series of trade studies to determine the most cost-effective means of meeting requirements for communications, tracking, data processing, and mission operations, including commercial options.
6.2.3.n For Category I flight systems and ground support projects, complete an initial Probabilistic Risk Assessment (PRA) during formulation. NPR 8000.4, Risk Management Procedural Requirements, provides general criteria for selecting the scope of the PRA, while NPR 8705.5, Probabilistic Risk Assessment Procedures for NASA Programs and Projects, provides detailed procedures for performing a PRA.
6.2.3.o Develop a technical resource margin management approach, and implement a tracking and reporting process to support it.
6.2.4 Project Assessment and Control Requirements: The Project Manager and the project team shall:
6.2.4.a Monitor changes in the project estimate presented at the preliminary NAR, and immediately inform the Program Manager if it increases by more than 25% in Phase B. The Project Manager should make every effort to produce a project cost estimate that contains an adequate cost-risk margin. During Phase B, life cycle cost growth beyond 25% of the preliminary NAR project estimate may result in a Termination Review initiated by the Program Manager or MDAA.
6.2.4.b Provide the MDAA a Project Status Report (PSR) in formats ready for reporting to the OCFO when required to do so, as defined in GAO Report B-237602, "Project Status Reports."38 The OCFO will validate the PSR and forward it, through the Office of Legislative Affairs, to the appropriate congressional committees.
6.3.1 Purpose: The project approval process for flight systems and ground support projects is an on-going effort by senior NASA management to determine the project's readiness (at key milestones) to proceed to the next project phase or to implementation. To secure approval for a flight system and ground support project, the Project Manager shall prepare (or revise) key project management documents (Project Plan, etc.) and presents them to the GPMC at a decision review meeting.
6.3.2 In addition to the requirements in paragraph 3.3.4 that deal with the NAR, the Project Manager must also successfully pass a preliminary NAR at the Phase A to B transition. Flight systems and ground support projects using the AO process have the equivalent of the preliminary NAR in the Step 2 proposal selection process, and are exempt from requirements pertaining to the preliminary NAR. To avoid unnecessary duplication of review events, these decision review meetings for the first project in a program are generally timed to coincide with the program's preliminary NAR and NAR. For all programs that use evolutionary acquisition, there are two additional decision reviews--the Concept Decision Review, occurring before formal formulation activities start, and the Production Review, occurring during implementation before significant production activities start. Table 6-1 shows the required project decision reviews.
Table 6-1. Project Decision Reviews
6.3.3 NASA will modify its project evaluations and management accountability hierarchy to accommodate projects that are part of an evolving system-of-systems. Specifically, when a Mission Directorate uses an evolutionary acquisition approach, program decision reviews by the Agency PMC will occur at the "spiral level", and decision review meetings for the major program elements (i.e., projects) will be held by the GPMC to coincide with the spiral decision reviews. The NASA Deputy Administrator is the authority for these types of Agency PMC decision reviews. Because this is a new approach to project approval, NASA senior management plans to revisit the number and level of decision review meetings after some experience has been gained.
6.3.4 Requirements: In support of GPMC decision review meetings during project approval:
6.3.4.a The Project Manager shall support evaluation by the IA organization in accordance with the project evaluation process. (See Section 6.5.)
6.3.4.b The Project Manager shall prepare a project overview briefing for presentation at the GPMC milestone decision review meeting to include a summary of the project, the status of project documentation and products, and significant risks, all appropriate to the level of project maturity.
6.3.4.c The Project Manager shall ensure that the project documents and products described in Table 6-2 are available at the GPMC decision review.
6.3.4.d At that meeting, the IA results and findings, including the results of an ICE or ICA, will also be presented. The Project Manager shall then follow with a presentation of responses to the IA findings.
6.3.5 When all presentations are concluded, the GPMC convenes an executive session to discuss the material presented and determines whether to recommend approval to the appropriate decision authority. The decision authority for Category I projects is the Deputy Administrator; for Category II projects, the MDAA (or MSOD); and for Category III projects, the Center Director (of the executing Center). A positive recommendation may be unconditional, or conditional on the Project Manager completing assigned action items, some of which address the IA organization findings. A negative recommendation by the GPMC could result in decision authority direction to the Project Manager to address the deficiencies, or in a decision authority recommendation to the next higher GPMC decision authority to authorize a Termination Review. If project approval requires a modification to the PCA, the MDAA (or MSOD) is responsible for obtaining PCA approval by the Deputy Administrator. Upon GPMC approval, the project's NAR Baseline is formally established.
Table 6-2. Key Project Documents and Product Maturity by Decision Review
6.4.a Project implementation entails continued execution of the Project Plan and all activities leading up to the successful delivery of the product or service that meets the original requirements. Successful project implementation relies on close interaction between the project team and the user and/or customer of the product or service. The Project Manager shall comply with the requirements in Section 3.4, and shall meet additional requirements in the following activities:
6.4.1 Project Assessment and Control Requirements: The Project Manager and the project team shall:
6.4.1.a Determine and implement appropriate means for observing the project in all phases where technical risks have been identified, along with a means for collecting, trending, archiving, and analyzing data for post-anomaly investigation.
6.4.1.b Implement a system to access "as-built" configurations, including photographic records and engineering drawings of all critical subsystem modifications, to assist in real-time troubleshooting.
6.4.2 Systems Engineering Requirements: The Project Manager and the project team shall:
6.4.2.a For Category I projects, ensure that the PRA is updated throughout implementation. The Project Manager should integrate PRA results into system design and operational risk mitigation trades.
6.4.2.b Track and report project technical resource margins periodically throughout implementation.
6.4.2.c Conduct Physical and Functional Configuration Audits.
6.4.2.d For projects with long-term operations and sustainment, evaluate (using the systems analysis process) upgrades or modifications to deployed project systems, alternative product improvement investments, and decommissioning/disposal alternatives, as needed.
6.4.3 Design, Develop, Transition-to-Use, and Operations Requirements: The Project Manager and the project team shall:
6.4.3.a Deliver, deploy, and transition-to-use project flight and ground systems.
6.4.3.b Deliver new technology through data, information, products, and services.
6.4.3.c Execute acceptance/turnover agreements and data for those products requiring transfer of custodial responsibility.
6.4.3.d Establish and maintain an integrated logistics support capability, including spares, ground support equipment, system maintenance and operating procedures, in order to sustain deployed hardware and software systems, consistent with mission requirements and plans.
6.4.3.e Establish and maintain other enabling systems, as needed, so as to ensure that critical facilities, equipment, materials, training, simulation support, and other services are available when needed.
6.4.3.f Provide sustaining engineering to promote efficiency enhancements, safety enhancements, and accommodate obsolescence.
6.4.3.g Refine and implement plans for disposition/decommissioning of project assets (flight and ground) after the end of their useful life.
6.4.3.h For projects with long-term operations and sustainment, the project during Phase E refines its operations success criteria, operations concept and plans to meet mission objectives specified in the Program and Project Plans, but the focus is on the tactical execution of the next mission increment, launch, or mission epoch. As the project produces its intended products and services, it continually explores new operations and sustainment options to meet the overall objectives, reduce operations costs and operational risks; fine tunes the internal management control functions that will be used throughout the remaining life of the project; assesses new technologies, modifications, and upgrades that potentially increase safety and performance, and lower operations costs; and tracks operational margins and reserves consistent with project safety requirements. If necessary, agreements (Program and Project Plans) are modified, and approved in accordance with the approval process. In order to accomplish this, the Project Manager and the project team shall:
6.4.4 Capture Knowledge Requirements: The Project Manager and the project team shall:
6.4.4.a Capture and forward summaries of project costs as a function of the WBS and other performance information, to the OCFO Cost Analysis Division for inclusion in the ONCE database using the CADRe format.
6.4.4.b Archive all relevant project records and data (drawings, analyses, reports, etc.) in the project library in electronic format.
6.5.1 Due to the visibility, risk and importance to the Agency, flight systems and ground support projects are assessed more frequently and monitored more closely than other types of projects. At a minimum, flight systems and ground support projects are subject to a preliminary NAR (Phase A to B), NAR (Phase B to C), and surveillance following the NAR. For the first project within a program, the decision reviews are conducted concurrently with the program reviews. For initial planning purposes, the Project Manager should consult Table H-4 in Appendix H. The flight development project evaluation process flow is the same as that for a project NAR as described in paragraph 3.5.8.
6.5.2 Flight development projects are closely monitored during implementation by IA organizations through a surveillance activity. The purpose of surveillance is to provide timely reporting to the GPMC when the project is showing adverse trends in its performance. After NAR approval, the responsible IA organization will conduct project surveillance by collecting timely performance data from the existing project performance reporting and activities (e.g. project quarterly reviews, monthly reviews, internal reviews, onsite visits, etc.). Successful surveillance depends on an open interface between the project team and IA organizations.
6.5.3 Requirements: To accomplish the project evaluation process, the Project Manager shall:
6.5.3.a Prepare project briefings and material demonstrating the project's readiness to continue, and present them at the IA organization site field review. The Project Manager should consult Table H-1 in Appendix H for other assessment criteria.
6.5.3.b Following the NAR approval, provide the IA organization access to project information databases, performance data, meetings, and NASA and contractor sites in accordance with the ToR. This includes access to project cost-performance evaluations, including EVM data for Category I and II projects.
| TOC | Preface | Change_Log | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | Chapter6 | Chapter7 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | AppendixF | AppendixG | AppendixH | AppendixI | AppendixJ | AppendixK | AppendixL | AppendixM | AppendixN | AppendixO | ALL | |
| | NODIS Library | Program Formulation(7000s) | Search | |