![[NASA Logo]](../Images/nasaball.gif) |
NASA Procedures and Guidelines |
||||
This Document is Obsolete and Is No Longer Used.
|
|||||
|
|
|||||
|
|
||||
| | TOC | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | Chapter6 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | AppendixF | AppendixG | ALL | | |||||
2.1.1 To support its diverse activities, NASA invests in a complex set of supporting IT and institution and infrastructure development and enhancement programs and projects. Programs and projects are different and the following definitions are used to distinguish between the two:
a. Program - a strategic investment by a Mission Directorate or Mission Support Office that has a defined architecture and/or technical approach, requirements, funding level, and a management structure that initiates and directs one or more projects. A program defines a strategic direction that the Agency has identified as needed to implement Agency goals and objectives.
b. Project - a specific investment having defined requirements, a life-cycle cost, a beginning, and an end. A project also has a management structure and may have interfaces to other projects, agencies, and international partners. A project yields new or revised products that directly address NASA's strategic needs.
c. Activity - an operation that sustains NASA as an organization. Unlike projects, which are temporary and unique, activities are ongoing and repetitive.
d. The term "Mission Support Office," as used in this document, refers to any Headquarters non-Mission Directorate office that initiates a program or project. Refer to the definition of "Mission Support Office" in Appendix A for additional information.
2.1.2 For CoF projects, the facilities program is as described in NPR 8820.2 and should be referenced for detailed requirements for CoF program/project management.
2.1.3 For ECR projects, the environmental program is as described in NPR 8590.1 and should be referenced for detailed requirements for ECR program/project management.
2.1.4 The Office of the Chief Financial Officer maintains the official database of the structure of NASA's work, which is named the Metadata Manager (MdM). This database documents the Agency's financial Work Breakdown Structure (WBS). At the highest level, a WBS element is flagged as an activity or a project. An activity is an ongoing operation to sustain NASA as an organization. IT and institutional infrastructure elements identified as projects comply with this NPR. The Office of Chief Engineer (OCE) approves the designation of an element as a project or an activity. Project managers are responsible for maintaining project attributes in MdM.
2.1.5 NASA strives to execute all programs and projects with excellence. Management requirements and oversight should track with the investment's magnitude and Agency priority. These factors are taken into account in IT and institutional infrastructure program and project requirements; the assignment of a program and project Governing Body; and identification of the Decision Authority for the program or project. A waiver process is established in section 6.2 to adapt the requirements to the scope and scale of a project. The program plan and the project plan are also used to define program and project requirements. A program plan template is found in Appendix E. A project plan template is found in Appendix F.
2.2.1 The NASA strategic management framework has a governance structure, which consists of three Agency-level management councils: the Strategic Management Council (SMC), the Program Management Council (PMC), and the Operations Management Council (OMC). The SMC is chaired by the Administrator and determines NASA's strategic direction and assesses Agency strategic progress. The PMC is chaired by the Associate Administrator and assesses program and project performance. Mission Directorate PMCs (DPMCs) support the Agency PMC. The OMC is chaired by the Deputy Administrator and reviews and approves institutional plans. In most cases, the OMC is the Governing Body for IT and institutional infrastructure programs and projects; however, in exceptional cases the PMC or the SMC may be assigned as the Governing Body. The OMC may also delegate governance to a Mission Support Office. If the Mission Support Office does not have an appropriate established oversight body, one will be formed. In other cases, another institutional committee, such as the Education Coordinating Committee, may be assigned as the Governing Body. If a Mission Directorate has an IT and institutional infrastructure program or project, the DPMC may be assigned as the Governing Body.
2.2.2 The Governing Body is the council, committee, board, or other organization with the responsibility of periodically evaluating the cost, schedule, risk, and performance of a program or project within its purview. The evaluation focuses on whether the program or project is meeting its commitments to the Agency. The Governing Body conducts a review prior to each KDP and then makes recommendations to the Decision Authority based on its findings.
2.2.3 A KDP is a point in time where the Decision Authority makes a decision on the readiness of a program or project to progress to the next phase of the life cycle. KDPs serve at each phase as gates through which programs and projects must pass. Within each phase, the KDP is preceded by one or more reviews, including a Governing Body review. Program KDPs are designated with roman numerals, e.g., KDP II, and project KDPs are designated with letters, e.g., KDP B.
2.2.4 The Decision Authority is the individual responsible for authorizing the transition at a KDP to the next life-cycle phase for a program or project. For programs and projects governed by the OMC, the Decision Authority is the NASA Deputy Administrator. This authority can be delegated to the Mission Support Office Official-in-Charge, usually an Assistant Administrator. The Decision Authority may also be the chairperson of the Governing Body.
2.3.1 The Office of the CIO has implemented a governance model that pertains to investments in IT that are not highly specialized, as highly specialized IT is defined in Appendix A. The governance model includes an IT Strategy and Investment Board
(IT SIB), an IT Program Management Board (IT PMB), and an IT Management Board (ITMB).
2.3.2 The purpose of the IT SIB is to provide a forum for senior-level stakeholder participation in the setting of IT strategy and policy of broad impact in terms of budget or operational capacity, as well as prioritization of significant IT investments that align with the strategy and mission of the Agency. The purpose of the IT PMB is to provide a forum for high-level Agency participation in the oversight and evaluation of Agency IT programs and projects. The purpose of the ITMB is to make decisions regarding performance, integration, and other issues pertaining to operational systems. The ITMB also serves as a senior-level Configuration Control Board (CCB) for Agency infrastructure projects, reviewing and approving high-level infrastructure requirements.
2.3.3 The IT PMB is the Governing Body for IT programs and projects that are in the scope of this document. The IT PMB has two levels: an Agency IT PMB level and a Center IT PMB level. Center IT PMBs are Governing Bodies performing the comparable functions of the Agency IT PMB, but at the Center level. Centers may assign Center IT PMB responsibilities to a new or existing body, e.g., the Center Management Council. Table 2-1 describes which IT PMB oversees a particular program or project.
| Criteria | Programs* | Projects with DME cost $1M or more (full cost basis) | Projects with DME cost less than $1M (full cost basis) | Projects with high visibility as determined by NASA CIO | Projects with high impact as determined by NASA CIO | Projects with high risk as determined by NASA CIO |
|---|---|---|---|---|---|---|
| Agency IT PMB | X | X | X | X | X | |
| Center IT PMB | X |
*For programs delegated to the IT PMB by the Agency OMC or PMC; DME: Development, Modification, or Enhancement.
Table 2-1: Scope of Agency IT PMB vs. Center IT PMB
2.3.4 The NASA CIO is the Decision Authority for programs and projects overseen by the Agency IT PMB. The Center CIO is the Decision Authority for programs and projects overseen by the Center IT PMBs.
2.3.5 The NASA CIO will have visibility into projects in the scope of this document and, regardless of the criteria in the table above, may designate oversight of a particular project to either the Agency IT PMB or a Center IT PMB.
2.3.6 For programs and projects governed under NPR 7120.5, or NPR 7120.8, with an identified IT component subject to IT Authority, the NASA CIO or the Center CIO, as appropriate, will include those elements in the IT management process to ensure overall alignment within Agency IT requirements and direction. The NASA CIO or designee will in turn represent and/or reflect those discussions, findings, and issues with the appropriate Governing Body under the auspices of NPR 7120.5, or NPR 7120.8, to ensure that oversight of the program or project is rationalized to provide assistance to program and project managers in resolving any issues. The agreement shall be documented in the program plan or project plan (or other appropriate document) encompassing the systems of concern. In the event that disagreements cannot be resolved at a lower level, the NASA Associate Administrator will make the final determination.
2.4.1 NASA's strategic management approach requires that all organizations within NASA manage requirements, schedule, and budget according to a program and project management structure. Programs provide the linkage between the Agency's goals and the projects that are the means for achieving them. Programs vary in scope, complexity, cost, and criticality; however, all programs have a life cycle that is divided into two phases:
a. Formulation - Pre-Program Acquisition, in which program requirements are defined, a required funding level is established, and a plan for implementation is designed, all consistent with the NASA Strategic Plan.
b. Implementation - Program Acquisition, Operations, and Sustainment, in which projects are initiated through competition or other processes and their formulation, approval, implementation, integration, operation, and ultimate decommissioning are constantly monitored.
2.4.2 The NASA Program Life Cycle is shown in Figure 2-1. Program formulation and implementation require the preparation and approval (at the appropriate level) of three key documents: a program formulation authorization document (FAD), a program commitment agreement (PCA), and a program plan. Each is described in subsequent paragraphs.
2.4.2.1 To initiate individual programs, a Mission Directorate or Mission Support Office prepares a program FAD. The program FAD authorizes a program manager to initiate the planning of a new program and to perform the analyses required to formulate a program plan that contains project elements, schedules, risk assessments, and budgets. A FAD template is found in Appendix C. Because the creation of a new program represents a major commitment of the Agency, the FAD requires the approval of the Mission Directorate Associate Administrator (MDAA) or Mission Support Office Official-in- Charge, usually an Assistant Administrator. The program FAD does the following:
a. Contains a statement of purpose for the proposed program and defines its relationship to the Agency's strategic goals and objectives.
b. Establishes the scope of work to be accomplished.
c. Provides initial constraints, including resources, schedule, and program participants within and external to NASA, as well as international partnerships.
d. Defines the approach and resources required to conduct program formulation.
Figure 2-1 Information Technology and Institutional Infrastructure Program Life Cycle
2.4.2.2 The PCA is the agreement between the MDAA or Mission Support Office official in charge and the Decision Authority who authorizes transition from formulation to implementation. If the MDAA is the Decision Authority, the NASA Associate Administrator signs the PCA. If the Mission Support Office Official-in-Charge is the Decision Authority, the NASA Deputy Administrator signs the PCA. The PCA documents the program's objectives, technical performance, schedule, cost, safety and risk factors, internal and external agreements, independent reviews, and top-level program requirements. A PCA can be considered an executive summary of the program plan and will be updated and approved during the program life cycle. A PCA template is found in Appendix D.
2.4.2.3 The program plan is an agreement between the MDAA or Mission Support Office Official-in-Charge and the program manager. It documents at a high level the program's objectives, scope, implementation approach, the environment within which the program operates, and the commitments of the program. The program plan is used by the program Governing Body in the review process to determine if the program is fulfilling its agreement. The program plan is updated and approved during the program life cycle, as appropriate.
2.4.2.4 The program plan describes how the program will be managed and contains the list of specific projects that are official program elements subject to the requirements in this document. The program plan also documents the program requirements on constituent projects. The requirements are documented in the program plan, in an appendix to the program plan, or in a referenced separately controlled requirements document.
2.5.1 For IT and institutional infrastructure projects, the project life-cycle phases of formulation and implementation are further divided into more incremental pieces that allow managers to assess progress.
2.5.1.1 Project formulation consists of two sequential phases, traditionally denoted as Phases A (Concept Development) and B (Preliminary Design). The primary activities in these phases are to define the project requirements and cost/schedule basis, and to design a plan for implementation (including contractor selection and long-lead procurement). While not formally a part of formulation, some formulation-type activities will naturally occur as part of advanced studies. These fall into a part of the project life cycle known as Pre-Phase A (Concept Studies).
2.5.1.2 Project implementation consists of Phases C, D, E, and F. Approval marks the transition from Phase B of formulation to Phase C of implementation. During Phases C (Final Design and Build) and D (System Assembly, Integration, and Test), the primary activities are developmental in nature, including contract execution. Phase C may include the building and testing of components or subsystems. All activities are executed as per the project plan developed during formulation. The start of Phase E (Deployment, Operations, and Sustainment) marks the transition from system development and acquisition activities to primarily system operations and sustainment activities. The project continues to execute the project plan, adjusted as needed to meet Agency strategic goals. In Phase F (Decommissioning), project systems or assets are taken out of service and safely disposed. Independent assessment activities occur throughout the phases.
2.5.2 To initiate a project, the MDAA or Mission Support Office Official-in-Charge, working through a program office usually provides a small amount of discretionary resources for concept studies (i.e., Pre-Phase A). These pre-formulation activities involve design reference project analyses, feasibility studies, and analyses of alternatives (AoA) that should be performed before a specific project concept emerges. These trade studies are not considered part of formal project planning since there is no certainty that a specific project proposal will emerge. In other cases, such as statute or unsolicited proposal, a project may be initiated in Phase A.
2.5.3 The MDAA or Mission Support Office Official-in-Charge has the authority to initiate a project and begin formulation activities. To effect a project's official entry into formulation, the program manager prepares a project FAD or equivalent. The project FAD is forwarded to the MDAA or Mission Support Office Official-in-Charge for final signature. Once the project FAD is signed, a project formally enters formulation.
2.5.4 Working with the program manager, the project manager and the project team develop the program requirements on the project. If requested by the program manager, the project manager assists in preparing a revised PCA. The project manager is then responsible for the evolution of the project concept and ultimate project success.
2.5.5 NASA places a good deal of emphasis on project formulation because adequate preparation of project concepts and plans is vital to success. During formulation, the project establishes the success criteria, including quantitative metrics, explores the full range of implementation options, defines an affordable project concept to meet project objectives specified in the program plan, develops needed technologies, and develops the project plan. Formulation is an iterative set of activities rather than discrete linear steps, and the phase may be performed many times in the life of a project as needs and conditions change. Formulation continues with interactive execution of its activities, normally concurrently, until formulation output products, like the project plan, have matured and are acceptable to the program manager.
2.5.5.1 The project plan is an agreement between the program manager, the MDAA or the Mission Support Office Official-in-Charge, and the project manager, and if it is performed at a Center, the Center Director. It defines, at a high level, the project's objectives, technical approach, cost, schedule, risks, implementation approach, the environment within which the project operates, and the commitments of the program and project. The project plan is used by the project Governing Body in the review process to determine if the project is fulfilling its agreements. The project plan must be consistent with the program plan. The project plan is updated and approved during the project life cycle to reflect changes in the stated commitments or project-level requirements.
2.5.5.2 The project plan is the key document that captures formulation results. Larger and more complex projects may find it necessary or desirable to write separate control plans to convey project approaches and strategies. In these cases, the project plan summarizes the key elements of such separate plans. In smaller projects, separate and detailed control plans may not be needed to document project approaches. The project plan itself serves as the single source for such information. A project plan template is found in Appendix F.
2.5.6 There are specialized project life cycles for each type of IT and institutional infrastructure project.
2.5.6.1 The CoF project life cycle consists of the formulation phases of project planning/development and design, and the implementation phases of Construction, Activation, Operations and Maintenance, and Decommissioning. The CoF project life cycle is shown in Figure 2-2 and is further described in NPR 8820.2. The figure shows the full CoF life cycle, but facility engineering terminates at activation when the facility is turned over to its user or owner.
Figure 2-2 CoF Project Life Cycle
2.5.6.2 The ECR project life cycle for restoration projects follows the Environmental Cost Element Structure developed by the Environmental Cost Engineering Committee of the Federal Remediation Technologies Roundtable, a multiagency group that develops and shares concepts and strategies for restoration technologies. The ECR restoration life cycle is shown in Figure 2-3.
Figure 2-3 ECR Project Life Cycle
2.5.6.3 The IT project life cycle is shown in Figure 2-4. The Pre-Phase A portion of the life cycle is optional; all other phases are required. The IT project life cycle shown in Figure 2-4 is illustrated like a "waterfall" methodology of system development. Individual projects may find that deliverables are better met by following a different methodology, such as iterative development or agile, that has incremental (as opposed to waterfall) characteristics. Projects may conduct their activities in accordance with nonwaterfall methodologies. However, before doing so, they must present to the Governing Body, early in the formulation phase, the proposed methodology and come to agreement with the Governing Body concerning how the proposed methodology would map to the project oversight requirements of this document. Chapter 4 defines the requirements for IT projects assuming a waterfall methodology. However, the activities described in Chapter 4 will be tailored in the project plan if an iterative development methodology is used. Project managers should refer to NPR 7123.1, NASA Systems Engineering Processes and Requirements, and NPR 7150.2, NASA Software Engineering Requirements, for helpful system and software engineering information.
Note: The EAPR is shown in Phase A, but, may be held at a later phase with the agreement of the EA team.
Figure 2-4 IT Project Life Cycle Reviews and Requirements
2.5.6.4 The OMSI project life cycle is shown in Figure 2-5. Because the scope and scale of OMSI projects vary, individual projects may be managed to a minimal subset of the life cycle, as appropriate to the project, agreed to between the program manager and project manager, and documented through the waiver process described in section 6.2 and the project plan. Chapter 5 defines the requirements for OMSI projects.
Figure 2-5 Other Mission Support Investment Project Life Cycle
2.6.1 Program reviews offer an opportunity to add value to program products and to share knowledge by inviting outside experts who can provide confirmation of the approach and/or recommend options. They offer an opportunity to organize, assess, and communicate critical data and information between providers, customers, and stakeholders. See Table 2-2 for program review descriptions.
2.6.2 Project reviews for CoF projects are to be required as described in NPR 8820.2.
2.6.3 Project reviews for ECR projects are to be required as described in NPR 8590.1.
| Review | Description |
|---|---|
| Program Concept and Definition Review (PCDR) | The PCDR examines the functional and performance requirements defined for the program and its constituent projects, and ensures that the program concept will satisfy the requirements. It examines the proposed program architecture and the flow down to all functional elements of the program. Technology planning with off-ramps (e.g., substitution of old technology) will be described. The preliminary description of management approach and initial budget and schedule will be presented. Risk assessment and management will be presented as well as the initial descope plan. |
| Program Implementation Review (PIR) | PIRs are conducted every two years to examine the program's continuing relevance to the Agency's strategic plan, the progress to date against the approved baseline, the implementation plans for current and upcoming work, budget, schedule, and all risks and their mitigation plans. |
Table 2-2 IT and Institutional Infrastructure Program Reviews
2.6.4 The IT project system life cycle identifies the project reviews associated with each phase in the IT project life cycle. In addition to the project life-cycle reviews, there are IT project unique reviews/assessments for enterprise architecture (EA), system certification and accreditation, and information records management and privacy impact. See Table 2-3 for IT system engineering project life cycle review descriptions. All the reviews described in Table 2-3 are required, with the exception of the system concept review. Refer to Appendix G for information on project-appropriate tailoring of the reviews. All Agency IT projects must adhere to the requirements of NPR 7150.2, and NPD 2820.1, NASA Software Policy.
2.6.5 NPR 2830.1, NASA Enterprise Architecture Procedures, defines a set of criteria that determine those investments that are candidates for an EA review, based on the significance of the investment to the Agency. The goal of an enterprise architecture project review (EAPR) is to ensure that projects have a fundamentally sound business foundation for successful funding and implementation. The goal of an enterprise architecture service review (EASR) is to ensure investments in sustained operations, modifications, upgrades, or enhancements have a fundamentally sound business foundation and are aligned with Agency requirements.
| Review | Description |
|---|---|
| System Concept Review (SCR) | The SCR evaluates the scope, cost benefit analysis, and a recommended solution/concept for the product or service to be delivered for the purpose of receiving approval, formalized via the Formulation Authorization Document, to proceed to the Formulation Phase. It assesses the effect on the "as-is" and "to-be" Enterprise Architecture, and ensures applicable security controls have been considered. The Pre-Phase A life-cycle phase is optional, but the SCR is conducted if the project includes Pre-Phase A. |
| System Requirements Review (SRR) | The SRR examines the functional, technical, performance, and security requirements for the system and elements of the preliminary Project Plan and ensures that the requirements and the selected concept will satisfy the system objectives. |
| Preliminary Design Review (PDR) | The PDR demonstrates that the preliminary design meets all system requirements with acceptable risk and within the cost and schedule constraints and establishes the basis for proceeding with detailed design. It will show that the correct design option has been selected, interfaces have been identified, and verification methods have been described. |
| Critical Design Review (CDR) | The CDR confirms that the maturity of the design is appropriate to support proceeding with implementation, that it was developed in conjunction with stakeholders, demonstrates that the design meets detailed requirements, and identifies open design issues for the purpose of obtaining a decision to proceed with development and deployment. It reviews the technical architecture to ascertain the effect on the enterprise architecture and reviews the application security design and the inclusion of security controls. |
| Test Readiness Review (TRR) | The TRR evaluates the project's readiness to proceed with testing, ensuring adequate schedule, resources, and management processes are in place. It ensures the completion of an integration test plan and the system's readiness for execution of integration testing. |
| Operational Readiness Review (ORR) | The ORR determines that the project is ready to go-live with the system or service: requirements have been met; the functionality, performance, and security controls have been thoroughly tested; procedures are in place for operations; the users have been adequately trained; and, the organization responsible for operations and sustaining engineering is ready to assume responsibility. It ensures a security plan is in place and that system authorization has been received. |
| Project Completion Review (PCR) | The PCR provides assurance that the implemented system is performing as expected and that all necessary support requirements are in place and functioning properly. It confirms that the system is operating properly in its production environment. It is the official closeout of the project and project team. The final project schedule is published and remaining open risks are transferred, closed, or accepted. At the conclusion of the PCR, the system is considered fully operational. |
| Decommissioning Review (DR) | The DR confirms the decision to terminate or decommission the system and assess the readiness for the safe decommissioning and disposal of system assets. |
Table 2-3 IT Project System Engineering Life-Cycle Reviews
2.6.5.1 As of the writing of this document, NPR 2830.1, requires an EAPR prior to any new investment for projects that meet any of the following criteria: over $500,000 in value; affects more than one Center; affects more than 100 people; or if it is a major investment requiring an OMB Exhibit 300. An EASR is required to consider sustained investment or modification/enhancement proposals for projects that meet any of the following criteria: over $1 million in value; affects more than one Mission Directorate; affects more than one Center; affects more than 100 customers; or is a major investment requiring an OMB Exhibit 300. If any of these EAPR or EASR criteria are met, the Chief Enterprise Architect or designee must be notified, and an EA review will be scheduled. Consult NPR 2830.1 for the most current and authoritative description of criteria for the EAPR and EASR.
2.6.5.2 NASA requires that all projects with IT content adhere to the EA reviews outlined in Table 2-4. Refer to NPR 2830.1, for additional requirements on EA reviews. The authority and responsibility for conducting an EA review is determined by the investment category and the life-cycle stage of the investment. In addition, the participation of enterprise architecture staff in the IT system engineering life-cycle reviews described in Table 2.3 is encouraged to further ensure alignment of the project with the enterprise architecture, but their participation is not required.
| Review | Description |
|---|---|
| EA Project Review (EAPR) | The EAPR ensures that project proposals have a solid business mapping to the program goals they support, create new capabilities for the Agency, and ensure that these proposals do not create capabilities that already exist. A review helps ensure that key sponsors, executives, and stakeholders have the appropriate information detail to make informed investment and funding prioritization decisions. |
| EA Service Review (EASR) | The goal of an EASR is to ensure investments in sustained operations, or which are undergoing modifications, upgrades, or enhancements, have a fundamentally sound business foundation, and are aligned with Agency requirements. This review allows key sponsors, executives, and stakeholders to assess the extent and effectiveness of that service against the program goals it supports. |
Table 2-4 Enterprise Architecture (EA) Reviews for all IT-Related Projects
2.6.6 IT security risks and controls need to be planned for and factored into all decisions during all phases of the IT project life cycle, from Pre-Phase A through decommissioning of the system in Phase F.
2.6.6.1 IT Security assessments are required at various phases in the system development life cycle as shown in Figure 2-4. For example, IT risk assessments and system security categorizations should be initiated during the formulation phase to ensure that security controls are properly designed, developed, implemented, and verified. Additional assessments such as system certification and accreditation are required during the implementation phase of the life cycle to ensure that the selected security controls are effective in the operational environment where the information system is deployed. IT security policy and Federal regulations also require the periodic testing and evaluation of the security controls in an information system, to be performed with a frequency depending on risk, but no less than annually.
2.6.6.2 NASA requires that all projects with IT content adhere to the IT security reviews and assessments outlined in Table 2-5. Additional IT Security activities and assessments are listed in Chapter 4 and Appendix G. They are consistent with the IT security requirements for NASA as described in NPR 2810.1, Security of Information Technology.
| Review/Assessment | Description |
|---|---|
| Information / System Security Categorization | Analysis of the information types to be stored and processed in the system to address three IT security objectives (Confidentiality, Integrity, and Availability). Determines the potential impact that a loss would have on the system or functional line of business supported by the information system and the level of IT security required to manage risk to an acceptable level. The result of the analysis is an "IT security category," validated by an appropriate NASA authority. |
| Security Certification | Comprehensive assessment of the management, operational and technical security controls and other safeguards of an IT system. Establishes the extent to which a particular design and implementation meets documented security requirements and any necessary remedial actions. |
| Security Accreditation | Formal declaration by an Authorizing Official that an IT system is compliant with established security requirements, that any residual risks identified during the risk mitigation process are acceptable, and that the system is approved to operate using a prescribed set of safeguards. |
| Annual Self-Assessment of Controls | Self-assessment of each system, performed at least annually, to ensure that security controls are still operating appropriately and that the level of risk to the IT system and the information contained therein remains acceptable. |
Table 2-5 IT Security Reviews and Assessments for All Projects with IT Systems
2.6.7 The ability to properly manage records is an important requirement for IT systems, both to comply with Federal law and to build a history of NASA's decisions for use by future projects. Privacy is also essential for all IT projects that store information about individuals. As such, all IT projects must incorporate the records management and privacy assessment activities, as described in Chapter 4 and Appendix G. The requirements for records management and privacy are detailed in NPR 1441.1, NASA Records Retention Schedules, and in NPR 1382.1, NASA Privacy Procedural Requirements.
2.6.8 Project reviews for OMSI projects depend on the scale and scope of the project. The review plan section of the project plan and the waiver process established in section 6.2 are used to document the reviews that will be conducted by the project. See Table 2-6 for OMSI project review descriptions.
2.6.9 Program and project reviews identified in the life cycles are convened by the Decision Authority (or designee) and the program or project manager. The agenda and ground rules for the review are jointly developed and a review board chairperson is appointed. The chairperson organizes the review board and submits the names of proposed members to the Decision Authority and program or project manager for joint approval. Proposed members must be independent of the program and project and some members must be independent of the Mission Directorate or Mission Support Office responsible for the program or project. Members of review boards are chosen based on their combined management, technical, safety and mission assurance, and/or educational expertise and/or qualifications (i.e., required certified, civil servant, etc.); their objectivity; and their ability to make a broad assessment of the implementation of the program or project that employs numerous technical and other disciplines.
| Review | Description |
|---|---|
| System/Project Concept Review (SCR) | The SCR establishes that the baseline project requirements are understood and the requirements for sub-projects (if any) have been determined. It also verifies that the envisioned system/project design will satisfy the requirements. |
| System/Project Requirements Review (SRR) | The SRR examines the functional and performance requirements for the system/project and the preliminary Project Plan and ensures that the requirements and selected concept will satisfy the project goals. |
| Preliminary Design Review (PDR) | The PDR demonstrates that the preliminary design meets all system/project requirements with acceptable risk and within cost and schedule constraints, and establishes the basis for proceeding with detailed design. It will show that a correct design option has been selected and verification methods have been described. Baseline costs and schedules, as well as all risk assessment, management systems, and metrics, will be presented. |
| Critical Design Review (CDR) | The CDR demonstrates that the maturity of the design is appropriate to support proceeding with full-scale fabrication, assembly, integration, and test, and that the technical effort is on track to complete the system development and operations in order to meet performance requirements within the identified cost and schedule constraints. Progress against management plans, budget, and schedule, as well as risk assessment will be presented. |
| Operational Readiness Review (ORR) | The ORR examines the actual system characteristics, test results, and the procedures used in the system or product's operation and ensures that all system and support hardware, software, personnel, procedures, and user documentation accurately reflects the deployed state of the system. |
| Decommissioning Review (DR) | The purpose of the DR is to confirm the decision to terminate or decommission the system and assess the readiness for the safe decommissioning and disposal of system assets. |
Table 2-6 OMSI Project Reviews
2.6.10 The MDAA, Mission Support Office Official-in-Charge or program manager may also require special reviews as the need is determined. Circumstances that may warrant these special reviews include variances with respect to technical, cost or schedule requirements, inability to develop an enabling technology, or some unanticipated change to the program or project baseline. The process followed for these reviews is the same as for other reviews. The review team will be dissolved following resolution of the issue(s) that triggered the review.
2.6.11 For all types of projects in the scope of this document, if the Decision Authority is considering the termination of a project at any time in Phases B, C, D, or E, then a special termination KDP may be requested. Circumstances such as the anticipated inability of the project to meet its commitments, an unanticipated change in Agency strategic planning, or an unanticipated change in the NASA budget may be instrumental in triggering a termination KDP. The Decision Authority commissions an Independent Assessment (IA), and following its completion, the project Governing Body holds a Termination Review.
2.7.1 IAs occur as part of the program and project KDP processes. The Decision Authority works with the program manager, project manager, and the cognizant individuals within the Mission Directorate or Mission Support Office, and the Office of Program Analysis and Evaluation, as necessary, in developing the IA agenda and ground rules and selecting the review chairperson. Review team members are independent of the program and project line of authority. Program and project IAs are separate from the program and project reviews and are generally conducted in conjunction with them.
2.7.2 The first program IA is the Program Approval Review (PAR) which occurs in conjunction with or following the PCDR. This assessment is conducted to ensure that major issues are understood and resolved prior to KDP I where program approval is given. The purpose and description of this review is listed in Table 2-7.
2.7.3 Other program IAs are conducted at least every two years following program approval. The IA looks at program performance and adherence or progress to meeting Agency goals.
| Review | Description |
|---|---|
| Program Approval Review (PAR) | The PAR examines the overall program concept, its relevance to the Agency strategic plan, the technical and management approaches, and the readiness of the program to provide oversight into the formulation of the initial project(s) of the program. Key criteria include: the feasibility and maturity of the Technical Concept/Program Architecture; clarity, completeness, and consistency of the program requirements, and the flow down of these requirements to initial and subsequent projects; the state of interface identification; identification of technology development needs; identification of risks and mitigation approaches; program test and verification policy; adequacy of resources to implement the initial project(s) in the program, including budget, reserves, and reserves policies; sufficiency of program management staffing and control mechanisms to manage initial and future constituent projects and satisfy external communication and reporting requirements throughout the expected lifetime of the program. |
Table 2-7 Information Technology and Institutional Infrastructure Program Approval Review
2.7.4 The first required project IA is the Non-Advocate Review (NAR) and occurs in conjunction with or following the PDR. In addition, for all new major projects with IT ("major IT projects"), OMB has directed an Independent Validation for Reasonableness (IVR) of cost, schedule, and performance objectives before beginning project development. This requirement also applies to ongoing major IT projects that have development, modernization, and enhancement efforts. NASA implements this requirement as part of the NAR. The criteria for what constitutes a major IT project changes from year to year depending upon the Agency's needs and guidance provided by OMB. Typical criteria include high-executive visibility or special management attention needed due to its importance to the NASA mission/function (regardless of cost), significant program or policy or privacy implications, a financial management support system that will obligate more than $500,000 annually, and others. The NASA Office of the CIO (OCIO), working in conjunction with its IT governance structure, designates a particular project as a major IT project during the capital planning process when the initial decision is made to approve the formation of a project. Following that determination, the OCIO informs the program/project manager that the project is a major IT project and that an IVR and additional reporting associated with a major IT project are required. Since the criteria for a major IT project may change from year to year, the OCIO may inform a program/project manager that a project which has been underway for some time is now considered to be a major IT project and that the IVR and additional reporting may be required, based on where the project is in its life cycle. Table 2-8 provides the purpose and description of the project NAR.
2.7.5 Other project IAs generally occur with or following project reviews. The IAs look at project cost, schedule and performance, and risk management processes. The required project IAs are documented in the review plan section of the project plan. For large-scale projects (>250M LCC), an IA is required for each KDP. Project IAs may also be required to support special reporting requirements from external sources such as OMB and NASA authorization and appropriations laws.
2.7.6 If the Decision Authority is considering the termination of a project in Phases B, C, D, or E, then an IA is conducted for the termination KDP.
2.7.7 Results of all IAs culminate at the Governing Body review where the program, project, Mission Directorate or Mission Support Office, and the IA team present their status, findings, and recommendations.
| Review | Description |
|---|---|
| Non-Advocate Review (NAR) | The NAR is an independent review of projects conducted at the end of Formulation (Phase B). It provides Agency management with an independent assessment of the project to proceed to Implementation (Phase C). The review provides the Governing Body with information that assists it in making recommendations to the Decision Authority. For major IT projects, this review also includes the IVR. Upon successful completion of this review process, a project baseline is established. Review criteria include assessment of the project's preliminary design, plans for implementation, and final implementation documentation. |
Table 2-8 Information Technology and Institutional Infrastructure Project Non-Advocate Review
| TOC | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | Chapter6 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | AppendixF | AppendixG | ALL | |
| | NODIS Library | Program Formulation(7000s) | Search | |