DOE G 415.1-2, Information Technology Project Execution Model Guide for Small and Medium Projects

DOE G 415.1-2 12-21-2015 INFORMATION TECHNOLOGY PROJECT EXECUTION MODEL GUIDE FOR SMALL AND MEDIUM PROJECTS [This Guide describes acceptable, but not mandatory means for complying with requirements. Guides are not requirements documents and are not to be construed as requirements in any audit or appraisal for compliance with associated rule or directives.] U.S. Department of Energy Office of the Chief Information Officer NOT MEASUREMENT SENSITIVE DOE G 415.1-2 i 12-21-2015 Table of Contents FOREWORD................................................................................................................................ iii 1 Introduction ........................................................................................................................... 1 2 Background ........................................................................................................................... 1 3 Scope....................................................................................................................................... 1 4 Framework ............................................................................................................................ 2 4.1 Critical Decision (CD) Review Process ........................................................................... 2 4.1.1 Deliverables & CD Packages .................................................................................... 3 4.1.2 CD Review Process................................................................................................... 3 4.2 Core Elements .................................................................................................................. 4 4.2.1 Lifecycle Phases & Stages ........................................................................................ 5 4.3 SMP Essential Artifacts ................................................................................................. 22 4.4 Key Project Stakeholders ............................................................................................... 24 5 Monitoring & Controlling .................................................................................................. 27 5.1.1 Risk Management ................................................................................................... 28 5.1.2 Change Control Management ................................................................................. 28 5.1.3 Work Breakdown Structure & Schedule Management ........................................... 29 5.1.4 Project Reviews ...................................................................................................... 32 5.1.5 Project Cost Tracking ............................................................................................. 33 6 Modular & Agile Approach ............................................................................................... 34 6.1 SMP Modular Workflow ................................................................................................ 34 6.2 SMP Agile Workflow..................................................................................................... 35 7 Tailoring Opportunities ..................................................................................................... 37 APPENDIX A: ACRONYMS ........................................................................................................ 1

APPENDIX B: OCIO Resources and Departmental Requirements ............................................... 1 APPENDIX C: GLOSSARY .......................................................................................................... 1 APPENDIX D: DESCRIPTION of PROJECT ARTIFACTS ........................................................ 1 APPENDIX E: REFERENCES ...................................................................................................... 1 Figure 1 - Critical Decision Gates .................................................................................................. 2 Figure 2: Composition of a CD Packages ....................................................................................... 3 Figure 3: SMP Critical Decision Review Process .......................................................................... 4 Figure 4: SMP Core Elements ........................................................................................................ 5 ii DOE G 415.1-2 12-21-2015 Figure 5: Execution Phase ............................................................................................................ 14 Figure 6: SMP Essential Artifacts................................................................................................. 23 Figure 7: SMP Risk Management ................................................................................................. 28 Figure 8: SMP Change Control Management Plan....................................................................... 29 Figure 9: SMP Schedule Progression ........................................................................................... 30 Figure 10: SMP Modular Approach ............................................................................................. 35 Figure 11: SMP Agile Workflow .................................................................................................. 37 Table 1: Pre-Project Phase - Key Activities ................................................................................... 7 Table 2: Pre-Project Phase Summary ............................................................................................. 8 Table 3: Initiation Phase - Key Activities ....................................................................................... 9 Table 4: Initiation Phase Summary ............................................................................................... 10 Table 5: Planning Phase - Key Activities ..................................................................................... 12 Table 6: Planning Phase Summary ............................................................................................... 13 Table 7: Design Stage - Key Activities ......................................................................................... 15 Table 8: Development Stage- Key activities ................................................................................ 16 Table 9: Testing Stage - Key Activities ........................................................................................ 17 Table 10: Execution Phase (Design Stage) Summary .................................................................. 18 Table 11: Execution Phase (Development & Testing Sages) Summary ....................................... 18 Table 12: Implementation Stage - Key Activities ......................................................................... 19

Table 13: Closure Stage - Key Activities ..................................................................................... 20 Table 14: Maintenance Stage - Key Activities ............................................................................. 21 Table 15: Production Phase - Inputs-Process-Outputs.................................................................. 22 Table 16: SMP Key Project Stakeholders ..................................................................................... 24 Table 17: SMP High-Level Schedule ........................................................................................... 31 Table 18: SMP Milestone Schedule .............................................................................................. 31 Table 19: SMP Detailed Project Schedule .................................................................................... 32 Table 20: Important Agile Terminology ....................................................................................... 35 Table 21: Project Tailoring Considerations .................................................................................. 38 Table 22: Examples of Tailoring Questions ................................................................................. 39 Table 23: Government-wide and DOE Requirements Integrated into the IT PEM ....................... 1 DOE G 415.1-2 iii (and iv) 12-21-2015 FOREWORD This Department of Energy (DOE) Guide is approved for use by all Department of Energy (DOE), including National Nuclear Security Administration (NNSA), organizations. This Guide was developed to provide project management principles and guidelines to small and medium projects that fall outside the scope of DOE Order (O) 415.1, Information Technology Project Management, dated 12-03-2012. DOE O 415.1 states that IT projects that do not meet the scope of the Order are required to be managed using a standardized approach as specified and approved by the sponsoring or funding Organization. This guide puts forth suggestions for a project management framework that applies DOE approved concepts and methods from the Information Technology (IT) Project Execution Model (PEM) Guide, dated July 17, 2014. DOE Guides are part of the DOE Directives System and are issued to provide supplemental information regarding the Department’s expectation of its requirements as contained in rules, Orders, Notices, and regulatory standards. This Guide puts forth suggestions for project management and does not establish or invoke any new requirements. Beneficial comments (recommendations, additions, deletions, and any pertinent data) that may improve this document should be sent to: Denise Hill IM-20 U.S. Department of Energy Washington, D.C. 20585 Phone (202) 586-5848 DOE G 415.1-2 1 12-21-2015 1 Introduction The purpose of this guide is to deliver an approved, standardized project management approach for use by small and medium sized IT projects. This guide provides a customized adaptation of the Information Technology (IT) Project Execution Model (PEM) Guide, dated July 17, 2014 1 . The concepts and methods employed in this guide were chosen for their importance, practicality, and benefit to the management of small and medium projects. This guide and its framework will be officially titled the Information Technology Project Execution Model for Small and Medium Projects and referred in this guide as the “SMP.” 2 Background

The scope, effort, and budget required on small and medium-size IT projects are typically less than their larger counterparts. Deliverables (activities and artifacts) appropriate for larger projects may be impractical or not beneficial for small and medium sized projects. Moreover, smaller projects typically pose a lower risk and cost to an organization, making them simpler to justify and approve into an organization’s project portfolio. Their ease of entry into an organization’s project portfolio increases the number of SMP type projects and the need for approved project management guidance specifically designed to support small and medium IT projects. 3 Scope The SMP is approved for use by all Department of Energy (DOE), including National Nuclear Security Administration (NNSA), organizations who seek approved and standardized guidelines for managing small and medium IT projects 2 . DOE O 415.1 states that IT projects that do not meet its scope should still utilize a standardized project management approach as specified and approved by the sponsoring or funding Organization. Departmental Elements should provide to its contractors (including IT Program/Project Management and service contracts) clear requirements and expectations for sound Project Management, in alignment with the DOE O 415.1 Customer Requirements Document (CRD). The contractor project management approach should be specified and approved by the sponsoring or funding Organization. The SMP puts forth suggestions for project management for projects that fall outside the scope of DOE O 415.1 or that meet the following criteria: • Projects with a Total Project Cost (TPC) of less than $25 Million (M); • Projects with a short duration or lower complexity; • Nominal Impact on DOE elements; • Internal to a specific program or organization; or • As determined by head of organizational unit. 1 Information Technology Project Execution Model, dated July 17, 2014 was developed to provide project management guidance in support of DOE O 415.1. 2 Note that IT projects that involve acquisitions must meet the requirements of 40 U.S.C. 11319(b)(1)(c) (“Federal Information Technology Acquisition Reform”) 2 DOE G 415.1-2 12-21-2015 Furthermore, modular and agile projects that fall within the criteria can also benefit from the structure and agility of the SMP framework. Section 6 of this guide provides additional information on modular and agile approaches. 4 Framework As previously mentioned, the SMP is a customized version of the IT PEM. As such, the SMP aims to maintain the structural components of the IT PEM framework. This includes factoring into its methodology Government-wide and/or Department requirements for information management to include Capital Planning Investment Control (CPIC), Configuration Management (CM), Cybersecurity, Enterprise Architecture (EA), Quality Assurance (QA), Records Management (RM), Safety and Safeguards (S&S), Section 508, and System Engineering. Applying the same structural components allows the SMP to maintain continuous alignment, consistency, and synchronization with larger projects. 4.1 Critical Decision (CD) Review Process The SMP utilizes the same Critical Decision (CD) Reviews as the IT PEM. CD Reviews are formal stage gates or transition points during a project’s lifecycle where designated approvers (i.e. CD Approvers) review required deliverables (activities and artifacts) and other internal and

external factors to determine if the project is prepared to advance to its proceeding phase or stage. CD Approvers should be determined early in the project lifecycle or prior to the first CD Review (CD-0). Each project and their specific governance should determine their specific CD Approvers. The Approvers may be the same individuals across all CD Reviews or may be different. The chosen individuals should have a stake in the successful implementation of the project and sufficient authority to accept or reject moving the project to its successive phase or stage. A unanimous decision is required from all CD Approvers in order to advance the project to its successive phase or stage. The PM is responsible for resolving any discrepancies preventing unanimous CD Reviewer approval to include items with conditional approval. Figure 1 illustrates the five CD Reviews (CD-0 to CD-4) along the SMP project lifecycle. Figure 1 - Critical Decision Gates DOE G 415.1-2 3 12-21-2015 4.1.1 Deliverables & CD Packages Project Deliverables include tangible and intangible activities and artifacts required to support the delivery of project objectives. A CD Package is a group of deliverables whose completion is required to satisfy a particular CD Review. Although the SMP provides guidance on the activities and artifacts that should be considered across the project lifecycle, it is the responsibility of each project team and their respective governance to determine the appropriate deliverables required for each CD Package. Figure 2 provides an illustration of the composition of a CD Package. Figure 2: Composition of a CD Packages 4.1.2 CD Review Process Once a CD Package for a particular CD Review has been completed, the PM performs a quality review to ensure all deliverables within that package were appropriately completed, reviewed, and signed-off (by appropriate document owner). The CD Review generally requires that all incomplete deliverables be completed prior to the review. If it is critical to proceed prior to full completion, however, action items must be identified and a risk must be assigned to address its completion during the next phase or stage. A unanimous approval from all CD Approvers is required to advance the project to its successor Phase or Stage. The CD Review process should be repeated in preparation for each CD Review to ensure preparedness and to validate the completion of quality deliverables. Figure 3 illustrates the CD Review Process as described in this section. The CD Review Process should be repeated in preparation for each CD Review. DOE G 415.1-1 4 12-21-2015 Figure 3: SMP Critical Decision Review Process 4.2 Core Elements The SMP adopts the same core elements utilized in the IT PEM Methodology. These core elements are size agnostic as their subcomponents can be customized to meet the specific needs of each project. Figure 4 provides a high-level illustration of the SMP core elements across the SMP lifecycle. A waterfall illustration is provided to best depict the elements included at each phase. Section 6 in this guide provides an agile development approach which projects can apply at that stage. The core elements as applied by both the SMP and the IT PEM frameworks include: 1. Lifecycle Phases & Stages 2. Critical Decision Reviews (CD) 3. Deliverables & CD Packages 4. Key Project Stakeholders DOE G 415.1-2 5 12-21-2015 Figure 4: SMP Core Elements 4.2.1 Lifecycle Phases & Stages

The SMP Lifecycle Phases and Stages are distinct periods in a project’s lifespan with the goal of providing a quality structure, deliverable compliance, transparency in execution, and a baseline to standardize reporting. Small and medium projects should address all phases and stages as prescribed in this guide. The level of rigor required at each SMP lifecycle phase and stage will be less than that required or expected for larger projects. The SMP lifecycle phases and stages include the following: • Pre-Project Phase • Initiation Phase • Planning Phase • Execution Phase o Stages: Design, Development & Testing • Production Phase o Stages: Implementation, Closure, Maintenance Each SMP lifecycle phase and their appropriate stages will be described in the next sub-sections. Two tables will be provided at each sub-section. The first table will explain the logical progression of activities at each phase or stage; the second will summarize each phase by providing its inputs, process, and outputs. The information presented in these tables should be used as reference when applying the SMP methodology. Some of the suggested content may be more or less than what may be required or prescribed for a specific project. It is therefore the responsibility of each project and its governance to determine the appropriate level of 6 DOE G 415.1-1 12-21-2015 customization while ensuring that all directives requirements are met. Section 7 of this guide provides information on determining the appropriate tailoring or customization for a specific project. 4.2.1.1 Pre-Project Phase The Pre-Project Phase is applied in the SMP framework to ensure that foundational tasks have been considered or fulfilled prior to initiating a project and committing further federal and contractor resources. The Pre-Project Phase is typically driven by an identified business need from the business or requestor organization proposing the project (e.g. Business Owner). During the Pre-Project Phase, initial business objectives and requirements are collected, categorized, and assessed to determine business and technical feasibility. This initial feasibility assessment may be informal or it may require compliance with appropriate governance, specific departmental protocol, or follow a prescribed intake process. Outputs from the initial feasibility assessment will become essential inputs to the Business Case Document (or Concept Paper) which is typically required to formally justify the need, provide a proposed solution, and obtain the appropriate sponsorship and funding approval to begin the Initiation Phase. Even though there are no formal gates to exit the Pre-Project Phase, it is not advisable to advance to the Initiation Phase without appropriate concept and budget approval from Sponsor and funding stakeholders. Table 1 provides a logical view of the Pre-Project Phase based on the progression of key activities. DOE G 415.1-2 7 12-21-2015 Table 1: Pre-Project Phase - Key Activities Key Activities Outcome Business Need Feasibility Assessment Sponsorship Approval Governance Approval Budget & Funding Begin Initiation  Identify the Goals & Objective Outcomes (Business Need)  Determine and Define (at High-Level): Initial Scope, Initial requirements, Resource Requirements, available alternatives, Cost, Timeline to Achieve; and Recommended solution  Identify policy requirements (e.g. Office of Management and Budget (OMB), Cybersecurity, U.S.

Rehabilitation Act Section 508)  Champion for the Project Accepts Recommended solution  Organizational acceptance for the Investment of Resources & Time  Project Manager Assignment  Project cost estimate is accepted.  Funding is formally committed.  Project is prioritized against other projects in the portfolio.  Funding allocated by Acquisition Executive / Contract Office Representative/ Office of Chief Financial Officer (CFO-Object Classes)  Signature Approval to Proceed (e.g. Business Case)  PM Assigned & Accountable  Proceed to Initiation Phase Propose Accept Fund Start Table 2 summarizes the Pre-Project Phase using an input, process, and output flow. The highlighted artifacts are also presented in Section 4.3 of this guide and defined in Appendix D. 8 DOE G 415.1-1 12-21-2015 Table 2: Pre-Project Phase Summary Note: Only SMP recommended artifacts are highlighted in this table. Other deliverables (which may also be artifacts) are included for their importance and input to SMP Essential Artifacts. 4.2.1.2 Initiation Phase: During the Initiation Phase the Project Manager (PM) 3 assumes day to day responsibility of the project (i.e. no longer the Business Owner) and will work to identify and define the scope, schedule, and budget to meet project objectives. The PM will customarily use Pre-Project phase outputs (e.g. documented objectives, requirements, feasibility assessment, Rough Order of Magnitude, and the approved Business Case) to develop the Project Charter Document. The Project Charter essentially confirms the agreed upon project goals, objectives, and path forward. While the Pre-Project Phase focused on justifying the business and technical benefits of a proposed business need, the Initiation Phase now requires the PM to define how the need will be met from a project management perspective. The PM utilizes the Project Charter to gain 3 The term <Project Manager> or <PM> will be used throughout the SMP to refer to both the FPM and CPM. DOE G 415.1-2 9 12-21-2015 concurrence on the project objectives and ultimately obtain sponsor and key stakeholder approvals to officially authorize the project. The Project Charter document may be a multiple page artifact or may be customized to a single or double page document depending on the specific project and its governance. Table 3 provides a logical view of the Initiation Phase based on the progression of key activities. Table 3: Initiation Phase - Key Activities Key Activities Outcome Charter Approval Project Team(s) Critical Decision (CD) Review Begin Planning  Describes project & Scope Statement  Lists Goals, Objectives, & Initial Requirements  Identifies Milestones & Schedule  Lists Deliverables & Success Criteria  Identifies Key Stakeholders  Confirms Budgeted Cost  Lists Initial Risks, Constraints, & Assumptions  Assemble Project Team (dedicated resources) to support Planning, Execution, & Production Phases  For Coordination and Collaboration o Integrated project Team(s) (cross-organizational /functional) o Working Group(s) (Focused on specific areas) o Subject Matter Experts (Consult and Guidance)  CD-0 Package  Concurrence on project Charter Details  Determine whether the Project Team is ready to move forward  Signature Approval to Proceed (CD-0 Review Approval)  Begin Project Planning Define Prepare Authorize Proceed As described in Table 3, the PM submits the completed Project Charter to sponsor/s (e.g. Federal

& Technical Sponsors) and other key stakeholders (e.g. Business Owner & Technical Lead) for their review and approval. An approved Project Charter represents concurrence on the initial project scope, (high-level) schedule, and budget. In addition, its approval also provides authorization for the project and PM to commit (Federal and Contractor) project resources. A CD-0 Review is required at the completion of the Initiation Phase to ensure appropriate deliverables were completed and that the project was officially authorized. Table 4 summarizes the Pre-Project Phase using an input, process, and output flow. The highlighted artifacts are also presented in Section 4.3 of this guide and defined in Appendix D. 10 DOE G 415.1-1 12-21-2015 Table 4: Initiation Phase Summary Note: Only SMP recommended artifacts are highlighted in this table. Other deliverables (which may also be artifacts) are included for their importance and input to SMP Essential Artifacts. 4.2.1.3 Planning Phase: During the Planning Phase the PM brings together the project team and initiate their support to the project. As an early project deliverable of the Planning Phase the project team should work to further elicit, document, prioritize, and ultimately baseline business, functional, and non- functional requirements. The PM should ensure that all business and functional requirements can trace back to the original business objectives. A lack of requirements traceability should raise the concern for potential scope creep. System and technical requirements may be known to a degree but will not be further elaborated for baseline until the Execution Phase. With baselined business and functional requirements, the project team can now work to determine the final solution. The final solution will be the method used to deliver the required functionality desired. If only one viable solution exists, the project team can begin to develop the preliminary design, test plan, and training plan. Vendor involvement may be required and engaged via request for proposal, request for quote, and support with development of preliminary design. If multiple viable solutions exist, an alternatives analysis may need to be conducted prior to determining final solution and engaging vendor support. The alternatives analysis should present the pros and cons of each alternative and should conclude with a recommendation of the most optimal method to deliver the solution. The most optimal solution may at times be a DOE G 415.1-2 11 12-21-2015 “hybrid” or contain features from more than one of the analyzed alternatives. The Business Owner and appropriate stakeholders should review and accept the final solution along with the preliminary design before moving forward. The Work Breakdown Structure (WBS) is developed to organize, optimize, and synchronize project team efforts and expectations. Development of the WBS should be a collaborative project team effort as its content should reflect the deliverable outputs directly confirmed by the responsible resources. The WBS supports the development of the Project Schedule and a valuable tool for determining resource requirements and cost estimations. When developing the detail project schedule and identifying dependencies and timeline constraints the project team should review the WBS to ensure that all work has been planned in the schedule. The Work Breakdown Structure (WBS) is a deliverable-oriented hierarchical

decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project. Each descending level represents an increasingly detailed definition of the project work. 4 A WBS is a great way to engage project team and external stakeholders in identifying dependencies and timeline constraints that could impact the overall project schedule. Moreover, the collaborative inputs of stakeholders and cross-functional organizations will improve the quality of the baseline schedule and support greater stakeholder buy-in. Using a WBS to breakdown the project objectives into manageable pieces also provides an opportunity to identify activities or requirements that may have been missed. Table 5 provides a logical view of the Planning Phase based on the progression of key activities. 4 Definition of Work Breakdown Structure: (PMBOK®) Guide – Fifth Edition. 12 DOE G 415.1-1 12-21-2015 Table 5: Planning Phase - Key Activities Key Activities Outcome Collaboration Requirements Processing Work Breakdown Structure Project Schedule Project Management Plan Begin Execution  Project Team(s) determines what it will take to accomplish deliverables.  SME’s (functional/organizational) provide inputs on requirements to meet objectives: o Categorize & Organize (Business, Function, Technical) Requirements o Align Requirements to Objectives o Identify Owners & Contributors o Determine structure and format to Capture Costs o Identify Security Specific items o Collaboration Outputs: Timeline, Resources, Level of Effort, Budget (costs), Dependencies.  Identify Objective based Work Packages (WP’s)  Breakdown into a List of Activities  Determine the sequencing of those activities  Determine Start/Finish of WP’s  Identify and Apply Dependencies  Factor in policy requirements (e.g. OMB, Cybersecurity, U.S. Rehabilitation Act Section 508)  Factor in Dependencies to further build in lead or lag time  Identify Critical Path  Goals & Objectives Overview  Selected Project Approach  Identifies Roles & Responsibilities  Define Approach for Managing Scope, Schedule, Cost, Quality, Communications, Risk, Change Control, etc.  Incorporate Detail Baseline Schedule with Work Breakdown Structure  List of Required Artifacts  Establish Performance Measurement Baseline Metrics  Signature Approval to Proceed (CD-1 Review Approval)  Establish Baseline: o Scope o Schedule o Cost/budget o Quality  Begin Project Execution Prepare Approach Authorize Baseline The Project Management Plan (PMP) is a key output document from the planning phase. The SMP approach provides the PM with the ability to tailor the PMP to include key project management components or to separate those components as separate stand-alone artifacts based on specific project need. The PMP should be clear on its summary of the project management approach and how the project will administer the following processes during execution: • Project Management Approach (Agile/Modular) o Tailoring Approach • Scope Management; • Schedule Management; • Cost Management; • Quality Assurance; • Communications Management; • Risk Management; • Change Control Management • Security Management; and • The Performance Measurement Baseline* DOE G 415.1-2 13 12-21-2015 Additional subsections such as acquisitions, procurement, and human resources may be included

or required depending on the specific project. A list of the project deliverables and expectations supporting its sectioned plans will add value to the PMP and foster greater understanding by the project team and stakeholders. Note, agile development methodologies may prescribe their own activities and artifacts that may differ from those recommended in this guide. In these situations, the project manager should still maintain the essence of each SMP phase, stage, and CD Review. Project management approach as well as tailoring approach should be documented in the Project Management Plan. Table 6 summarizes the Planning Phase using an input, process, and output flow. The highlighted artifacts are also presented in Section 4.3 of this guide and defined in Appendix D. Table 6: Planning Phase Summary Note: Only SMP recommended artifacts are highlighted in this table. Other deliverables (which may also be artifacts) are included for their importance and input to SMP Essential Artifacts. 4.2.1.3.1 Performance Measurement Baseline*: The metrics identified in the PMP will be used to establish the Performance Measurement Baseline (PMB) for tracking progress toward achieving project objectives. The PMB defines the project’s baseline scope, baseline schedule, and baseline budget for the purpose of establishing metrics to measure project performance during execution. The PMB should highlight key success factors prescribed by the customer. 14 DOE G 415.1-1 12-21-2015 A CD-1 Review is required at the completion of the Planning Phase to ensure appropriate deliverables were completed. In particular, the project’s performance measurement baseline must be established to control, manage, and measure project performance during execution. 4.2.1.4 Execution Phase: The Execution Phase Includes processes performed to complete the deliverables (activities, milestones, and artifacts) defined in the Planning Phase. The PM ensures that deliverables and milestones are completed and achieved as agreed in the PMP and Project Schedule. Additionally, the PM continues to provide appropriate status reporting and communication to project stakeholders as specified in the communications section of the PMP. Monitoring and controlling methods are performed to manage risks and changes with the potential to impact the PMB or overall project quality. Some of the deliverables completed during the Execution Phase may include: • Baselining Technical Requirements • Completing Final Design • Obtaining Final Design Approval • Finalizing Test Plans • Finalizing Training Plan • Development Planning • Procurement (for Development) • Conducting Development & Testing • Performing Risk Management • Change Control Management • Conducting Production Readiness Review (PRR) The Design, Development, and Testing Stages are addressed during the Execution Phase. These stages accommodate a systems development approach in alignment with the SMP. The diagram in Figure 5 represents a high level view of the Execution phase with consideration for multiple release solutions. The deliverables for systems, software and non-software projects will vary in their content and application. Figure 5: Execution Phase 4.2.1.4.1 Design Stage: The primary objective of the Design Stage is to create a design that satisfies the requirements gathered and agreed to during the Planning Phase. The end result is an approved design of how DOE G 415.1-2 15 12-21-2015

the proposed solution is to be developed. Test and Training Plans should also be developed and reviewed during the Design Stage-in preparation for development and testing. A CD-2 Review is required at the completion of the Design Stage to ensure appropriate deliverables were completed and in particular final design approval has been attained, test plans have been completed, training plan has been established, and the project is therefore prepared to initiate development. Table 7 provides a logical view of the Design Stage based on the progression of key activities. Table 7: Design Stage - Key Activities Key Activities Outcome Requirements for Design Test and Training Plans CD-2 Review Initiate Development  System/Technical Requirements Baselined  Final Design Review & Approval  Develop Test & Training Plans  Approve Test & Training Plans  Deliverables Completed  Approved Final Design  Test and Training Plans Established and Completed  Determine Preparedness to Begin Development (Technical & Budget)  Signature Approval to Proceed (CD-2 Review Approval)  Begin Project Development Design Prepare Authorize Proceed 4.2.1.4.2 Development Stage: At this stage, the PM along with the project team initiate development planning sessions to collaboratively plan the procurement and approach to support project development. A prototype may be developed in a lab or controlled environment where it can be tested and accepted prior to its implementation or release into the production environment. Although described sequentially, the Development and Testing Stages may occur concurrently to allow for faster diagnosis and resolution of problems and defects identified during development. Modular and agile development approaches are further addressed in Section 6 of this guide. Table 8 provides a logical view of the Development Stage based on the progression of key activities. 16 DOE G 415.1-1 12-21-2015 Table 8: Development Stage- Key Activities Key Activities Outcome Development Planning Meeting Procurement & Reservation Development Authority to Test • Release Planning o Module/Sprint Planning • Procurement Planning • Resources o Materials o Labor o Other • Coordination • Develop Solution • Check Points • Modular & Agile Development • Apply change requests • Obtain Authority to Test • Prepare required documentation Plan Resource Develop Proceed 4.2.1.4.3 Testing Stage: Appropriate Testing is performed as specified in the Test Plan Document. Testing may be performed to validate system or technical requirements and specifications (e.g. network or hardware). Additionally, a User Acceptance Test (UAT) should be performed with the customer or appropriate end-users to validate the system, product, service or feature functionality through hands-on testing. UAT testers are typically designated by the Business Owner. The Business Owner determines the system, product, service or feature readiness for production based on UAT results and feedback from testers. The PM ensures that appropriate training is delivered in advance to UAT resources in preparation for testing. Upon successful completion of all required tests, the PM coordinates the development of the Production Readiness Report. This report provides evidence of successful completion of all tests (including UAT) as specified in the project’s test plan. The Production Readiness Report should be reviewed and approved by the appropriate technical stakeholders who are able to validate

readiness to implement into the production environment. The Production Readiness Review should be facilitated by the PM and should take place prior to the CD-3 Review. This review can be used to ensure that special requirements for security, regulation, or organization specific have been met. In addition to documented evidence that those requirements have been met; there are standard project management documents that should be included for review or referenced during the Production Readiness Review. These additional documents should include: Requirements Document, Design Document, Test Plan (and Test Results), Training Plan, Risk Register, and Implementation Plan. Table 9 provides a logical view of the Testing Stage based on the progression of key activities. DOE G 415.1-2 17 12-21-2015 Table 9: Testing Stage - Key Activities Key Activities Outcome Testing Production Readiness Review CD-3 Review Initiate Implementation o Follows Approved Test Plan o Validation of Accepted Requirements o Appoint appropriate resources o Create Test Cases o Manage Defects o UAT Resource Training o Documented results & changes • Ensure Tests Directly Address Project Requirements & Final Design • Validation of features and functions • All required security controls tested and documented (e.g. ATO) • Review Open Items Risks, Issues, Punch List Items • Determine Readiness for Production  Deliverables completed  Testing completed successfully with documented results  Production Readiness Review and Approval received o ATO Package completed and approved (If Applicable)  Approval Obtained (CD-3 Review Approval)  Proceed to Production Phase Test Document Review Authority to Operate A formal Authorization to Operate (ATO) may be required if implementing a new system or if applying significant changes to an existing system. Specific ATO prescribed artifacts will need to be developed and presented to designated authority for their approval. ATO approval is required prior to exiting the Testing Stage and beginning implementation in production environment. The ATO approval process will crossover into the Production Phase where a formal signature from designated authority will be required after implementation and before the system is handed-off to production. The CD-3 Review formally accepts advancing the project into the Production Phase. Tables 10 and 11 summarizes the Execution Phase using an input, process, and output flow. Two tables are provided to separate Design Stage from Development and Testing Stages (both also culminate at separate CD Reviews). The highlighted artifacts are also presented in Section 4.3 of this guide and defined in Appendix D. 18 DOE G 415.1-1 12-21-2015 Table 10: Execution Phase (Design Stage) Summary Note: Only SMP recommended artifacts are highlighted in this table. Other deliverables (which may also be artifacts) are included for their importance and input to SMP Essential Artifacts. Table 11: Execution Phase (Development & Testing Sages) Summary Note: Only SMP recommended artifacts are highlighted in this table. Other deliverables (which may also be artifacts) are included for their importance and input to SMP Essential Artifacts. DOE G 415.1-2 19 12-21-2015 4.2.1.5 Production Phase The Production Phase includes the Implementation, Closure, and Maintenance Stages of the project. During this phase, the PM ensures that the system, product, service, or feature/s accepted

for production (CD-3 Review) is successfully implemented or released into the production environment. In contrast to the Implementation and Closure Stages which are part of the traditional project management lifecycle, the maintenance stage initiates post-project-closure, operations and maintenance oversight of the implemented system, product, service, or feature. 4.2.1.5.1 Implementation Stage: During the Implementation Stage, the feature or product is implemented or released in the production environment. Post implementation testing is conducted, and training is provided to customer, operations, and/or end-users. Appropriate user and administrator guides are made available to appropriate end-user. As mentioned in the Testing Stage, ATO Approval should take place during this stage, after the system has been implemented but before it is formally handed- off to operations. If the implementation and post testing validations are successful, the PM will transition the system, product, or feature functionality over to operations. When all implementation efforts have been concluded, the project team will complete the Post Implementation Report and review it with the Federal Sponsor. The Post Implementation Report should provide evidence that: the product, feature, or functionality was implemented successfully; it satisfies the business requirements or other exit criteria established during the Planning Phase; and it was successfully transition to operations. Post Implementation Review approval by the Federal Sponsor allows the project to transition into the Closure Stage. Table 12 provides a logical view of the Implementation Stage based on the progression of key activities. Table 12: Implementation Stage - Key Activities Key Activities Outcome Production Operational Readiness Post Implementation Review Initiate Closure o Implementation Plan o Implementation Schedule o Production Site Readiness o Ensure Resource Availability (Facility, Vendors, Developers, Testers) • Post Implementation Testing (feature/function) • ATO Acceptance & Sign-off • Operations and end-user Training • Transition Documentation Completed  Successful product implementation of features and functions  Business Requirements and Success Criteria Satisfied  Successful Transition to Operations  Approval Obtained (Post Implementation Review w/Sponsor)  Begin Closure Activities Release Implement Transition Authority to Proceed 4.2.1.5.2 Project Closure Stage: At the Closure Stage, the PM completes the Project Closure report which describes all activities required to formally close the project. Project Closure Report should include: evidence that the 20 DOE G 415.1-1 12-21-2015 Post Implementation Review was conducted and approved by the sponsor; status of project transition to operations; timeline for closing project management processes, forums, and contractual agreements; a lessons Learned section; information on future document repository; timeline for releasing project team and stakeholders; and a communications strategy that informs direct and indirect stakeholders about the closure. A CD-4 Review is required at the completion of the Closure Stage to ensure appropriate deliverables were completed, post-implementation review and approval by sponsor was attained, and project closure tasks were concluded or transitioned. Table 13 provides a logical view of the Closure Stage based on the progression of key activities.

Table 13: Project Closure Stage - Key Activities Key Activities Outcome Closure Resources CD-4 Gate Review Project Closure o Verify Post Implementation Sponsor Approval o Product Transition Status o Documentation Updates o Archive PM Documents in (Appropriate) Workspace Repository o Communication Strategy • Release Project Team(s) • Contract Completion Notification • Financial Reconciliation • Transition Post Implementation (Vendor) Support Contracts to Operations  Objectives and Goals Achieved  Requirements Satisfied  Documentation Archived  Verification of Approvals  Closure Tasks Completed  Written Sponsor Acceptance  Approval to Close-out project  Notification for Annual Operational Analysis Report Release Archive Acceptance 4.2.1.5.3 Maintenance Stage: The Maintenance Stage begins after a system, product, service or feature has been transitioned to operations. During this stage, operations team takes ownership over the standard operating functionality and maintenance of the system, product or feature. Additionally, operation team will take ownership of contractual support level agreements with vendors and for ensuring that the system, product, service or feature continues to meet customer or end-user expectations. In the case of software related products, this will include maintaining and renewing appropriate licenses agreements. An Annual Operational Analysis is conducted by operations team to determine if the system is continuing to meet expectations, requires additional development, or reaching end-of-life (or support). Results from the Annual Operational Analysis are communicated to appropriate stakeholders who may need this input to make appropriate system or product decisions. When determined that the system or product is reaching end of life, operations team should perform proper system disposition to ensure that a system's components, data, software and DOE G 415.1-2 21 12-21-2015 hardware are disposed of properly and according to organizational regulations. Vital information is archived, secured, and maintained for future business or system needs. Table 14 provides a logical view of the Maintenance Stage based on the progression of key activities. Table 14: Maintenance Stage - Key Activities Key Activities Outcome Collect Evaluate Annual Operational Analysis Determination o System or Product Performance Data o Lifecycle and Contractual Data o Feature/Function Updates o Financial Information • Feature Function Effectiveness • Lifecycle and Contractual Status • Business Needs and Requirements Status • Financial Status and Health  System or Product Meets Intended Purpose  Return on Investment Status  Renewal or Retirement Status  Modify, Maintain, or Improvement  Written AoA Report  Recommendatio n Approvals  Determination Documentation Review Control Recommendation Status Notification Table 15 summarizes the Production Phase using an input, process, and output flow. The highlighted artifacts are also presented in Section 4.3 of this guide and defined in Appendix D. 22 DOE G 415.1-1 12-21-2015 Table 15: Production Phase - Inputs-Process-Outputs Note: Only SMP recommended artifacts are highlighted in this table. Other deliverables (which may also be artifacts) are included for their importance and input to SMP Essential Artifacts. 4.3 SMP Essential Artifacts The SMP Essential Artifacts illustrated in Figure 6 suggests a customized set of artifacts which

should be considered by small and medium size IT projects. These artifacts satisfy the minimum required to manage an IT Project utilizing the SMP. Depending on complexity, security risk, and management/organizational protocol, some projects may require more or fewer artifacts. As with the SMP WBS, the SMP Essential Artifacts are strategically positioned to progressively establish project information that supports the overall objectives, intent of each lifecycle phase, and individual CD Review. With appropriate governance approval, project teams may modify, consolidate, replace, or omit SMP Essential Artifacts as long as they preserve the essence, purpose, and goal of each lifecycle phase and CD review as described in this guide. Project artifacts should be defined in the Project Management Plan and reviewed for concurrence and DOE G 415.1-2 23 12-21-2015 approval at the CD-1 Review. Appendix D in this guide provides additional description and definition for each SMP artifact. 1. Requirements Document 2. Cost Estimate Report 3. Enterprise Architecture Worksheet 4. Business Case Document 5. Project Charter 6. Risk Register 7. Detail Project Schedule (with WBS) 8. Project Management Plan 9. Change Control Log 10. Final Design Document 11. Test Plan 12. Training Plan 13. Production Readiness Report 14. Implementation & Transition Plan 15. Post Implementation Report 16. Project Closure Report Figure 6: SMP Essential Artifacts 24 DOE G 415.1-1 12-21-2015 4.4 Key Project Stakeholders Small and medium projects seek to deliver quick results to its customers. The fast paced nature of these projects makes it necessary to have well defined roles and responsibilities from project conception to project closure. Well defined roles and responsibilities help to promote proper and timely execution of deliverables, processes, reviews, and approvals. The SMP suggests a number of Key Project Stakeholders for their typical role and importance supporting small and medium projects at the DOE. Table 16 lists and describes the SMP Key Project Stakeholders. Table 16: SMP Key Project Stakeholders Roles Description Federal Sponsor (FS) Federal executive who is ultimately Accountable for the project and for fulfilling the business need. Has authority to assign or request project management support. Can authorize the start and end of the project. Sets priorities for the project. Reviews and approves project artifacts (e.g. Business Case, Project Charter, & Post Implementation Review). Provides funds for the project. Makes critical project decisions to resolve major project conflicts.  Assigns resources (e.g. Business Owner) to process a new business need.  Reviews and approves Business Case.  Reviews and approves Project Charter.  Reviews and approves Post Implementation Report. Business Owner (BO) Project team member representing the customer, end-users, or Federal Sponsor. Drives the business need through appropriate project intake process. Develops the Business Case and coordinates its review and approval by appropriate sponsors and governance stakeholders. Ensures intended benefits (e.g. Return on Investment) as captured in the Business Case are realized. Supports the project manager and project team with requirements gathering, prioritization, acceptance, and establishing baseline. Reviews deliverables prior to submission to Federal Sponsor. May provide suggestions, feedback,

and acceptance on change requests, risks, and other conflicts which may impact performance baseline. Coordinates the execution of user acceptance testing (UAT). Engages the support of the Federal Sponsor as needed.  Typically assigned by Federal Sponsor or Customer organization to manage business need.  Submits formal business need through appropriate project intake process.  Develops the Business Case.  Coordinates appropriate Business Case review and Approval.  Reviews and accepts Project Charter prior to submission to Federal Sponsor. DOE G 415.1-2 25 12-21--2015 Roles Description  Supports project team with requirements gathering, prioritization, acceptance, and baseline.  Reviews and approves final design.  Supports project team with development of UAT plan.  Coordinates UAT testing. Assigns appropriate resources (End-Users) for testing.  Reviews and accepts Post-Implementation Report prior to submission to Federal Sponsor. Technical Sponsor (TS) Federal executive accountable for delivering the project’s technical solution/s within agreed project baseline. Has authority to assign the (technical) Project Manager and (technical) implementation team to support the project. Oversees, evaluates, and supports the work and progress of its technical project staff. Makes decisions to resolve major technical conflicts. May escalate or address major concerns and issues directly with Federal Sponsor. Manages budget within their technical organization.  Assigns technical resources to support Project Intake Process (i.e. feasibility assessment).  Reviews and approves Business Case.  Reviews and approves Project Charter.  Reviews and approves Final Design.  Reviews and approves Production Readiness Report. Intake Assessment Team (IAT) Established process typically driven by an IT organization where an Interim team receives, analyzes, and determines the technical and business feasibility of a new business need. Includes the evaluation and assessment of representatives from different organizations who may be impacted or who may need to support the implementation of the solution. Assessment feedback is utilized by IAT team to develop a Rough Order of Magnitude (ROM), answer Enterprise architecture worksheet questionnaire, and provide justification which can be used by the Business Owner to develop the Business Case.  IAT receives, analyzes, and determines the technical and business feasibility of a new business need. Includes ROM development.  Assessment feedback is utilized by IAT team to answer (Pre-Project) Enterprise Architecture worksheet questionnaire.  Outputs are delivered to Business Owner to support Business Case development. Technical Lead (TL) Project Team Member and subject matter expert (e.g. Systems Architect) who provides solutions to technical challenges facing the project. May become involved early in the project lifecycle to support the Business Owner articulate 26 DOE G 415.1-1 12-21-2015 Roles Description the business need. Reviews and approves technical material and artifacts. Ensures the finished product meets the design and technical specifications of their clients.  May be assigned early to support the business owner articulate the business need.  May support IAT team during project Intake Process.  May be required to provide Business Case approval.  May be required to provide Project Charter approval.  Provides Final Design Approval.

 Provides Production Readiness Approval Federal Project Manager (FPM) Responsible for the overall success of the IT project and for reporting to key project stakeholders. Leads the development of the Project Charter, Project Management Plan, Project Schedule, Post-Implementation Report, and Project Closure Report. Manages the timely delivery of activities and artifacts assigned to Project Team. Initiates and coordinates the execution of CD Reviews with CD Review Approvers.  Develops the Project Charter Document.  Facilitates Project Charter Document review and approval.  Assigns/commits project resources.  Initiates and coordinates CD-0 Review.  Develops the Project Management Plan (PMP).  Develops the Project Schedule.  Initiates and coordinates CD-1 Review.  Initiates and coordinates CD-2 Review.  Initiates and coordinates CD-3 Review.  Initiate next module/sprint if required.  Develop Post Implementation Report.  Develop Project Closure Report.  Initiates and coordinates CD-4 Review. Contractor Project Manager (CPM) Contractor responsible with supporting the FPM with the day-to-day management of the IT project (See FPM role description) Implementation Team Technical and Non-Technical staff assigned to support the planning, development, testing, and implementation phases and stages of the project. These individuals bring the appropriate IT, Engineering, Operations, Security, Architecture, Quality Assurance, Procurement, and product/service expertise. DOE G 415.1-2 27 12-21--2015 Roles Description The Project Manager relies on the Implementation team to support with:  Gather, prioritize, document, and baseline business and functional requirements.  Determine and document final solution (e.g. Alternatives Analysis).  Gather, prioritize, document, and baseline technical requirements.  Supports development of Final Design.  Supports development of Test Plans.  Supports development of Training Plan.  Supports development and Testing efforts.  Supports development of Production Readiness Report.  Supports development of Implementation Plan.  Supports Implementation or Release in production environment. Critical Decision Approvers (CDA) Responsible for approving or rejecting the advancement of a project to its successive phase or stage during a CD Review. Have a stake or interest in the project and hold appropriate authority to influence governance decisions over the project.  CO-0 Review acceptance.  CO-1 Review acceptance.  CO-2 Review acceptance.  CO-3 Review acceptance.  CO-4 Review acceptance.  Note: The project stakeholders referenced in this section suggest a typical composition which may be utilized at the DOE. Some projects may differ and involve more or less stakeholders depending on unique circumstances, organizational protocol, or as prescribed by project governance. 5 Monitoring & Controlling Flexibility and speed to market are benefits which may be realized by smaller size projects. These benefits can also become problems without the proper controls built into the project to protect established baseline scope, schedule, cost, and quality. Problems such as unmanaged risks, scope creep, lack of governance, and poorly developed artifacts can quickly impact project performance and success. To avoid these problems the SMP recommends a number of monitoring and controlling methods which are applicable to all small and medium size projects.

All monitoring and controlling methods used in the project should be documented and explained in the Project Management Plan. The Monitoring and Controlling methods recommended by the SMP include: 28 DOE G 415.1-1 12-21-2015 • Risk Management • Change Control Management • Schedule Management • Project Reviews • Project Cost Tracking 5.1.1 Risk Management A risk is an event or condition that if it occurs, could have a positive or negative effect on the project. Risks should be identified early and continually across the life of the project to determine their probability and potential impact. An initial risk assessment should be conducted and documented in the Project Charter. A Risk Register should be utilized beyond this initial point to document and manage open risks. The Risk Register is a central repository for all risks identified in the project. For each risk the Risk Register includes information such as risk probability, impact, and response plan. A Risk Management section describing how the project will perform risk management should be included in the Project Management Plan and reviewed at CD-1 Review. Figure 7 illustrates a suggested diagram for managing risks using the SMP: Note: The Risk Register is utilized as the primary tool to record and manage tools from “Identify Risks” to “Close Risk Management”. Figure 7: SMP Risk Management 5.1.2 Change Control Management A Change Control Management process must be instituted to control change requests after the project has achieved baseline. Change requests can be made by several individuals or groups which may include the customer (or end-user), Sponsor, Funding Organization, Business Owner, Technical Implementation Team, Vendor, Project Manager, Project Team, and other project stakeholders. All change requests should be evaluated prior to acceptance. A Change Control Management process should provide a systematic approach to manage change requests that ensures proper documentation of the request, impact assessment, review, and final acceptance. This evaluation and acceptance helps to prevent scope creep and inefficient use of project DOE G 415.1-2 29 12-21-2015 resources. A Change Control Log should be utilized to help document and manage all change requests. A change control log tracks the progress of each change request from submission through review, approval, implementation, and closure. The SMP does not establish formal Change Control Management Roles as those used by larger projects (e.g. Change Control Board, Change Control Manager). Instead, the SMP places accountability on the PM and Project Team to determine their individual Change Control Management governance. The Change Control Management process is documented in the Project Management Plan and reviewed during CD-1 Review. The process should be followed from this point forward to appropriately assess the impact changes will have on the project’s scope, schedule, and budget. Figure 8 illustrates a suggested diagram for conducting Change Control Management using the SMP. Figure 8: SMP Change Control Management Plan 5.1.3 Work Breakdown Structure & Schedule Management 5.1.3.1 Work Breakdown Structure The PMBOK defines Work Breakdown Structure (WBS) as a “deliverable oriented hierarchical decomposition of the work to be executed by the project team.” The work breakdown structure visually defines the scope of the project in manageable chunks that project teams can understand.

30 DOE G 415.1-1 12-21-2015 Each level of the work breakdown structure should provide further definition and detail. The WBS is a useful tool whose decomposition can help in determining resource requirements, cost packages, and more importantly help with developing the project schedule. The SMP WBS emphasizes the following structure: • Objective A Level 1: Output/Artifact Level 2: Activity Level 3: Sub-Activity 5.1.3.2 Schedule Management Schedule management should be progressively developed and managed across the project lifecycle. Project schedules should help align and communicate what, when, and who will perform project deliverables or tasks. Schedules should become more and more detailed over time or as the project is defined. A project’s baseline schedule is established during the planning phase or by CD-1. SMP project schedules progress through three systematic evolutions which include: • High-Level Schedule; • Milestone Schedule; and • Detail Project Schedule (Baseline). Figure 9 illustrates the progression of SMP project schedules across the project lifecycle. These are further described in the sections that follow. Figure 9: SMP Schedule Progression 5.1.3.3 High-Level Schedule During the Pre-Project Phase the customer may specify need-by-dates or schedule expectation for the proposed project and its solution. The SMP calls this initial schedule the “High-Level Schedule.” The High-Level Schedule does not typically include durations, resources, dependencies, or project management milestones. This initial schedule is considered when determining the rough order of magnitude and may be captured or illustrated in the Business Case Document. Table 17 illustrates a sample structure of a High-Level Schedule. DOE G 415.1-2 31 12-21-2015 Table 17: SMP High-Level Schedule # Deliverables/Tasks Due Date 1 Objective A (Date) 2 Output/Artifact (Date) 3 Activity (Date) 4 Sub-Activity (Date) 5 Objective B (Date) 6 Output/Artifact (Date) 7 Activity (Date) 8 Sub-Activity (Date) 5.1.3.4 Milestone Schedule Once the project moves into the Initiation Phase, the PM will further develop the schedule by incorporating project management lifecycle phases and milestones such as CD Reviews or significant accomplishments. This milestone schedule should be incorporated and presented as part of the Project Charter Document. The milestone schedule begins with the inclusion of project management milestones and known dependencies, but will not yet capture task duration or resources. Table 18: SMP Milestone Schedule # WBS Deliverables/Tasks Due Date Dependency 2.0 Planning Phase 1 2.0 Objective A (Date) 2 2.0.1 Output/Artifact (Date) 3 2.0.2 Activity (Date) 4 2.0.3 Sub-Activity (Date) 5 2.1.0 Objective B (Date) 1 6 2.1.1 Output/Artifact (Date) 7 2.1.2 Activity (Date) 8 2.1.3 Sub-Activity (Date) 9 2.3.0 CD-0 Review (Date) 1,5 10 2.3.1 Output/Artifact (Date) 11 2.3.2 Activity (Date) 12 2.3.3 Sub-Activity (Date) 3.0 Execution Phase 5.1.3.5 Detail Project Schedule The Detailed Project Schedule provides a logical breakdown of the work to be performed. The detailed schedule will require input from the project team and other stakeholders and therefore should be completed after CD-0 (once resources are committed to project). A WBS should be developed as a precursor to developing the Detailed Project Schedule. The WBS may be utilized and further developed for this purpose. Unlike the previous two schedules, the Detailed Project

Schedule should include tasks, subtasks, durations, and resources. In some cases, the Detailed Schedule may also include cost information for each task or work package. The first instance of 32 DOE G 415.1-1 12-21-2015 the Detailed Project Schedule will be the baseline schedule provided during the Planning Phase along with CD-1 Package. Beyond CD-1, the Detailed Project Schedule should be continually reviewed and updated as needed. Schedule changes or updates with a potential to impact established project baseline metrics should first be evaluated according to the project’s Change Control Management Plan. The Detailed Project Schedule may be closed once Production Phase implementation has been completed, Post-Implementation Review approval has been attained from sponsors, and Project Closure Report tasks have been closed or transitioned to Operations. Table 19: SMP Detailed Project Schedule # WBS Deliverables/Tasks Start Finish Dependency Resources 2.0 Planning Phase 1 2.0 Objective A (Date) (Date) 2 2.0.1 Output/Artifact (Date) (Date) (Name/s) 3 2.0.2 Activity (Date) (Date) (Name/s) 4 2.0.3 Sub-Activity (Date) (Date) (Name/s) 5 2.1.0 Objective B (Date) (Date) 6 2.1.1 Output/Artifact (Date) (Date) (Name/s) 7 2.1.2 Activity (Date) (Date) 1 (Name/s) 8 2.1.3 Sub-Activity (Date) (Date) 3 (Name/s) 9 2.3.0 CD-0 Review (Date) (Date) 5,6 10 2.3.1 Output/Artifact (Date) (Date) 6 (Name/s) 11 2.3.2 Activity (Date) (Date) 7 (Name/s) 12 2.3.3 Sub-Activity (Date) (Date) 9 (Name/s) 3.0 Execution Phase There are many tools that can be used to manage the schedule. Project management software programs also offer network, resource, and Gant chart views that can be used for reviewing and reporting on the project status and progress. 5.1.4 Project Reviews Project reviews are used to brief project stakeholders on the status of the project. Topics such as accomplishments, planned activities, risks, issues, and baseline metrics are typically presented during project reviews. Project reviews provide an opportunity to obtain feedback from stakeholders on the progress of the project. Feedback can be used to make improvements that are directly aligned to stakeholder recommendations. Project reviews can also create an opportunity to communicate and escalate risks and constraints to governance stakeholders who may have the authority to provide relief and timely corrective action. The Communications Management section of the Project Management Plan should list all planned project reviews. There are different types of reviews associated with project management. The following bullets list some of the most typical project reviews: • Routine o Weekly/Monthly/Quarterly DOE G 415.1-2 33 12-21-2015 o Management or Leadership • Event Driven o CD Reviews o Operational Readiness Review • Independent o IT Council / IRB o Inspector General (IG) 5.1.5 Project Cost Tracking Project cost tracking is an essential monitoring and controlling task that should be performed across all phases of the project to control and monitor budget performance. Cost tracking begins early in the project lifecycle when rough order estimations made to determine the Total Cost of the project. Project teams may utilize special software to track project costs or off the shelf spreadsheet application. At the Pre-Project Phase, cost estimates become critical inputs to the Business Case and utilized

to determine financial feasibility, determine appropriate budget, and financial justification and analysis tools such as the cost benefit analysis and the return on investment. Once the Business Case Document is approved and initial budget is appropriated, the project is ready to enter the Initiation Phase. At the Initiation Phase the project manager should utilize the Project Cost section of the Project Charter to update project cost information such as planned cost, actual spent, and available amount against initial appropriated budget. The projections documented in the Project Charter allows the sponsor and financial stakeholders to remain informed and make appropriate and timely financial decisions based on project cost tracking projections. At the Planning Phase, the project manager will work to baseline project scope, schedule, and budget and therefore achieving greater certainty with regards to total project cost. During the Planning Phase the project team will define how the project will manage costs during the execution phase. This information can be documented in a standalone document such as the Cost Management Plan or it may be included in the cost management section of the SMP Project Management Plan template. The project’s cost management approach should make clear who are the responsible stakeholders, cost tracking process, cost tracking tools/artifacts, and cost/budget governance and approvals. Once cost is baselined, other monitoring and controlling process such as Change Control Management and Risk Management should be also utilized to manage and avoid cost overruns. The PM should ensure that project follows the documented cost management process during the execution and production phases. The project cost tracker along with other monitoring and controlling artifacts should be included with each CD Package and reviewed at each CD Review. 34 DOE G 415.1-1 12-21-2015 6 Modular & Agile Approach Projects that require greater flexibility, optimize incremental development, seek to decrease investment risk, solution based focus, and maximized return on investment via the development, testing, and release of prioritized, partial products or features (of a larger design) may want to consider using a modular or agile approach.  Modular approaches advocate the division of a project’s scope into several smaller increments that provide for delivery, implementation, and testing of workable systems or solutions in discrete increments. Through an incremental release approach, modular and agile approaches can help reduce project risk, reduce cost, improve visibility, and better adapt to changes in scope and customer expectations. 5  Agile is an iterative and incremental (evolutionary) approach to software development which is performed in a highly collaborative manner by self-organizing teams within an effective governance framework with “just enough” ceremony that produces high quality software in a cost effective and timely manner which meets the changing needs of its stakeholders. 6 The definition of modular and agile approaches help to understand the similarities and slight differences that exist between the two. One distinction is that with agile approaches, the focus is placed on dividing the efforts into chronological sprints, almost all of which are equal in duration whereas the focus in modular approaches is placed on how to best partition the overall effort into individual modules.

The goal of this section is not to focus on any specific modular or agile methodology (e.g. SCRUM). Instead, it provides a general overview of common methods and practices which can be applied using the SMP framework. Project teams may apply external methodologies if determined to be beneficial to the success of a specific project. Project stakeholders may realize early in the project lifecycle that a modular or agile approach would be most beneficial for their project. This realization may be based on the type of requirements, contractual circumstances, or specific product delivery/release expectations. The modular or agile approach to be used should be described early in the project (e.g. Project Charter or PMP) to ensure project team, sponsor, and stakeholder understanding. 6.1 SMP Modular Workflow The use of a modular approach is not limited to software development projects. A modular approach can be used by any project seeking greater flexibility, a reduced investment risk, to remain solution focused, vendor contracting options, and a maximized return on investment. This also promotes incremental development and delivery of products or services. Figure 10 5 White House, Contracting Guidance to Support Modular Development, dated June 14, 2012 6 http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm DOE G 415.1-2 35 12-21-2015 illustrates the SMP Modular Approach. Unless specified in the project management approach section of the PMP, the SMP modular workflow assumes the use of the SMP Essential Artifacts presented in Section 4.3 of this guide. Additional subcomponents are included to illustrate important sub activities important to this workflow. Figure 10: SMP Modular Approach 6.2 SMP Agile Workflow There are numerous agile methodologies but all seek to achieve the same results and benefits as with the modular approach. Agile methodologies such as Scrum are mainstream methods for deploying software development products. Moreover, the popularity of Scrum has triggered the use of its vocabulary which is gradually becoming part of the conventional agile lexicon. Table 20 describes important agile terms which are also used in our SMP Agile Workflow. Table 20: Important Agile Terminology Agile Terms Description Release The transition of an increment of potentially shippable product from the development team into routine use by customers. Releases typically happen when one or more sprints have resulted in the product having enough value to outweigh the cost to deploy it. Scrum Scrum is a simple yet incredibly powerful set of principles and practices that help teams deliver products in short cycles, enabling fast feedback, continual improvement, and rapid adaptation to change. As the leading 36 DOE G 415.1-1 12-21-2015 Agile Terms Description agile development framework, Scrum has predominantly been used for software development, but it is also proving to be effective in efforts far beyond. Sprint An iteration of work during which an increment of product functionality is implemented. Iterations typically last +/- 30 days. Sprint Planning The Sprint planning meeting is a negotiation between the team and the product owner about what the team will do during the next sprint. Sprint Retrospective The sprint retrospective meeting is held at the end of every sprint after the sprint review meeting. The team meets to discuss what went well and what

to improve in the next sprint. Sprint Review Informal meeting held to assess the project against the sprint goal determined during the sprint planning meeting. Product Backlog The product backlog (or "backlog") is the requirements for a system, expressed as a prioritized list of product backlog Items. These included both functional and non-functional customer requirements, as well as technical team-generated requirements. “Glossary of Scrum Terms” Scrumalliance.org, 12 March 2007 7 7 “Glossary of Scrum Terms” Scrumalliance.org, 12 March 2007 DOE G 415.1-2 37 12-21-2015 Figure 11 illustrates the SMP Agile Workflow. Unless specified, the SMP Agile Workflow diagram assumes an abbreviated use of the SMP framework as described in sections 1 through 5 of this guide. Agile methodologies such as SCRUM may prescribe their own artifacts, team roles, project reviews, and acceptance protocols. To ensure understanding among stakeholders, the PM must describe the agile methodology being used and highlight any differences to the SMP methodology. 8 Regardless of the agile methodology being used, projects should maintain the essence of each SMP phase, stage, and CD review. Figure 11: SMP Agile Workflow 7 Tailoring Opportunities The SMP recognizes that projects may need to be tailored to meet the specific needs of an organization, solution, or requestor. A PM may be required to customize the deliverables and the approach. All tailoring approaches should be ultimately reviewed and accepted by appropriate project-governance stakeholders prior to being implemented. The SMP suggests that the tailoring process includes a review of the following project considerations for customization: 8 Describe agile methodology being used and any differences to the SMP methodology in the Project Management Approach section of the PMP document. 38 DOE G 415.1-1 12-21-2015 • Importance • Type • Timeline • Deliverables • Approach These key areas for considerations will allow the project manager to further define the project’s characteristics; as noted in Table 21. Table 21: Project Tailoring Considerations Project Considerations Importance Type Timeline Deliverables Tailored Project Approach o Governance Level o Complexity (Technical, Risk, or Impact) o Low, Medium, High Visibility and Oversight o Budget & Value of Investment • HW/SW Solution • Infrastructure Implementation • Knowledge Based Solution • Administrative Effort  Duration  Major Milestone Dates  Deliverables & Due Dates  Project Completion Deadline  System and Software Releases  Incremental Deliverables  Security Requirements  Documentation  Waterfall (traditional)  Modular or Phased  Agile  Program (sub-projects) Project Characteristics A project tailoring approach can be progressively or instantaneously defined. For example, project stakeholders may determine during the Pre-Project Phase that a formal Business Case Document may not be necessary given that appropriate sponsor and budget approvals are already in place. Under this circumstance, a proposed project may be ready to be handed to a Federal PM to begin the Initiation Phase. Project teams may determine other tailoring opportunities as they progress across the lifecycle and define scope and determine final solution. The tailoring approach should be documented in the Project Management Plan and be presented for approval

at the CD-1 Gate Review. Tailoring opportunities determined beyond the CD-1 Review may need to be evaluated via the project’s change control management process to assess impact to resources and established project baseline (e.g. Scope, Schedule, budget, or Quality). The SMP itself is a result of tailoring the IT PEM methodology to better meet the needs of project managers working on projects that fall under or outside the scope of DOE O 415.1. The SMP is not considered a tailoring guide and only suggests items for consideration and examples of project characteristics to be included. The process of tailoring includes a Question and Answer (Q&A) review that should be conducted by the PM in order to further clarify project characteristics. Understanding the project’s characteristics is an important step to the tailoring process and essential to customizing the project approach and deliverables. The Q&A’s will vary from project to project and the process for tailoring projects may include, but not be limited to those found in Table 22. DOE G 415.1-2 39 12-21-2015 Table 22: Examples of Tailoring Questions Project Considerations & Characteristics Tailoring Questions Project Importance How important is this project?  Governance Level  Visibility & Oversight (Low/Medium/High)  Budget & Value of Invest ment  Is the appropriate sponsorship in place?  Will it require IT Council or Governance Board acceptance?  Does it impact more than one DOE Element?  What is the estimated Total Project Cost (TPC)?  Does it meet CPIC criteria for a Large Investment?  Will Pre-Project Justification (Business Case) be required? Project Type (examples) What type of solution will be delivered?  HW/SW Solution  Infrastructure Implementation  Knowledge Based Solution  Administrative Effort  Will the project deliver; a HW or SW solution?  Will the project deliver a network (LAN/WAN) solution?  Will the project deliver knowledge (No HW/SW)?  Will the project deliver an administrative solution (e.g. Event planning, QA Initiatives, Resource Mgt.)?  Does it deliver more than one Project Type solution? Project Timeline How long will this project take?  Duration (3, 6, 9 months, etc.)  Major Milestone Dates  Deliverables & Due Dates  Project Completion  What is the expected project completion date?  Can project solution be delivered in partial increments?  Do I need to factor in time for an Alternatives Analysis?  Can CD-2 & 3 be combined (If HW/SW)?  Can decision making be made lean and agile?  Can artifacts be combined or customized for agility? Project Deliverables (examples) What deliverables apply to my project?  System and Software Releases  Incremental Deliverables  Will a feasibility assessment be required prior to Initiation?  Will an alternatives analysis be required? 40 DOE G 415.1-1 12-21-2015 Project Considerations & Characteristics Tailoring Questions  Security Requirements  Documentation  Will a security assessment (& deliverables) be required?  Will conceptual, preliminary, or Final Designs be required?  Will multiple releases (Sprints/Modules) be required?  What documentation is expected (e.g. artifacts, guides, etc.)?  Will the solution require UAT? Training?  Will a Production Readiness Review be required? The PM is responsible for the tailoring process and determinations. The efficiencies realized

through a tailored approach can be very beneficial to mitigate time and resource constraints when performed properly. Conversely, over simplifying the project management level of effort or documentation can increase the risk of an adverse impact on a project’s performance. The suggestion for tailoring or customization is not intended as a license to ignore project management best practices for success. Deviations from the standard SMP framework should still satisfy the intent of each CD gate review and must comply with federal and governmental requirements such as Cybersecurity, OMB, and Enterprise Architecture. DOE G 415.1-2 Appendix A 12-21-2015 A-1 (and A-2) APPENDIX A: ACRONYMS Acronym Definition BO Business Owner CC Change Control CCB Change Control Board CD Critical Decision CDA Critical Decision Approvers CFO Chief Financial Officer CIO Chief Information Officer CPM Contractor Project Manager CR Change Request DOC Document DOE Department of Energy EA Enterprise Architecture FPM Federal Project Manager IG Inspector General IAT Intake Assessment Team IRB Internal Review Board IT Information Technology M Million ($) NNSA National Nuclear Security Administration O Order OCIO Office of the Chief Information Officer PEM Project Execution Model PMB Performance Measurement Baseline PMBOK Project Management Body of Knowledge PMI Project Management Institute PMO Project Management Office PMP Project Management Plan PT Project Team SMP Small and Medium Projects TL Technical Lead TPC Total Project Cost TS Technical Sponsor UAT User Acceptance Test WBS Work Breakdown Structure DOE G 415.1-2 Appendix B 12-21-2015 B-1 APPENDIX B: OCIO RESOURCES AND DEPARTMENTAL REQUIREMENTS The SMP guide aims to support Government-wide and/or Department requirements essential to maintain and/or support federal approaches towards strategy, business, security, and technology. Table 23: Government-wide and DOE Requirements Integrated into the IT PEM provides a list and brief description of some of the OCIO resources and/or department requirements supported by the SMP. Table 23: Government-wide and DOE Requirements Integrated into the IT PEM Topic Summary Source Capital Planning and Investment Control (CPIC) As defined by the Office of Management and Budget (OMB) Circular A-11, “Capital planning and investment control means the same as capital programming and is a decision-making process for ensuring IT investments integrate strategic planning, budgeting, procurement, and the management of IT in support of agency missions and business needs. The term comes from the Clinger-Cohen Act of 1996 and generally is used in relationship to IT management issues.” IT Capital Planning and Architecture Division (IM- 21) DOE.CPICMailbox@hq.d oe.gov Chief Information Officer (CIO) Cost Tracking Object Classes Object Class Codes are categories in a classification system that present obligations by the items or services purchased by the Federal Government and are required by the Office of Management and Budget (OMB) Circular A-11. Ensures that the appropriate agency/program cost codes for financial tracking have been applied for appropriate budgetary management. Standardized Object Class Codes and Definitions, Office of the Chief Financial Officer Configuration Management (CM) Configuration management (CM) is the detailed recording and updating of information that

describes an enterprise's hardware and software. It is a process for establishing and maintaining consistency of a product's performance, functional and physical attributes with its requirements, design and operational information throughout its life. Configuration Management (CM) – OCIO Cybersecurity The definition of Cybersecurity is the protection of information systems against unauthorized access to or modification of information, whether in storage, processing, or transit, against loss of accountability for information and user actions, and against the denial of service to authorized users, including those measures necessary to protect against, detect, and counter such threats. Cybersecurity (IM-30) – OCIO https://powerpedia.energy.gov/wiki/Office_of_Management_and_Budget https://powerpedia.energy.gov/wiki/Office_of_Management_and_Budget mailto:DOE.CPICMailbox@hq.doe.gov mailto:DOE.CPICMailbox@hq.doe.gov Appendix B DOE G 415.1-1 B-2 12-21-2015 Topic Summary Source Enterprise Architecture Enterprise Architecture refers to the explicit description and documentation of the current and desired relationships among business and management processes and IT of an organization. It describes the “current architecture” and “target architecture”. An enterprise architecture includes the rules and standards and systems life cycle information to optimize and maintain the environment which the agency wishes to create and maintain through its IT portfolio. An enterprise architecture should provide a strategy that enables the agency to support its current state and provides a roadmap for transition to its target environment. An enterprise architecture defines principles and goals and sets a direction on such issues as the promotion of interoperability, open systems, public access, end-user satisfaction, and IT security. The agency should support an enterprise architecture with a complete inventory of agency information resources including: stakeholders and customers, equipment, systems, services, and funds devoted to information resources management and IT, at an appropriate level of detail. Enterprise Architecture (IM-1) - OCIO DOEEAMailbox@hq.doe. gov Performance Management and Quality Assurance Division Lead organization for implementing the requirements of DOE O 414.1D within the Office of the Chief Information Officer and is designated as the voting member for the DOE Quality Council. Within IM-60, PMQAD is responsible for ensuring compliance with applicable Federal directives and orders; and ensuring compliance with contractual performance standards and industry best practices, including alignment with ISO 9001:2008 and the Software Engineering Institute (SEI) Capability Maturity Model Integrated (CMMI). Director of Performance Management and Quality Assurance Division (IM- 60) - OCIO EITS_PMQAD@hq.doe.g ov mailto:DOEEAMailbox@hq.doe.gov mailto:DOEEAMailbox@hq.doe.gov mailto:EITS_PMQAD@hq.doe.gov mailto:EITS_PMQAD@hq.doe.gov DOE G 415.1-2 Appendix B 12-21-2015 B-3 (and B-4) Topic Summary Source Records Management Records management, or RM, is the practice of maintaining the records of an organization from the time they are created up to their eventual disposal. This may include classifying, storing, securing, and destruction (or in some cases, archival preservation) of records. The Records Management Division (IM-23) - OCIO Safety and Safeguards

Conduct a preliminary safety and safeguards assessment by CD-0. At CD-1, the AE ensures that the quality assurance practice addresses all safety and security requirements, per the Integrated Safety and Safeguards directives. Office of Environment, Health, Safety, and Security (AU) Section 508 Section 508, an amendment to the United States Workforce Rehabilitation Act of 1973, is a federal law mandating that all electronic and information technology developed, procured, maintained, or used by the federal government be accessible to people with disabilities. Federal Acquisition Regulation (FAR) Subpart 39.201 states that Section 508 must be addressed in all solicitations to purchase E&IT. Technical standards of this law should be incorporated in all PEM Lifecycle phases. The Performance and Management Division (IM- 22) – OCIO DOESection508Coordinator @Hq.Doe.Gov DOE G 415.1-2 Appendix C 12-21-2015 C-1 APPENDIX C: GLOSSARY Term Definition Agile Development Refers to an alternative to traditional/Waterfall project management, typically used in software development. It helps teams respond to unpredictability through incremental, iterative work cadences, known as sprints. Agile methodologies are an alternative to waterfall, or sequential development. Alternative Analysis Refers to an analysis of alternatives for addressing the performance objectives of an investment. The analysis is performed prior to the initial decision to implement a solution and updated periodically, as appropriate, to capture changes in the context for an investment decision. Alternatives analysis documentation should be submitted along with Exhibit 300 for all major IT investments. Alternatives Analysis should be performed for investments with projects in the planning or DME stages, whereas strictly operational investments should instead perform operational analyses until such time as a decision is made to re-evaluate the investment or to resume development, modernization or enhancement. Approach Altering methods for managing small and medium projects (e.g. traditional/waterfall) Approach, Agile approach, and Modular Approach). Baseline A quantitative definition of cost and schedule that serves as a base or standard for measurement and control during the performance of an effort; the established plan against which the status of resources and the effort of the overall Program, Field Program(s), project(s), task(s), or subtask(s) are measured, assessed, and controlled. Once established, baselines are subject to a change-control discipline. Budget A prediction of the costs associated with a particular project. This budget includes labor, materials, and other related expenses. Business Owner • Project team member representing the business/end-users • Driving the business need through appropriate project intake process • Responsible for developing the Business Case and obtaining appropriate approval/s. • Ensures intended benefits captured in the Business Case are realized. • Plays key supporting role in requirements gathering • Validates deliverables prior to submission to Federal Sponsor • Validates project baseline • Facilitates the execution of user acceptance testing (UAT) • Engages the Federal Sponsor as needed Appendix C DOE G 415.1-1 C-2 12-21-2015 Term Definition CD Approvers The ultimate goal of a CD Approver is to advance a project to

its successive phase or stage. CD Approvers should be identified and assigned by each individual project team and their respective governance early in the project (preferably at Initiation Phase). The CD Approvers should typically be familiar with the project, its deliverables, and its governance. The CD Approvers should have a stake or interest in the success of the project and hold the appropriate authority to influence financial, budget, and project governance decisions. A project may have one or more CD Approvers depending on the size, complexity, and/or project governance decision. There may also be different CD Approvers assigned to each CD Review (i.e. CD-2 & CD-3 may require more technically inclined reviewers). CD Package Required deliverables for a particular CD grouped together (in a package). Change Control Board (CCB) Predefined project stakeholders responsible for ensuring proper management of change throughout the project. Members of the CCB should have sufficient knowledge of a project’s requirements and expected outcome (end-product) to recommend the approval or rejection of change requests. Contractor Project Manager Contractor responsible for day-to-day management of the contractor project team. This role may also represent any PM for each distinct IT service (e.g., design, build, and operations/maintenance) reporting to the FPM. Core Elements The IT PEM framework is comprised of four elements which serve as its foundation and infrastructure. The four IT PEM elements are composed of: • Lifecycle Phases • Critical Decision (CD) • Deliverables & CD Packages • Project Stakeholders Cost Refers to the expenditure of funds or use of property to acquire, produce, operate, or maintain an asset. Examples include, but are not limited to: sunk costs, operational costs, acquisition costs, and disposition costs (including variable costs such as labor hours). Critical Decision (CD) Critical Decisions (CDs) are formal stage gates or transition points during a project’s lifecycle where a set of required deliverables are evaluated by “CD approvers” to ensure they were properly completed and accepted. DOE G 415.1-2 Appendix C 12-21-2015 C-3 Term Definition Critical Decision Review Process The Critical Decision Review Process is performed in preparation for all CD reviews (CD-0 to CD-4) to determine readiness for review. During the process, the Project Manager reviews all deliverables to ensure they were appropriately completed and approved. This evaluation promotes the development of quality deliverables and increased probability of project success. The Critical Decision Review Process should be described in the quality assurance section of the Project Management Plan as a means to promote project quality. Cybersecurity The protection of information systems against unauthorized access to or modification of information (whether in storage, processing, or transit), loss of accountability for information and user actions, and the denial of service to authorized users, including those measures necessary to protect against, detect, and counter such threats. Deliverable Tangible and intangible outputs (artifacts and activities) generated throughout the project. Departmental Directives Program Used to establish Directives as the primary means to set, communicate, and institutionalize policies, requirements, responsibilities, and procedures for Departmental Elements and

contractors. Equivalencies and exemptions to this Order are processed in accordance with DOE Order 251.1C, Departmental Directives Program. Design Stage The primary objective is to create a design that satisfies the requirements gathered and agreed during the Planning Phase. Questions move from the previous "what" type questions in the Planning Phase to the "how" type questions. The end result is an approved design of how the proposed solution is to be developed. The “system design document” and the “system requirements review document” are utilized to formalize and document final design. Development Stage Procurement is executed and developers begin to develop the actual system or product. This involves writing any software and building the appropriate architecture. DOE Elements First-tier organizations at Headquarters and in the field that may apply the IT PEM framework for their program and project management endeavors. Appendix C DOE G 415.1-1 C-4 12-21-2015 Term Definition Enterprise Architecture (EA) An EA includes the rules and standards and systems life cycle information to optimize and maintain the environment which the agency wishes to create and maintain through its IT portfolio. An EA should provide a strategy that enables the agency to support its current state and provides a roadmap for transition to its target environment. An EA defines principles and goals and sets a direction on such issues as the promotion of interoperability, open systems, public access, end-user satisfaction, and IT security. The agency should support an EA with a complete inventory of agency information resources including: stakeholders and customers, equipment, systems, services, and funds devoted to information resources management and IT, at an appropriate level of detail. Enterprise-wide IT Projects A project that spans or impacts multiple DOE Elements. Execution Phase This phase includes processes performed to complete the activities (tasks, milestones, deliverables, and artifacts) defined in the Planning Phase. Monitoring and Controlling processes and procedures are also performed to track, review, and regulate the progress and performance of the project. Any changes to the baseline plan may require a formal change control process or as specified in the PMP. Federal Project Manager (FPM) Federal official responsible for the overall success of the project and for reporting to the AE. The FPM oversees the project until project closeout. Federal Sponsor • Federal executive who is ultimately accountable for the project and business need • Sets priorities for the project • Has authority to assign or request project management support • Authorizes the start and end of a project • Approves project artifacts (e.g. Business Case, Project Charter, & Post Implementation Review) • Provides funds for the project • Makes critical project decisions to resolve major conflicts Impact Assessment An evaluation of the impact a stressor (e.g. risk, issue, or change request) would have on a project’s Scope, schedule, cost, or quality. Implementation Stage System or product is implemented and released to all end-users, system documentation is provided to end-users, training is provided to each group of users. Post implementation report is completed to formalize successful completion, sponsor acceptance and sign off. DOE G 415.1-2 Appendix C 12-21-2015 C-5 Term Definition

Information Any communication or representation of knowledge such as facts, data, or opinions in any medium or form, including textual, numerical, graphic, cartographic, narrative, or audiovisual forms. Information System A combination of information, computer, and telecommunications resources; other information technology resources; and personnel resources that collect, record, process, store, communicate, retrieve, and display information. Information Technology (IT) Information technology, as defined by the Clinger-Cohen Act of 1996, sections 5002, 5141, and 5142, means any equipment or interconnected system or subsystem of equipment that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information. For purposes of this definition, equipment is “used” by an Agency whether the Agency uses the equipment directly or it is used by a contractor under a contract with the Agency that (1) requires the use of such equipment or (2) requires the use, to a significant extent, of such equipment in the performance of a service or the furnishing of a product. Information technology includes computers, ancillary equipment, software, firmware, and similar procedures, services (including support services), and related resources. It does not include any equipment that is acquired by a Federal contractor incidental to a Federal contract. Information technology is any proposed acquisition of information technology or information technology-related resources to support a defined business need. Information Technology Project Execution Model (IT PEM) The Information Technology Project Execution Model (IT PEM) is a guide that supports the U.S. Department of Energy (DOE) IT Program and Project Managers (PM) with guidance that may be useful to them in effectively and efficiently implementing the requirements of DOE Order (O) 415.1, Information Technology Project Management, and dated December 3, 2012. Specifically, this Guide provides a suggested formal, structured, and integrated standard approach to managing DOE IT projects and programs. Information Technology Project Execution Model for Small & Medium Projects (Also referred to as simply the SMP) Is a project management guide that delivers an approved, standardized project management approach for use by small and medium sized IT projects. This guide provides a customized adaptation of the Information Technology (IT) Project Execution Model (PEM) Guide, dated July 17, 2014. Appendix C DOE G 415.1-1 C-6 12-21-2015 Term Definition Initiation Phase At this initial phase, the approved (high-level) business case becomes an input and is utilized to develop the Project Charter and identify initial scope. Internal and external Stakeholders (who interact and influence the overall outcome of the project) are identified and documented in the Stakeholder Register. Project Charter approval is obtained and both the project and PM are officially authorized. Initial financial resources are committed. Initiative An initiative is created by an Organization in response to a driver or internal Directives and defines the scope of the Organizational work- efforts performed. Intake Assessment Team Interim team brought together to review new requirements (business needs and objectives) and assess its business and technical feasibility. Will typically include representatives from

Engineering, Operations, Enterprise Architecture (EA), and Cybersecurity. IT Investment Refers to the expenditure of IT resources to address mission delivery and management support. An IT investment may include a project or projects for the development, modernization, enhancement, or maintenance of a single IT asset or group of IT assets with related functionality, and the subsequent operation of those assets in a production environment. All IT investments should have a defined life cycle with start and end dates, with the end date representing the end of the currently estimated useful life of the investment, consistent with the investment’s most current alternatives analysis if applicable. IT Project A planned endeavor funded by an approved information technology investment, thus achieving a specific goal and creating a unique product, service, or result. A project has a defined start and end point with specific objectives that, when attained, signify completion. IT Project Manager (IT PM) An individual in the Headquarters (HQ) Organizational Element responsible for managing a project and its assigned activities. This individual ensures that all the projects are properly phased, funded over time, and that each PM is meeting his/her key milestones. These individuals are the project’s advocates, ensure proper resourcing, and facilitate the execution process. They predict Programmatic risks and put mitigation strategies in place so that projects are not affected. DOE G 415.1-2 Appendix C 12-21-2015 C-7 Term Definition Life Cycle Phases Lifecycle phases are distinct periods in a project’s lifespan. Each period is comprised of tangible and intangible deliverables that upon fulfilling will help advance the project closer towards completion. The PEM Lifecycle Phases include the: Pre- Project, Initiation, Planning, Execution, and Production phases. Maintenance An activity necessary to keep an asset functioning as designed during its operations and maintenance phase of a project. Maintenance costs include costs needed to sustain an IT asset at the current capability and performance levels including: corrective hardware/software, voice and data communications maintenance, replacement of damaged or obsolete IT equipment, and associated overhead costs. Examples of maintenance projects include operating system upgrades, technology refreshes, and security patch implementations. Maintenance Stage The Maintenance Stage occurs after project closure. An “Annual Operational Analysis” is conducted to continuously collect system or product data and monitor and control the system or product’s lifecycle status. When determined that the system or product has reached the end of its lifecycle, proper system disposition is conducted to ensure that a system's components, data, software and hardware are disposed of properly and according to organizational regulations. Vital information is archived and maintained for future business or system needs. Milestone Any significant or substantive point, time, or event of the project. Milestones typically refer to points at which large- schedule events or series of events have been completed, and a new phase(s) is set to begin. Modular Development (or Modularization) This involves dividing a project or investment into smaller parts in order to reduce investment risk, deliver capabilities more rapidly, and permit easier adoption of newer and emerging technologies.

Monitoring and Controlling Refers to the processes and procedures essential to manage project scope, schedule, cost, and quality. Objective This defines the principal areas of concern within the overall goal; it may also provide quantitative measures of future performance and may list several Strategic Targets that provide additional quantification of Agency objectives. Office of the Chief Information Officer (OCIO) The Office responsible to ensure that IT is acquired and information resources are managed consistent with statutory, regulatory, and Departmental requirements and priorities. Appendix C DOE G 415.1-1 C-8 12-21-2015 Term Definition Operation The day-to-day management of an asset in the production environment and included activities to operate data centers help desks, operational centers, telecommunication centers, and end- user support services. Operations costs include the expenses associated with an IT asset that is in the production environment to sustain an IT asset at the current capability and performance levels including Federal and contracted labor costs and the costs for the disposal of an asset. Planning Phase This phase includes processes required to establish the total scope of the project, define key target performance metrics, and ensure that the proposed scope, schedule, and cost baseline are achievable. To accomplish these goals, the PM should develop the project management plan (PMP), collect business – functional requirements, refine objectives, perform risk management, and ultimately baseline the project. Pre-Project Phase An initial Pre-Project Phase is used in the IT PEM framework to ensure that critical pre-project tasks have been considered and/or fulfilled. These critical tasks lay the foundation for the development of the (high-level) business case. An approved (high-level) business case is expected prior to advancing the project to the Initiation Phase and committing federal and contractor resources. Process A permanent or semi-permanent collection of measurable, auditable, and repeatable activities that result in an output. Product Backlog The product backlog (or "backlog") is the requirements for a system, expressed as a prioritized list of product backlog Items. These included both functional and non-functional customer requirements, as well as technical team-generated requirements. Production Phase This phase includes the actual implementation of the system or product in the production environment, the product or system release to production environment, handoff to operations, project closure, and initiation of the Retirement Stage. Program Refers to a group of related projects. Program Management A group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually. Project A project has a defined start and end point with specific objectives that, when attained, signify completion thus achieving a specific goal and creating a unique product, service, or result. Built on interdependent activities planned to meet a common objective, a project focuses on attaining or completing a deliverable within a predetermined cost, schedule, and technical scope. DOE G 415.1-2 Appendix C 12-21-2015 C-9 Term Definition Project Complexity Level (PCL) The PCL leverages the criteria set forth in DOE O 415.1 to distinguish projects based on the following complexity levels:

1) High, 2) Medium, or 3) Low. Project Management Project Management is the discipline of planning, organizing, securing, managing, leading, and controlling resources to achieve specific goals. A project is a temporary endeavor with a defined beginning and end (usually time-constrained, and often constrained by funding or deliverables) undertaken to meet unique goals and objectives, typically to bring about beneficial change or added value. Project Management Plan (PMP) The contractor-prepared document that sets forth the plans, organization, and systems that the contractor will utilize to manage the project. Its content and the extent of detail of the PMP will vary in accordance with the size of the type of project and state of project execution. Project Manager (PM) The person assigned by the performing organization to achieve the project objectives. The SMP utilizes the term Project Manager to refer to both the Federal Project Manager and its supporting Contractor Project Manager. Project Performance The overall measurement of whether a project has met objectives and requirements of scope, cost, and schedule. A periodic measurement during the monitoring and controlling phases of a project performed to observe project execution and identify variances from the Project Management Plan for proactive mitigation. Project Reviews Project reviews are used to brief project stakeholders on the Status of the project. Topics such as accomplishments, planned activities, critical risks, issues, and baseline metrics are typically presented during reviews. Project reviews are also opportunities to obtain management support or their decision on project matters requiring their direction. The communications management section of the Project Management Plan should list and describe all project reviews. Project Team Includes the FPM, CPM, BO, TL, and other federal and contractor resources responsible for developing or approving project deliverables (activities and artifacts) as specified in the Project Management Plan and Project Schedule. Although some representatives may support the project at earlier phases, the Project Team is not <formally> assembled until the project is authorized (Initiation Phase). http://en.wikipedia.org/wiki/Project http://www.pmconnection.com/modules.php?name=Encyclopedia&op=content&tid=221 Appendix C DOE G 415.1-1 C-10 12-21-2015 Term Definition Requirements A singular documented need of what a particular product or service should be or perform. It is a statement that identifies a necessary attribute, capability, characteristic, or quality of a system in order for it to have value and utility to a user. Business requirements describe in business terms what should be delivered or accomplished to provide value. Functional requirements describe the functionality that the system is to execute. Risk Factor, element, constraint, or course of action that introduces an uncertainty of outcome either positively or negatively that could impact project objectives. Risk Management The handling of risks through specific methods and techniques. Effective risk management is an essential element of every project. The DOE risk management concept is based on the principles that risk management should be analytical, forward- looking, structured, informative, and continuous. Risk assessments should be performed as early as possible in the project and should identify critical technical, performance,

schedule, and cost risks. Once risks are identified, sound risk mitigation strategies and actions should be developed and documented. Risk Register The document containing the results of the qualitative risk analysis, quantitative risk analysis, and risk response planning. The risk register details all identified risks, including description, category, cause, probability of occurring, impact(s) on objectives, proposed responses, owners, and current status. The risk register is a component of the project management plan. Schedule A listing of a project's milestones, activities, and deliverables, usually with intended start and finish dates. Those items are often estimated in terms of resource allocation, budget and duration, linked by dependencies and scheduled events. Scope The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions. Solution A comprehensive architectural response to a business problem. Solutions address all layers of EA - strategy, business, data, applications, and technology/security. Sponsoring/Funding Organization The DOE Organization responsible for providing the necessary funding to support the project and project activities. Sprint An iteration of work during which an increment of product functionality is implemented. Iterations typically last +/- 30 days. http://en.wikipedia.org/wiki/Functional_requirements http://en.wikipedia.org/wiki/Functional_requirements http://en.wikipedia.org/wiki/Project http://en.wikipedia.org/wiki/Milestone_(project_management) http://en.wikipedia.org/wiki/Task_(project_management) http://en.wikipedia.org/wiki/Deliverable http://en.wikipedia.org/wiki/Estimation_(project_management) http://en.wikipedia.org/wiki/Resource_allocation http://en.wikipedia.org/wiki/Budget http://en.wikipedia.org/wiki/Duration_(project_management) http://en.wikipedia.org/wiki/Dependency_(project_management) DOE G 415.1-2 Appendix C 12-21-2015 C-11 Term Definition Sprint Planning The Sprint planning meeting is a negotiation between the team and the product owner about what the team will do during the next sprint. Sprint Retrospective The sprint retrospective meeting is held at the end of every sprint after the sprint review meeting. The team meets to discuss what went well and what to improve in the next sprint. Sprint Review Informal meeting held to assess the project against the sprint goal determined during the sprint planning meeting. Stages In addition to the lifecycle phases, the IT PEM also incorporates six project stages which support IT project lifecycle requirements. The PEM Stages include: Design, Development, Testing, Implementation, Closure, and Retirement stages. Stakeholder Individuals and Organizations that are actively involved in the project, or whose interests may be positively or negatively affected as a result of Program execution or completion. They may also exert influence over the Program and its results. System An interconnected set of information resources organized for the collection, processing, maintenance, transmission, and dissemination of information, in accordance with defined procedures, whether automated or manual. Tailoring Tailoring is used to determine which processes and outputs are appropriate, and the degree of rigor that should be applied based on factors such as scope, size, risk, and complexity. Technical Lead Technical subject matter expert (e.g. Systems Architect/System

Owner) who provides solutions to technical challenges facing the project (or proposed project). May be assigned early in the Pre-Project phase to support the Business Owner articulate the business need and business case. Plays a key role in reviewing technical documents, approving technical artifacts, and ensuring the finished product meets the design and technical specifications of their clients. Technical Sponsor • Federal executive accountable for delivering technical solution within an agreed project baseline • Authority to assign technical project management support • Oversees, evaluates, and supports the work and progress of its technical project staff • Makes decisions to resolve major (technical) conflicts • Manages budget within their organization Appendix C DOE G 415.1-1 C-12 12-21-2015 Term Definition Testing Stage Begins after the product or feature has been developed. The test plans developed during the planning phase are utilized to verify that the features or product meets the business requirements. User Acceptance Testing (UAT) and the Operational Readiness Document are utilized as acceptance criteria to ensure the system or product is ready for transition to the Production Phase. Total Project Cost (TPC) All cost planning and implementation specific to a project incurred through the startup of continual operations (capability delivered) but prior to the operation of the facility. Traditional/Waterfall Approach A project management approach whereby each phase or stage must be completed fully before the next phase or stage can begin. Work Breakdown Structure A deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project. Each descending level represents an increasingly detailed definition of the project work. The WBS is decomposed into work packages. The deliverable orientation of the hierarchy includes both internal and external deliverables. Working Group Inter-disciplinary group designated by the IPT to carry out the development of a task, analysis, or deliverable. The Working Group does not make decisions but reports directly to the IPT or FPM. DOE G 415.1-2 Appendix D 12-21-2015 D-1 APPENDIX D: DESCRIPTION OF PROJECT ARTIFACTS Alternatives Analysis: A document that details the analysis of alternatives, which is a detailed study and assessment of the various options available for the purpose of selecting one for implementation. Ideally, all feasible alternatives should be investigated. Annual Operational Analysis (AOA): Combines elements from the Capital Planning and Investment Control (CPIC) evaluation and results from monitoring the performance of the Business Product during normal operations against original user requirements and any newly implemented requirements or changes. This document assists in the analysis of alternatives for deciding on new functional enhancements and/or modifications to the business product, or the need to dispose of or replace the business product altogether. Business Case: A formal, written argument intended to convince a decision maker to approve a project, initiative, or action. A well-crafted business case explores all feasible approaches to a given problem and enables business owners to select the option that best serves the organization.

In addition to the written argument, a Business Case should also include a list of the business requirements, an alternative cost analysis, forecasted cost if implemented, forecasted cost if not implemented, return on investment, and other essential data prescribed by internal and external federal organizations. Change Control Log: A record of requests for changes submitted to a project. A change control log tracks the progress of each change from submission through review, approval, implementation and closure. The log can be managed manually by using a document or spreadsheet or it can be managed automatically with a software or Web-based tool. Enterprise Architecture Worksheet: Provides a valuable opportunity to review all the architecture documents to prevent duplication and redundancies, reduce cost, minimize risk, increase interoperability, increase security, enhance collaboration, and to ensure the project is aligned to the DOE’s future Enterprise Architecture and enterprise roadmap. In addition, the Architecture Review ensures that all IT investments provide value to DOE’s strategic goals by engaging the business owners and the Chief Architect as an interactive event prior to the Critical Decision (CD)-0, Approve Project Charter and Critical Decision (CD)-1. Design Document: A document that defines the architecture, components, modules, interfaces, and data for a system to satisfy specified requirements. Implementation Plan: Describes how the project will be implemented, approach, dependencies for implementation, and outlines specific requirements which must be met to successfully transition the project (or its system, product, or feature) to production teams. Post Implementation Report. A document used to evaluate the effectiveness of the IT solution that was implemented in the production environment. The objectives are to determine if the IT solution: does what it is designed to do; supports the user in an effective and efficient manner as required; is successful in terms of functionality, performance, and cost versus benefits. The results of the report can be used to strengthen the IT solution as well as procedures. For IT Appendix D DOE G 415.1-1 D-2 12-21-2015 systems, post implementation review typically occurs after the system has been in production for a period of time (normally 6 months). Production Readiness Report (PRR): Provides evidence that the project (system, product, or feature) is ready for production. Evidence typically involves validating the successful development and testing of approved final design and requirements. This report is presented to appropriate approving stakeholders at conclusion of testing stage. Production Readiness Review approval is required prior to CD-3 review and before moving into Production Phase. Project Charter: Authorizes the existence of a project, and provides the PM with the authority to apply organizational resources to project activities. This document also embeds the Project Scope Statement which is the narrative description of the project scope, including major deliverables, project assumptions, project constraints, and a description of work that provides a documented basis for making future decisions and for confirming or developing a common understanding of project scope among the stakeholders. A milestone project schedule is also included in the project charter. Project Closure Report: A document which formalizes the closure of a project. The Project

Closure Report provides confirmation that the criteria for customer acceptance have been met and requests sign-off from the Federal Sponsor to close the project. Project Management Plan (PMP): The Project Management Plan is a dynamic formal approved document that defines how the project is executed, monitored and controlled. It may be summary or detailed and may be composed of one or more subsidiary management plans and other planning documents. The main objective of the PMP is to document assumptions and decisions for how the project is to be managed, to help in communication between all of the concerned parties and to document the scope, costs and time sequencing of the project. Project Schedule (Detail Project Schedule): The planned dates for performing schedule activities and the planned dates for meeting schedule milestones. The Project Schedule may also be referred to as the Integrated Master Schedule (IMS), which is a network of tasks linked from program start through program finish, reflecting the interdependencies between tasks and milestones. Requirements Document: Progressively captures and documents a project’s business objectives and its requirements (Business, Non-Functional, Functional, and Technical). The Requirements document may be completed in conjunction with a Requirements Traceability Matrix to ensure all requirements can trace back to original business objectives (avoiding scope creep). Requirements Traceability Matrix (RTM): A table used to document the life of a requirement and providing bi-directional traceability between various associated requirements. It enables users to find the origin of each requirement and track every change that was made to this requirement. Risk Register: A document containing the results of the qualitative risk analysis, quantitative risk analysis, and the risk response planning. The Risk Register details all identified risks, DOE G 415.1-2 Appendix D 12-21-2015 D-3 (and D-4) including description, category, cause, probability of occurring, impact(s) on objectives, proposed responses, owners, and current status. Test Plan: A document defines the types of tests (e.g. unit, function, integration, system, security, performance (load and stress), regression, user acceptance, and/or independent verification and validation) to be carried out. The document describes the acceptance criteria for those tests, roles and responsibilities of individuals involved in the testing process, traceability matrix, resources required (hardware and software environments), and other elements relevant to test planning and execution. This plan details the manner of testing (test cases, simulation, etc.) of the integrated software/hardware system. It should include as part of the main document or as a separate document detailed Test Case Specifications that describe the purpose and manner of each specific test, the required inputs and expected results for the test, step-by-step procedures for executing the test, and the pass/fail criteria for determining acceptance. Training Plan: A document that describes the overall goals, learning objectives, and activities that are to be performed to develop, conduct, control, and evaluate instructions that are to be provided to users, operators, administrators, and support staff who will use, operate, and/or otherwise support the solution. Work Breakdown Structure (WBS): A deliverable-oriented hierarchical decomposition of the

work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project. DOE G 415.1-2 Appendix E 12-21-2015 E-1 APPENDIX E: REFERENCES 1 DOE O 415.1 Information Technology Project Management, dated December 3, 2012. 2 DOE, Secretary Delegation Order No. 00-031.00A, dated June 7, 2007. 3 DOE CIO Memorandum, Enterprise Architecture Guidance, dated January 9, 2007. 4 DOE G 413.3-2, Quality Assurance Guide for Project Management, dated June 27, 2008. 5 DOE G 413.18-A, Integrated Project Team Guide for Formation and Implementation, dated February 3, 2012. 6 DOE O 200.1A, Information Technology Management, dated December 23, 2008. 7 DOE O 205.1B, Department of Energy Cybersecurity Management Program, dated May 16, 2011. 8 DOE O 243.1B, Records Management Program, dated March 11, 2013. 9 DOE O 413.1B, Internal Control Program, dated October 28, 2008. 10 DOE O 413.3B, Program and Project Management for the Acquisition of Capital Assets, dated November 29, 2010. 11 DOE O 414.1D, Quality Assurance, dated April 25, 2011. 12 Executive Order 13011, Federal Information Technology, FR 61-140, dated July 19, 1996. 13 Government Accountability Office (GAO) Report – GAO-11-826, OMB Needs to Improve Its Guidance on IT Investments, dated September 29, 2011. 14 Office of Science, Definition of a User Facility Memorandum, dated January 6, 2012. 15 OMB Circular A-11, Preparation, Submission and Execution of the Budget, dated August 18, 2011. 16 OMB Circular A-123, Management Accountability and Control, dated December 21, 2004. 17 OMB Circular A-127, Financial Management Systems, dated January 9, 2009. 18 OMB Circular A-130, Management of Federal Information Resources, dated November 28, 2000. 19 OMB Memorandum M-00-07, Incorporating and Funding Security in Information Systems Investments, dated February 28, 2000. https://www.directives.doe.gov/directives/0413.3-EGuide-02 https://www.directives.doe.gov/directives/0413.3-EGuide-02 https://www.directives.doe.gov/directives/0413.3-BOrder-b/view Appendix E DOE G 415.1-1 E-2 12-21-2015 20 DOE O 475.2B, Identifying Classified Information, dated October 3, 2014. 21 OMB Memorandum M-11-29, Chief Information Officer Authorities, dated August 8, 2011. 22 OMB Memorandum M-97-02, Funding Information Systems Investments, dated October 25, 1996. 23 The Clinger-Cohen Act of 1996, (CCA), (Public Law 104-106, Division E), dated February 10, 1996. 24 The E-Government Act of 2002, (Public Law 107-347), dated December 17, 2002. 25 The Federal Acquisition Streamlining Act of 1994, Title V (FASA V), dated October 13, 1994. 26 The Federal Information Security Management Act (FISMA) of 2002, dated October 24, 2002. 27 The Government Information Security Reform Act (GISRA - 2000), dated October 30, 2000. 28 The Government Paperwork Elimination Act of 1998, (Public Law 105-277, Title XVII), dated October 21, 1998. 29 The Government Performance and Results Act of 1993 (GPRA) (Public Law 103-62), dated August 3, 1993. 30 The Paperwork Reduction Act of 1995, (Public Law 104-13), dated May 22, 1995. 31 The President’s Management Agenda, Office of Management and Budget, Fiscal Year 2002, dated January 29, 2001. 32 Federal Acquisition Regulation (FAR), General Services Administration, Department of Defense, and National Aeronautics and Space Administration, dated March 2005.

33 25 Point Implementation Plan to Reform Federal Information Technology Management, U.S. Chief Information Officer, dated December 9, 2010. 34 Contracting Guidance to Support Modular Development, U.S. Chief Information Officer, dated June 14, 2012. 35 Project Execution Model (PEM), National Nuclear Security Administration (NNSA) Office of the Chief Information Officer, dated September 2009. 36 Information Technology Project Execution Model, dated July 17, 2014. 37 “Glossary of Scrum Terms” Scrumalliance.org, 12 March 2007 DOE G 415.1-2 Appendix E 12-21-2015 E-3 (and E-4) 38 Headquarters Program Cyber Security Plan (PCSP), dated March 12, 2013 39 Standardized Object Class Codes and Definitions, Office of the Chief Financial Officer, dated February 14, 2013 40 DOE O 475.2B, Identifying Classified Information, dated 10-03-14 41 10 CFR Part 1017, Identification and Protection of Unclassified Controlled Nuclear Information 42 DOE O 471.1B, Identification and Protection of Unclassified Controlled Nuclear Information, dated March 1, 2010 43 O 471.3, Identifying and Protecting Official Use Only Information, Admin Change 1, dated January 13, 2011 44 DOE M 471.3-1, Manual for Identifying and Protecting Official Use Only Information, Admin. Change 1, January 13, 2011 Project Execution Model Guide for Small and Medium Projects FOREWORD 1 Introduction 2 Background 3 Scope 4 Framework 4.1 Critical Decision (CD) Review Process 4.1.1 Deliverables & CD Packages 4.1.2 CD Review Process 4.2 Core Elements 4.2.1 Lifecycle Phases & Stages 4.2.1.1 Pre-Project Phase 4.2.1.2 Initiation Phase: 4.2.1.3 Planning Phase: 4.2.1.3.1 Performance Measurement Baseline*: 4.2.1.4 Execution Phase: 4.2.1.4.1 Design Stage: 4.2.1.4.2 Development Stage: 4.2.1.4.3 Testing Stage: 4.2.1.5 Production Phase 4.2.1.5.1 Implementation Stage: 4.2.1.5.2 Project Closure Stage: 4.2.1.5.3 Maintenance Stage: 4.3 SMP Essential Artifacts 4.4 Key Project Stakeholders 5 Monitoring & Controlling 5.1.1 Risk Management 5.1.2 Change Control Management 5.1.3 Work Breakdown Structure & Schedule Management 5.1.3.1 Work Breakdown Structure 5.1.3.2 Schedule Management 5.1.3.3 High-Level Schedule 5.1.3.4 Milestone Schedule 5.1.3.5 Detail Project Schedule 5.1.4 Project Reviews 5.1.5 Project Cost Tracking 6 Modular & Agile Approach 6.1 SMP Modular Workflow 6.2 SMP Agile Workflow 7 Tailoring Opportunities APPENDIX A: ACRONYMS APPENDIX B: OCIO RESOURCES AND DEPARTMENTAL REQUIREMENTS APPENDIX C: GLOSSARY APPENDIX D: DESCRIPTION OF PROJECT ARTIFACTS APPENDIX E: REFERENCES 1 DOE O 415.1 Information Technology Project Management, dated December 3, 2012. 2 DOE, Secretary Delegation Order No. 00-031.00A, dated June 7, 2007. 3 DOE CIO Memorandum, Enterprise Architecture Guidance, dated January 9, 2007. 4 DOE G 5 DOE G 6 DOE O 200.1A, Information Technology Management, dated December 23, 2008. 7 DOE O 205.1B, Department of Energy Cybersecurity Management Program, dated May 16, 2011. 8 DOE O 243.1B, Records Management Program, dated March 11, 2013. 9 DOE O 413.1B, Internal Control Program, dated October 28, 2008. 10 DOE O 413.3B, 11 DOE O 414.1D, Quality Assurance, dated April 25, 2011. 12 Executive Order 13011, Federal Information Technology, FR 61-140, dated July 19, 1996. 13 Government Accountability Office (GAO) Report – GAO-11-826, OMB Needs to Improve Its Guidance on IT Investments, dated September 29, 2011.

14 Office of Science, Definition of a User Facility Memorandum, dated January 6, 2012. 15 OMB Circular A-11, Preparation, Submission and Execution of the Budget, dated August 18, 2011. 16 OMB Circular A-123, Management Accountability and Control, dated December 21, 2004. 17 OMB Circular A-127, Financial Management Systems, dated January 9, 2009. 18 OMB Circular A-130, Management of Federal Information Resources, dated November 28, 2000. 19 OMB Memorandum M-00-07, Incorporating and Funding Security in Information Systems Investments, dated February 28, 2000. 20 DOE O 475.2B, Identifying Classified Information, dated October 3, 2014. 21 OMB Memorandum M-11-29, Chief Information Officer Authorities, dated August 8, 2011. 22 OMB Memorandum M-97-02, Funding Information Systems Investments, dated October 25, 1996. 23 The Clinger-Cohen Act of 1996, (CCA), (Public Law 104-106, Division E), dated February 10, 1996. 24 The E-Government Act of 2002, (Public Law 107-347), dated December 17, 2002. 25 The Federal Acquisition Streamlining Act of 1994, Title V (FASA V), dated October 13, 1994. 26 The Federal Information Security Management Act (FISMA) of 2002, dated October 24, 2002. 27 The Government Information Security Reform Act (GISRA - 2000), dated October 30, 2000. 28 The Government Paperwork Elimination Act of 1998, (Public Law 105-277, Title XVII), dated October 21, 1998. 29 The Government Performance and Results Act of 1993 (GPRA) (Public Law 103-62), dated August 3, 1993. 30 The Paperwork Reduction Act of 1995, (Public Law 104-13), dated May 22, 1995. 31 The President’s Management Agenda, Office of Management and Budget, Fiscal Year 2002, dated January 29, 2001. 32 Federal Acquisition Regulation (FAR), General Services Administration, Department of Defense, and National Aeronautics and Space Administration, dated March 2005. 33 25 Point Implementation Plan to Reform Federal Information Technology Management, U.S. Chief Information Officer, dated December 9, 2010. 34 Contracting Guidance to Support Modular Development, U.S. Chief Information Officer, dated June 14, 2012. 35 Project Execution Model (PEM), National Nuclear Security Administration (NNSA) Office of the Chief Information Officer, dated September 2009. 36 Information Technology Project Execution Model, dated July 17, 2014. 37 “Glossary of Scrum Terms” Scrumalliance.org, 12 March 2007 38 Headquarters Program Cyber Security Plan (PCSP), dated March 12, 2013 39 Standardized Object Class Codes and Definitions, Office of the Chief Financial Officer, dated February 14, 2013 40 DOE O 475.2B, Identifying Classified Information, dated 10-03-14 41 10 CFR Part 1017, Identification and Protection of Unclassified Controlled Nuclear Information 42 DOE O 471.1B, Identification and Protection of Unclassified Controlled Nuclear Information, dated March 1, 2010 43 O 471.3, Identifying and Protecting Official Use Only Information, Admin Change 1, dated January 13, 2011 44 DOE M 471.3-1, Manual for Identifying and Protecting Official Use Only Information, Admin. Change 1, January 13, 2011