Procedural
Requirements
Effective Date: August 17, 2020
Expiration Date: August 17, 2030
|
|
NASA Procedural Requirements |
NPR 7120.7A Effective Date: August 17, 2020 Expiration Date: August 17, 2030 |
| | TOC | ChangeLog | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | AppendixA | AppendixB | AppendixC | AppendixD | AppenidxE | ALL | |
a. In alignment with the Service Line Plan, IT projects provide services and capabilities to meet the service line's objectives implementing development methodologies that are most appropriate for the service line's objectives, scope, environment, and risk tolerance.
b. The project may include IT TD in the form of a Proof of Concept (PoC) or Prototype. IT TD matures a particular technology or set of related technologies and is managed within the project life cycle (Pre-Formulation), to the point where it is ready to transition to the IT project Formulation Phase.
(1) A PoC is an analytical and experimental demonstration of hardware or software concepts that may or may not be incorporated into subsequent development or operational products, systems, or services. To be deliberate, the project manager shall clearly state what is to be proven and to what degree with the PoC. Characteristically, a PoC relates to parts of a complete system utilizing a test environment.
(2) A prototype is used to test the viability or usefulness of a product, service, system, or subsystem and demonstrates the technology in a way that the customer or beneficiary can visualize the experience of using the technology or system. It is intended to identify, demonstrate, and evaluate the key management, policy, technology, and cost implications of a desired product, system, or service. A prototype is intended for a fixed and limited duration to capture lessons or knowledge for possible implementation. It operates within a test environment and is not a full-featured system.
c. The project may include a pilot implemented during the Operations Phase. A pilot is a full-feature product, system, or service deployed into the production environment as an experimental trial to a limited user base, with all relevant IT system security controls in place, including an Authorization to Operate (ATO).
d. The project may use a traditional or Agile development methodology and associated project management methodology, based on service line and project specific considerations.
a. To ensure effective and efficient software development, Project Managers shall ensure software acquisition, development, maintenance, retirement, operations, and software created, acquired, or maintained is in accordance with NPR 7150.2, NASA Software Engineering Requirements.
b. 44 U.S.C. § 3541 (FITARA) and 40 U.S.C. 40 §11319 (Responsibility for Acquisitions of Information Technology. Resources, planning, and portfolio management) require the NASA CIO to certify that IT investments are adequately implementing incremental development as defined in capital planning guidance issued by OMB.
c. Projects that include software development/engineering, hardware development, or other product and services development, must use an incremental development and release process.
(1) Incremental or modular development is where an investment may be partitioned into discrete projects, increments, or useful segments, each of which is undertaken to develop and implement the products and capabilities that the larger investment will deliver.
(2) Dividing investments into smaller projects or releases helps to reduce investment risk, deliver capabilities more rapidly, and permit easier adoption of newer and emerging technologies, as referenced in Government Accountability Office (GAO)-18-148, Information Technology Reform, Agencies Need to Improve Certification of Incremental Development.
d. For all projects in which software, hardware, or other IT products and services are being developed, the Project Manager shall ensure that planned and actual delivery of new or modified technical functionality to users occurs at least every six months in accordance with OMB-15-14.
e. Certification of incremental development applies to any project that is developing software, hardware, or other IT products and services:
NOTE: Incremental development and the certification thereof is not applicable for investments and projects where software, hardware, or other IT product and service development is not occurring, such as an investment related to infrastructure or technology refreshment of equipment. Project Managers shall provide a justification when incremental development is not appropriate.
f. The KDP DA shall certify that incremental development has been addressed and documented in the project FAD.
g. Projects shall use Minimally Viable Products (MVP) and/or Minimally Marketable Products (MMP) in their incremental development efforts.
(1) An MVP is a production solution (i.e., the first release of a product or service) that meets the minimum capabilities needed for customers to recognize value and for a service line to learn from its use so that it can be improved in subsequent releases. The project must define the features and capabilities of a Minimum Viable Product (MVP) in a draft version by KDP-Formulation within the FAD and final/baselined version by KDP-Implementation within the Project Plan.
(2) The MMP defines the minimal set of features, capabilities, and service requirements that will meet the needs of the customer and that will have an acceptable cost break-even point for a service line. The cost break-even point is a point in time when the estimated unit cost to sustain the service and the estimated unit price that customers are willing to pay for the solution are equal (minus approved investment costs). If the project must produce a solution that is either a demand service or a combination of base and demand, the project must also define the Minimum Marketable Product (MMP) in a draft version by KDP-Formulation within the FAD and final/baselined version by KDP-Implementation within the Project Plan.
(3) The Project Manager shall identify the use of an MVP and/or MMP in the project plan, along with the incremental development methodology.
a. The term project baseline is defined as a set of requirements, cost, and schedule controlled through a KDP review and approval process and is documented in the Project Plan.
(1) The term scope baseline is defined as the approved version of a project's goals and objectives, scope statement, work breakdown structure (WBS) and its associated WBS dictionary, requirements, and MVP and/or MMP definition.
(2) The term schedule baseline is defined as the approved version of the project's schedule, including the schedule of project reviews and milestones.
(3) The term cost baseline is the approved version of the time-phased project budget, excluding any authorized project reserves.
b. The KDP DA shall determine if the initial project baseline at KDP-Implementation is approved.
c. The project's performance is measured against the approved baseline during the Implementation Phase.
5.3.1 Project Rebaseline
a. A rebaseline changes requirements/scope, schedule, budget, or a combination of all three factors.
b. Project teams shall rebaseline if any one or more of the criteria are met:
(1) There is a change in project goals or objectives resulting from internal or external management decisions, changes in funding level or availability of funds (e.g., extended continuing resolution), or contracting (including contractual protests).
(2) A change in the scope statement, work breakdown structure, a mandatory or critical requirement, the schedule of a time-critical requirement's release, the definition of the MVP and/or MMP, or a critical design decision.
(3) The current cost or schedule baseline is no longer useful as a management tool for realistic performance measurement as variances have exceeded the approved limits.
(4) A change in the schedule that would impact the schedule for a project review or milestone.
(5) Any change in requirements or design approach that would cause the project to exceed cost or schedule baselines beyond approved limits.
(6) A change to the project's approved compliance matrix.
(7) The project has been interrupted.
(8) The KDP DA requests a rebaseline.
c. The Project Manager shall present a rebaselining proposal to the KDP DA during a KDP review or as a rebaseline review separate from a KDP.
d. The Project Manager shall document the results of the KDP or rebaseline review in a Project KDP Decision Memorandum and update the Project Plan.
e. The Project Manager shall communicate the rebaseline to all impacted stakeholders.
f. If the recommendation is to terminate the project, then refer to the Termination Review section, 3.13.
5.3.2 Project Replan
a. Changes that do not alter the project's baseline may be executed as a replan under the authority and with the approval of the Service Line Deputy Director.
b. The Project Manager shall document the results of the replan in the Project Plan.
c. The Project Manager shall communicate the replan to all impacted stakeholders.
5.3.3 On Hold Status
a. Schedule delays greater than 60 days for any milestone require the Service Line Deputy Director or Project Manager to initiate a notification to the KDP DA. The project will go on hold unless the DA approves continuation. A project that is on hold greater than 60 days or that exceeds approved schedule variances will require a rebaseline.
b. The Project Manager shall notify all impacted stakeholders when a project goes into an on-hold status and when it is able to continue again.
a. All IT projects have an IT life cycle that is divided into phases: Pre-Formulation, Formulation, Implementation, Operations, and Decommission as depicted in Figure 5-1, IT Life Cycle Phases.
b. The IT life cycle phases are separated into incremental project life cycle phases as depicted in Figure 5-2, IT Project Life Cycle Phases.
Figure 5-2. IT Project Life Cycle Phases
c. The transition from one IT life cycle phase to another is approved by a KDP review. Additionally, projects with TD use KDPs during the Pre-Formulation Phase to transition from one TD phase to another depicted in Figure 5-3, IT Technology Development Pre-Formulation Life Cycle.
d. The transition from one project life cycle phase to another is approved by a specific SE review per the FAD and Project Plan depicted in Figure 5-4, IT Project Life Cycle.
e. Each Project Manager shall follow the IT project life cycle depicted in Figures 5-3 and 5-4, including preparation of, and obtaining approval of key documents:
(1) Project FAD.
(2) Project Plan.
(3) Project Communications Plan.
(3) ATO.
(4) Decommissioning Report (DR).
f. The IT project life cycle is tailorable to support all product, system, and service development methodologies.
(1) The phasing of project deliverables may vary based on the chosen product, system, or service development methodology (e.g., Waterfall, Iterative, Agile).
(2) The Project Manager shall present the proposed product, system, or service development methodology in the FAD to be approved by the KDP DA and in the Project Plan to be approved by the KDP DA during KDP-Implementation.
5.4.1 Pre-Formulation Phase
The IT Pre-Formulation Phase consists of the Concept Studies project life cycle phase.
5.4.1.1 Concept Studies
a. During the Concept Studies Phase, a project team considers a broad range of system/service-enabling concepts that align with the service line objectives and result in a project FAD. Historical information and interactions with customers and other potential stakeholders help to identify a preliminary concept, draft high-level user requirements, technical requirements, and needed technologies.
b. If TD is included in the project, then Concept Studies is further segmented into the TD Formulation Phase, TD Implementation Phase, and TD Transition Phase, as depicted in Figure 5-3, IT Technology Development Pre-Formulation Life Cycle.
5.4.1.1.1 TD Formulation
a. KDP-TD Formulation (TDF) is a point in time when the KDP DA makes a decision on the readiness of the project to progress to the TD Formulation Phase.
b. The Project Manager shall meet the following KDP-TDF success criteria by filing the following documentation in the records repository accessible by the Agency OCIO:
(1) Final TD FAD.
(2) Final Compliance Matrix.
(3) Final KDP-TDF presentation charts.
(4) Preliminary TD Project Plan.
c. The KDP DA shall make a decision on the readiness to transition to the TD Formulation Phase and approval of the TD FAD.
d. KDP-TD Implementation (TDI) is a point in time when the KDP DA makes a decision on the readiness of the project to progress to the TD Implementation Phase.
e. The Project Manager shall meet the following KDP-TDI success criteria by filing the following documentation in the records repository accessible by the Agency OCIO:
(1) Final TD Project Plan.
(2) Final KDP-TDI presentation charts.
(3) Updated Compliance Matrix.
f. The KDP DA shall make a decision on the readiness to transition to the TD Implementation Phase and approval of the TD Project Plan.
5.4.1.1.2 TD Implementation
a. During the TD Implementation Phase the Project Manager executes the Project Plan and should provide information briefings to the TD stakeholders at the periodic Status Reviews (SRs). The SR briefings include status on the schedule, cost, issues, risks, and dependencies. The SR provides recommendations to the project for forward work and helps the project to escalate any risks or issues.
b. The Project Manager shall file the final SR presentation charts in the records repository accessible by the Agency OCIO.
c. KDP-TD Transition (TDT) is a point in time when the KDP DA makes a decision on the readiness of the project to progress to the TD Transition Phase where the project will either closeout or continue.
d. The Project Manager shall meet the following KDP-TDT success criteria by filing the following documentation in the records repository accessible by the Agency OCIO:
(1) Final TD Project Plan.
(2) Final KDP-TDT presentation charts.
(3) Final TD Business Case if recommending the project continue.
(4) Update Compliance Matrix.
e. The KDP DA shall make a decision on the readiness to proceed to the TD Transition Phase and whether the project will continue or closeout.
5.4.1.1.3 TD Transition
a. During the TD Transition Phase:
(1) If approved to continue, then the Project Manager shall develop a project FAD and Compliance Matrix, for review at KDP-Formulation.
(2) If not approved to continue, then the Project Manager shall:
(a) Submit a final Closeout Report (CR).
(b) Shut down any PoC or prototypes.
5.4.1.2 KDP-Formulation
a. Pre-Formulation culminates in KDP-Formulation when the KDP DA authorizes a Project Manager to perform the analysis required to formulate a sound Project Plan that captures Pre-Formulation results.
b. The Project Manager documents compliance with this NPR by appending a completed Compliance Matrix (see Appendix C.7 and C.9) to the IT project FAD for KDP DA approval. At KDP-Formulation, the Compliance Matrix must address requirements through KDP-Implementation.
c. To affect a project's entry into the Formulation Phase, the Project Manager shall meet the following KDP-Formulation success criteria by filing the following documentation in the records repository accessible by the Agency OCIO:
(1) Final Project FAD.
(2) Final Compliance Matrix.
(3) Final KDP-Formulation presentation.
d. The KDP DA shall make a decision on the readiness to begin the Formulation Phase.
5.4.2 Formulation
a. Formulation Phase consists of two project life cycle phases: Concept & Requirements and Preliminary Design.
b. In Formulation, the Project Manager executes the FAD, developing the Project Plan, budgets, schedules, preliminary design, and management controls to ensure project performance and alignment with the service line's strategic objectives.
5.4.2.1 Concept & Requirements
a. During the Concept & Requirements Phase, the project team, with assistance from stakeholders, develops a preliminary Analysis of Alternatives (AoA), Concept of Operations (ConOps), and the project's preliminary top-level user and technical requirements. These activities take place in preparation for the System Requirements Review (SRR).
b. The SRR is conducted to examine the functional, technical, performance, and IT security requirements for the product, system, or service, ensuring the requirements with the selected concept will satisfy the project objectives.
c. The Project Manager shall meet the following SRR success criteria by filing the following documentation in the records repository accessible by the Agency OCIO:
(1) Final Requirements Specification (RS).
(2) The preliminary Requirements Traceability Matrix (RTM).
(3) Final SRR presentation charts.
(4) Final Enterprise Architecture Project Assessment (EAPA).
(5) Preliminary Project Plan.
(6) Preliminary Project Communications Plan.
(7) Preliminary IT System Security Plan.
(8) Preliminary Software Development Plan/Software Management Plan.
(9) Preliminary ConOps.
(10) Preliminary AoA.
d. The SE DA shall make a decision on the readiness to begin the Preliminary Design Phase.
5.4.2.2 Preliminary Design
a. During the Preliminary Design Phase, the project team is focused on being able to baseline the requirements, cost, and schedule, and to establish a preliminary design, implementation approach, and test plan. These efforts take place in preparation for the Preliminary Design Review (PDR).
b. The IA evaluates the proposed baseline presented in the Project Plan.
c. The IA Chair shall evaluate the following:
(1) The project's alignment and relevancy to the service line goals/objectives and the adequacy of requirements flow-down from these.
(2) Adequacy of technical approach.
(3) Adequacy of the integrated cost and schedule estimates and funding strategy (i.e., budget adequacy and schedule adequacy).
(4) Adequacy and availability of resources other than budget.
(5) Adequacy of risk management approach and risk identification/mitigation per OCIO Risk Management Plan.
(6) Adequacy and fit of selected project and product, system, or service development methodology.
(7) Other criteria identified by the DA.
d. During the Preliminary Design Phase, the project manager, with the support of the project team, shall support the IA team review analysis.
e. The PDR demonstrates that the preliminary design meets all product, system, and service requirements with acceptable risk and within the cost and schedule constraints and establishes the basis for proceeding with detailed design. The interfaces have been identified, test plans are in development, and plans to update standard operating plans/procedures have been described.
f. The Project Manager shall meet the following PDR success criteria by filing the following documentation in the records repository accessible by the Agency OCIO:
(1) Final AoA.
(2) Preliminary Design Specification (DS).
(3) Updated RTM.
(4) Preliminary Interface Control Document (ICD)(s).
(5) Updated Software Development/Management Plan.
(6) Updated Project Plan.
(7) Updated Project Communications Plan.
(8) Updated IT System Security Plan.
(9) Updated ConOps.
(10) Preliminary Operations Concept (OpsCon).
(11) Preliminary Test Plan.
(12) Preliminary Security Control Assessment.
(13) Final PDR presentation charts.
g. The SE DA shall make a decision on the readiness to proceed to KDP-Implementation.
5.4.2.3 KDP-Implementation
a. Formulation culminates in KDP-Implementation when the KDP DA makes a decision on the readiness of a project to progress to the Implementation Phase.
(1) The Project Manager presents a summary of the completion of the Formulation Phase including the Concept & Requirements and Preliminary Design deliverables.
(2) The results of the IA provide an analysis of the project's readiness to advance to the Implementation Phase.
(3) The approved scope/requirements, schedule, and budget become the baseline.
(4) The Project Manager shall attach an updated Compliance Matrix that addresses all project requirements for all project phases to the Project Plan at KDP-Implementation. Once the KDP-DA approves the fully completed Compliance Matrix it becomes part of the scope baseline and any changes must subsequently be approved by the KDP-DA.
b. The Project Manager shall meet the following KDP-Implementation success criteria by filing the following documentation in the records repository accessible by the Agency OCIO:
(1) Final KDP-Implementation presentation charts.
(2) Updated Project Plan.
(3) Updated Project Communications Plan.
c. The IA Chair shall present the IA findings and recommendations at KDP-Implementation.
d. The KDP DA shall make a decision on the readiness to begin the Implementation Phase.
5.4.3 Implementation
a. Implementation Phase consists of three IT project life cycle phases: Final Design & Build; System Assembly & Integration; and Test & Pre-Deployment Phases.
b. Implementation Phase includes the continued development and execution of approved plans and the evaluation of the project performance using management controls.
5.4.3.1 Final Design & Build
a. During the Final Design & Build Phase, the project team completes the final design providing traceability to the detailed requirements, begins early production of system components requiring long lead time, and completes acquisitions. These efforts take place in preparation for the Critical Design Review (CDR).
b. The CDR confirms that the maturity of the design is acceptable to proceed with assembly and integration. The CDR determines that the technical effort is on track to complete the product, system, and service development, meets performance requirements, validates system architecture, and reviews the IT system security design including IT system security controls.
c. The Project Manager shall meet the following CDR success criteria by filing the following documentation in the records repository accessible by the Agency OCIO:
(1) Final DS.
(2) Updated RTM.
(3) Updated Project Plan.
(4) Updated Project Communications Plan.
(5) Updated ICD(s).
(6) Updated Test Plan.
(7) Preliminary Test Cases and Procedures.
(8) Preliminary O&M sustainment commitments.
(9) Preliminary O&M Handbook.
(10) Final Software Development/Management Plan.
(11) Preliminary Project Training Plan and materials.
(12) Updated IT System Security Plan.
(13) Final ConOps.
(14) Updated OpsCon.
(15) Final Security Control Assessment.
(16) Final CDR presentation charts.
d. The Project Manager shall validate that acquisitions are executed.
e. The SE DA shall make a decision on the readiness to begin the System Assembly & Integration Phase.
5.4.3.2 System Assembly & Integration
a. During System Assembly & Integration, the project acquires, builds, configures, and integrates the product, system, and/or service.
(1) The various hardware and software components and sub-systems are integrated to verify the design.
(2) These efforts take place in preparation for the Test Readiness Review (TRR).
b. The TRR evaluates the project's readiness to proceed with formal testing per the test plan confirming that adequate schedule, resources, and management processes are in place.
(1) The test plan demonstrates the traceability of test cases/scenarios to requirements and design (verification) and describes user acceptance testing (validation).
(2) If testing is going to be conducted in the production environment, then the following conditions must be met:
(a) An IT System Security Plan is in place and the system ATO has been signed by the AO.
(b) Project receives pre-approval from the KDP-DA if test will be in a production environment prior to KDP-Operations.
c. The Project Manager shall meet the following TRR success criteria by filing the following documentation in the records repository accessible by the Agency OCIO:
(1) Final Test Plan.
(2) Final RTM.
(3) Final Project Training Plan and materials.
(4) Updated O&M Handbook.
(5) Updated Project Plan.
(6) Updated Project Communications Plan.
(7) Final Security Assessment Report (SAR).
(8) Preliminary Authorization Package.
(9) Updated OpsCon.
(10) Final ATO if testing in the production environment.
(11) Final TRR presentation chart.
d. The Project Manager shall validate that subsystem and system integration and testing are complete and that the test results are satisfactory for proceeding into formal verification and validation.
e. The SE DA shall make a decision on the readiness to begin the Test & Pre-Deployment Phase.
5.4.3.3 Test & Pre-Deployment
a. During Test & Pre-Deployment, the product, system, and/or service undergoes rigorous verification and validation as written in the test plan to ensure the implemented products, systems, services, and supporting processes meet requirements, design intentions, and user expectations. The testing efforts take place in preparation for Operational Readiness Review (ORR).
b. The ORR evaluates the project's preparedness to deploy the product, system, and/or service. The ORR demonstrates that: the requirements have been met; the functionality, performance, and IT system security controls have been thoroughly tested; procedures are in place for O&M activity; and the organization responsible for operations/sustaining engineering is ready to assume responsibility.
c. The Project Manager shall meet the following ORR success criteria by filing the following documentation in the records repository accessible by the Agency OCIO:
(1) Updated Project Plan.
(2) Updated Project Communications Plan.
(3) Final O&M sustainment commitments.
(4) Final Deployment Plan.
(5) Final OpsCon.
(6) Final O&M Handbook.
(7) Final ATO has been submitted for signature or is signed.
(8) Final IT System Security Plan.
(9) Plan of Action and Milestones (POA&M)
(10) Final ORR presentation charts.
d. The SE DA shall make a decision on the readiness to proceed to KDP-Operations.
5.4.3.4 KDP-Operations
a. Implementation culminates in KDP-Operations when the KDP DA makes a decision on the readiness of a project to begin the Operations Phase.
(1) A product, system, or service where the plan includes executing pilots will only be deployed with KDP-Operations approval. (2) The Project Manager presents a summary on the completion of the Implementation Phase including final design and architecture, system testing, operational support readiness, system authorization, training, and O&M funding sources.
b. The Project Manager shall meet the following KDP-Operations success criteria by filing the following documentation in the records repository accessible by the Agency OCIO:
(1) Final KDP-Operations presentation charts.
(2) Final ATO.
(3) Updated Project Communications Plan.
c. The KDP DA shall make a decision on the readiness to begin the Operations Phase.
5.4.4 Operations
a. IT Operations Phase consists of two IT project life cycle phases: Deployment and Operations & Maintenance.
b. IT Operations Phase includes sustainment and evaluation of the product, system, or service.
5.4.4.1 Deployment
a. During the Deployment Phase, the product, system, or service is deployed into the operational environment.
(1) The Deployment Phase recognizes the transition of responsibility from the project team to an operations/sustaining engineering team, including lessons learned and transition support to the Service Desk.
(2) The Deployment Phase includes a deployment start date (or go-live date) and a deployment complete date, which is the date that all required deployment waves are complete and stakeholder adoption goals for the project are met.
(3) At the conclusion of the Deployment, the product, system, or service is considered fully operational.
b. The plan to deploy may include one or more pilots.
(1) If the KDP DA determines the pilots' deployments are successful, then the product, system, or service may be deployed to full production for all intended users as authorized at KDP-Operations.
(2) If not able to successfully implement the approved pilots' deployments, then the Project Manager shall present a revised deployment plan to the KDP DA for approval.
c. The Project Manager shall:
(1) Coordinate the deployment schedule with the agency and impacted centers' mission freeze calendars.
(2) Monitor deployment progress against the deployment schedule.
(3) Monitor the deployment progress against the project's stakeholder adoption goals.
(4) For incremental development and release projects, solicit customer and/or user feedback to inform the features and design of subsequent increments.
(5) Propose changes to the deployment plan to the KDP DA for approval.
(6) Validate that the deployment efforts are complete and that the stakeholder adoption goals have been met at the Deployment Complete milestone. This serves as the transition to the Operations & Maintenance Phase.
5.4.4.2 Operations & Maintenance
a. During the Operations & Maintenance Phase, the responsibility for the ongoing sustainment of the new or revised product, system, or service is transitioned from the Project Manager to an activity lead and managed as an activity.
b. If a project includes decommissioning an operational product, system, or service, a Project Manager presents the recommendation to begin decommissioning at a Decommissioning Readiness Review (DRR). The DRR confirms the decision and assesses the readiness of the system components for the safe decommissioning and disposal of system assets.
c. The Project Manager shall meet the following DRR success criteria by filing the following documentation in the records repository accessible by the Agency OCIO:
(1) Updated ICD.
(2) Final Decommissioning Plan.
(3) Updated Project Communications Plan.
(4) Final DRR presentation charts.
d. The SE DA shall make a decision on the readiness to proceed to KDP-Decommission.
5.4.4.3 KDP-Decommission
a. If a project includes decommissioning an operational product, system, or service, a Project Manager presents the recommendation to begin decommissioning at a KDP-Decommission when the KDP DA makes a decision on the readiness of a project to begin the Decommission Phase.
(1) The Project Manager presents a summary of the Decommissioning Plan including requirements, security concerns, schedule, cost, and stakeholder coordination.
b. The Project Manager shall meet the following KDP-Decommission success criteria by filing the following documentation in the records repository accessible by the Agency OCIO:
(1) Final KDP-Decommission presentation charts.
(2) Final Project Communications Plan.
c. The KDP DA shall make a decision on the readiness to begin the Decommission Phase.
5.4.5 Decommission
The Decommission Phase consists of the Decommissioning and Project Completion project life cycle phases.
5.4.5.1 Decommissioning
a. During the Decommissioning Phase, legacy products, systems, and/or services are safely decommissioned and the disposal of product, system, and/or service assets is completed per the Decommissioning Plan.
b. The Project Manager shall:
(1) Execute the Decommission Plan.
(2) Update the ICD(s).
(3) Prepare and submit the DR to the SE DA, validating the successful completion of the Decommissioning Plan.
c. The SE DA concurrence on the DR serves as the transition to the Project Completion Phase.
5.4.5.2 Project Completion
a. During Project Completion, the project team validates that all efforts to meet the project goals and objectives are complete, all records are placed in a records repository accessible by the Agency OCIO and a Project Completion Review (PCR) is held to assess the project's completion.
b. The Project Manager shall meet the following PCR success criteria by filing the following documentation in the records repository accessible by the Agency OCIO:
(1) Final PCR presentation charts.
(2) Final Enterprise Architecture Service Assessment (EASA).
(3) Final DR.
c. The SE DA shall make a decision on the completion of the project.
| TOC | ChangeLog | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | AppendixA | AppendixB | AppendixC | AppendixD | AppenidxE | ALL | |
| | NODIS Library | Program Formulation(7000s) | Search | |
This document does not bind the public, except as authorized by law or as incorporated into a contract. This document is uncontrolled when printed. Check the NASA Online Directives Information System (NODIS) Library to verify that this is the correct version before use: https://nodis3.gsfc.nasa.gov.