DOE G 415.1-1, Information Technology Project Execution Model Guide

DOE G 415.1-1 7-17-2014 INFORMATION TECHNOLOGY PROJECT EXECUTION MODEL GUIDE [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-1 i (and ii) 7-17-2014 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 in support of DOE O 415.1, Information Technology Project Management, dated 12-03-2012. This Guide assists IT Program and Project Managers in effectively managing and applying sound project management to IT projects subject to that order. This Guide leverages key project management and information technology concepts from the Federal Government and industry, focused on guiding the activities of key project stakeholders throughout a standard project management lifecycle. 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 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-1 iii 7-17-2014 Contents FOREWORD ................................................................................................................................... i 1 INTRODUCTION................................................................................................................. 1 1.1 Purpose ............................................................................................................................. 1 1.2 Background ...................................................................................................................... 1 1.3 Applicability and Exclusions ........................................................................................... 2 2 INFORMATION TECHNOLOGY PROJECT EXECUTION MODEL ........................ 3 2.1 Methodology .................................................................................................................... 3 2.1.1 PMBOK® Guide ....................................................................................................... 3 2.1.2 ITIL v3 ...................................................................................................................... 3 2.1.3 System Engineering .................................................................................................. 4 2.1.4 Federal Organizations ............................................................................................... 4 2.1.5 Government wide or Departmental Requirements ................................................... 4 2.2 IT PEM Framework ......................................................................................................... 6 2.3 IT PEM Elements ............................................................................................................. 7

2.3.1 Lifecycle Phases & Stages ........................................................................................ 8 2.3.2 Critical Decision (CD) ............................................................................................ 13 2.3.3 Deliverables and CD Packages ............................................................................... 14 2.3.4 Project Stakeholders................................................................................................ 15 2.4 Quality Management ...................................................................................................... 19 2.4.1 Critical Decision (CD) Review ............................................................................... 19 2.4.2 Independent Reviews (IR) ...................................................................................... 20 2.4.3 Quarterly Project Reviews (QPR) ........................................................................... 21 2.5 Risk Management ........................................................................................................... 21 2.6 Change Control Management......................................................................................... 24 3 KEY PROJECT MANAGEMENT PRINCIPLES .......................................................... 26 3.1 Project Complexity Level (PCL).................................................................................... 26 3.2 Tailoring ......................................................................................................................... 28 3.3 Agile or Modular Development ..................................................................................... 29 3.3.1 Agile or Modular Development Using the IT PEM................................................ 30 4 TEMPLATES & ARTIFACTS ......................................................................................... 33 4.1 Project Management Templates and Artifacts ............................................................... 33 5 IT PEM Framework at a Glance ....................................................................................... 35 iv DOE G 415.1-1 7-17-2014 6 INFORMATION TECHNOLOGY PROJECT MODEL BY PHASE .......................... 37 6.1 Pre-Project Phase: .......................................................................................................... 37 6.2 Initiation Phase: .............................................................................................................. 38 6.3 Planning Phase: .............................................................................................................. 38 6.4 Execution Phase: ............................................................................................................ 39 6.5 Production Phase ............................................................................................................ 40 APPENDIX A ................................................................................................................................. 1 APPENDIX B ................................................................................................................................. 1 GLOSSARY ................................................................................................................................... 1 APPENDIX C ................................................................................................................................. 1

ACRONYMS .................................................................................................................................. 1 APPENDIX D ................................................................................................................................. 1 REFERENCES ............................................................................................................................... 1 APPENDIX E ................................................................................................................................. 1 DESCRIPTION of PROJECT ARTIFACTS.................................................................................. 1 DOE G 415.1-1 v (and vi) 7-17-2014 Figures Figure 1: IT PEM Framework Alignment with Other Methodologies ........................................... 5 Figure 2: IT PEM Framework in a Program Management Environment ...................................... 6 Figure 3: IT PEM Elements ............................................................................................................ 7 Figure 4: Deliverables, CD Package, and CD Review ................................................................ 14 Figure 5: Project Stakeholders and their Communication Paths ................................................. 17 Figure 6: IT PEM Monitoring & Controlling............................................................................... 18 Figure 7: Critical Decision Review Process ................................................................................ 20 Figure 8: Probability and Impact Analysis (Sample Only) .......................................................... 22 Figure 9: Change Control Management Process ......................................................................... 25 Figure 10: Decision Tree for Determining PCL & IT PEM Applicability ................................... 27 Figure 11: IT PEM Tailoring ....................................................................................................... 28 Figure 12: IT PEM Agile & Modular Development ..................................................................... 30 Figure 13: CD-2 & CD-3 Combined ............................................................................................ 31 Figure 14: CD-2 and CD-3 applied for each module or iteration ............................................... 32 Figure 15: Pre-Project Phase ....................................................................................................... 37 Figure 16: Initiation Phase Artifact Workflow ............................................................................. 38 Figure 17: Planning Phase Artifact Workflow ............................................................................. 38 Figure 18: Execution Phase Artifact Workflow (CD-2) ............................................................... 39 Figure 19: Execution Phase Artifact Workflow (CD-3) ............................................................... 39 Figure 20: Production Phase Artifact Workflow .......................................................................... 40 Tables

Table 1: Lifecycle Phases & Stages ................................................................................................ 8 Table 2: IT PEM Critical Decision (CD) ..................................................................................... 13 Table 3: Roles and Responsibilities .............................................................................................. 15 Table 4: Independent Reviews for Critical Decisions .................................................................. 21 Table 5: Risk Management ........................................................................................................... 22 Table 6: Change Control Management ........................................................................................ 24 Table 7: Determining Project Complexity Level .......................................................................... 26 Table 8: Illustration of the “IT PEM Artifact Matrix” ................................................................. 34 Table 9: IT PEM Framework at a Glance .................................................................................... 36 DOE G 415.1-1 1 7-17-2014 1 INTRODUCTION 1.1 Purpose The purpose of the Information Technology (IT) Project Execution Model (PEM) Guide is to provide 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, dated December 3, 2012. Specifically, this Guide provides a suggested formal, structured, and integrated standard approach to managing DOE IT projects and programs. This Guide describes acceptable, non-mandatory guidelines for meeting requirements contained in DOE regulations and directives. This Guide provides flexible guidance that is intended to help DOE organizations effectively manage and apply sound project management practices to IT projects and initiatives. 1.2 Background DOE O 415.1 was developed to establish common IT project management principles which would help ensure that IT projects are delivered within the defined performance baseline, cost, and schedule and fully meet mission performance, safety, safeguards, and security standards in alignment with Section 5123 of Public Law (P.L.) 104-106, Performance and Results Based Management. Additionally, DOE O 415.1 requires that all IT projects apply a formal and structured project management approach that is acceptable to the sponsoring/funding organization. This Guide provides a suggested formal and methodical progression of best practices for IT project management which should: • Assist in delivering consistent IT projects within defined scope, schedule and cost baselines; • Help to establish accountability and reporting among the sponsor, project staff and various project key stakeholders; • Assist in facilitating cross-functional and cross-organizational communication, coordination, and collaboration; • Assist in providing overarching accountability and oversight of an IT program or project, ensuring that it meets mission expectations from a program management perspective; • Assist in integrating systems engineering activities with cybersecurity governance, IT governance and management practices that are scalable and repeatable from a project management perspective; and • Address Digital Government Strategy and Clinger-Cohen Requirements

2 DOE G 415.1-1 7-17-2014  Note: The terms [Program] and [Program Management] are utilized throughout this guide to mean, “A group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually.1” 1.3 Applicability and Exclusions This Guide applies to all DOE organizational elements, including NNSA organizational elements, with IT projects that are subject to DOE O 415.1. For simplicity, “DOE” as used throughout this Guide, includes all DOE organizational elements. IT projects covered by DOE O 415.1 include projects: • With a Total Project Cost (TPC) equal to or more than $25 Million (M); • With an impact on more than one DOE Element; or • As determined by the Under Secretary or Head of Element based on mission, priorities, risk management or national interest. DOE O 415.1 requires that all IT projects that do not meet the scope of the order are encouraged to use the project management principles and guidelines, as applicable to the scale of the project and as required/requested by the sponsoring/funding organization. The Project Management Institute (PMI) Project Management Body of Knowledge (PMBOK® Guide) – Fifth Edition, defines a project as, “A temporary endeavor undertaken to create a unique product, service, or result1”. The temporary nature of projects indicates a definite beginning and end. The end is reached when the project’s objectives have been achieved or when the project is terminated because its objectives will not or cannot be met, or when the need for the project no longer exists. Furthermore, the PMBOK® defines project management as, “the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements1”. This Guide provides a best practice project management approach that allows for flexibility to accommodate the unique circumstances (e.g., size, cost, duration, complexity, acquisition strategy, systems engineering methodology, etc.) of any IT program or project. The sponsoring/funding organization of the IT project has the flexibility to determine the appropriate rigor of project management application (i.e., application of this Guide) and apply accordingly.  Note: DOE O 415.1 Applicability & Exclusions criteria for projects are different than the criteria used for CPIC investments. Project teams are advised to reference the latest Capital Planning and Investment Control (CPIC) documentation (i.e. DOE Guide to IT Capital Planning and Investment Control) or contact CPIC team at DOE.CPICMailbox@hq.doe.gov for specific updates to the investment levels, cost thresholds, and specific DOE and Office of Management and Budget requirements. 1 A Guide to the Project Management Body of Knowledge (PMBOK® Guide)-Fifth Edition mailto:DOE.CPICMailbox@hq.doe.gov DOE G 415.1-1 3 7-17-2014 2 INFORMATION TECHNOLOGY PROJECT EXECUTION MODEL This Guide delivers the guidance to implement the requirements for DOE as defined in DOE O 415.1. It provides a standard approach to manage DOE projects and programs by setting the foundation for a common project management language, consistency in project execution, and continuous improvement. Through standardization we can improve project and program understanding, communication, reporting, measurability, and most important, proper and timely decision making across the DOE. This guide integrates project management, information technology, and governance processes into a common framework known as the “IT PEM.”

2.1 Methodology The IT PEM framework leverages methodologies and principles from the following areas: • PMI and its PMBOK® Guide-Fifth Edition2 • Information Technology Infrastructure Library (ITIL) v3 • DOE Systems Engineering Methodology (SEM) • Federal Organizations (Internal & External to DOE) • Government wide or Departmental Directives and Policies 2.1.1 PMBOK® Guide1 The IT PEM framework incorporates project management guidelines in accordance with PMI’s PMBOK® Guide2. Similar to the PMBOK® Guide’s “Process Groups”, the IT PEM lifecycle phases are seldom discrete or one-time events. Instead, the IT PEM lifecycle phases are overlapping activities that occur throughout the project. The output of one activity generally becomes an input to another or a project deliverable. Section 2.3.1: Lifecycle Phases & Stages in this guide describes the IT PEM lifecycle phases in greater detail. To support specific DOE and IT lifecycle requisites, the IT PEM emphasizes a “Pre-Project” and a “Production” phase which align to portions of the PMBOK® Guide’s Initiating, Executing, and Closing Process Groups. Figure 1: IT PEM Framework Alignment with Other Methodologies provides a high-level illustration of the IT PEM lifecycle phases and its alignment to the PMBOK® process groups. 2.1.2 ITIL v3 The IT PEM references ITIL v3 to align with an IT industry standard that is customer focused, promotes measurability, and continuous improvement of its processes and procedures. The ITIL complements the IT PEM by providing an IT focused approach that may not be attained by a traditional project management methodology alone. "ITIL provides guidance on the provision of quality services and project management provides guidance on planning, organizing, and executing projects. Their similarities drive synergy in the delivery of projects and services by IT 2 A Guide to the Project Management Body of Knowledge (PMBOK® Guide)-Fifth Edition 4 DOE G 415.1-1 7-17-2014 to the business -- and the greatest value is not realized by one or the other process, but by the integration of the whole.3" 2.1.3 System Engineering The IT PEM framework emphasizes key system engineering principles from the DOE Systems Engineering Methodology (SEM) Version 3, dated September 2002. The SEM was derived from the principles and standards advocated by information management industry leaders, such as the Institute of Electrical and Electronics Engineers (IEEE) and the Carnegie Mellon Software Engineering Institute (SEI). SEM principles such as guidelines on “Project Size” and the SEM “Information Systems Lifecycle Stages” are examples of principles leveraged from the SEM methodology. Figure 1: IT PEM Framework Alignment with Other Methodologies provides a high-level illustration of the IT PEM lifecycle phases and its alignment with the SEM Lifecycle Stages. 2.1.4 Federal Organizations The IT PEM leverages various IT project management methodologies from internal organizations such as the NNSA, the Office of Environmental Management (EM), and external organizations such as the Department of Health and Human Services (HHS) and the Executive Office of the President (EOP). 2.1.5 Government wide or Departmental Requirements The IT PEM integrates into its methodology Government-wide and/or Department requirements for information management. In addition to supporting DOE O 415.1, the PEM strives to capture and support essential deliverables from CPIC, Configuration Management (CM), Cybersecurity, Enterprise Architecture (EA), Quality Assurance (QA), Records Management (RM), Safety and Safeguards (S&S), and System Engineering.

3 Rivard, E., & Smith, K. (2010, November 18) Integrating ITIL with IT Project Management Improves Both. IT Business Edge. Retrieved from: http://www.itswatch.com. DOE G 415.1-1 5 7-17-2014 Figure 1: IT PEM Framework Alignment with Other Methodologies  Note: The term [Essential Artifact] is utilized throughout this guide to mean Project management artifacts essential to maintain and/or support federal approaches towards strategy, business, security, and technology.  Note: The term [Deliverable] is utilized throughout this guide to mean both tangible and intangible activities and artifacts.  Note: The term [Monitoring & Controlling] is utilized throughout this guide to imply the essential processes and procedures to manage project scope, schedule, cost, and quality. 6 DOE G 415.1-1 7-17-2014 2.2 IT PEM Framework The IT PEM framework provides for a formal, structured, integrated, and standard approach to managing DOE IT projects and programs while allowing for flexibility to meet the unique needs, principles, and environmental factors of each DOE Element. DOE Elements are first-tier organizations at Headquarters and in the field who may apply the IT PEM framework for their program and project management endeavors. Figure 2: IT PEM Framework in a Program Management Environment illustrates the IT PEM framework in a program management environment. The illustration depicts how a standard framework (such as the IT PEM) can provide the methodology and structure to more systematically monitor and control the alignment and synchronization of multiple projects across the DOE. Figure 2: IT PEM Framework in a Program Management Environment DOE G 415.1-1 7 7-17-2014 2.3 IT PEM 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 & Stages • Critical Decision (CD) • Deliverables & CD Packages • Project Stakeholders These elements work in concert to deliver a standard that promotes uniformity, measurability, lessons learned, and continuous process improvement. Figure 3: IT PEM Elements provides a high-level illustration of all four elements within the IT PEM framework. Figure 3: IT PEM Elements 8 DOE G 415.1-1 7-17-2014 2.3.1 Lifecycle Phases & Stages Lifecycle phases and stages 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. Applying these distinct periods helps by providing a standard structure for DOE projects to follow and improve deliverable compliance, better alignment and synchronization with other projects, and improved (standardized) project reporting. The IT PEM utilizes one preliminary “Pre-Project Phase” and four official project management phases which include Initiation, Planning, Execution, and Production. In addition, the IT PEM incorporates six project management stages which support an IT project management lifecycle development. Monitoring and controlling is conducted at all IT PEM lifecycle phases and stages. Section 3.0: Monitoring and Controlling in this guide describes the Monitoring and Controlling processes applied in the IT PEM framework. Table 1: Lifecycle Phases & Stages describes the IT PEM lifecycle phases and their appropriate stages in greater detail. Table 1: Lifecycle Phases & Stages Lifecycle Phases Activity 0) 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 prior to advancing to the Initiation Phase and committing further federal and contractor resources. The Pre-Project Phase is typically championed by the business organization (or the designated business owner) who is requesting a business need and/or objectives. An approved Business Case or appropriate sponsor approval to initiate a new project becomes the major milestone in the Pre-Project Phase. The following list outlines some essential tasks which should be considered and fulfilled during the Pre-Project Phase. • Obtain sponsorship • Identify strategic alignment • Consider shared services • Perform high level alternatives analysis • Complete & Submit “Pre-project Architecture Worksheet” • Perform Rough Order of Magnitude (ROM) analysis • Perform cost benefit analysis • Determine Project Complexity Level (PCL) • Determine program or portfolio management considerations • Develop the Business Case • Submit Business Case • Obtain Business Case approval • Assign project to appropriate Federal Sponsor • Federal Sponsor assigns Federal Project Manager 1) Initiation Phase At the Initiation Phase, the approved Business Case becomes an input and used by the project manager to complete such tasks and DOE G 415.1-1 9 7-17-2014 Lifecycle Phases Activity deliverables as identifying initial scope and development of the Project Charter. An initial risk assessment should be conducted and included with the Project Charter. Security requirements and risks should be determined and captured in the requirements and initial risk assessment sections of the Project Charter (It is recommended that the Project Manager seek the appropriate documentation and guidance from the respective security organization).At the end of the Initiation Phase, a sponsor approved Project Charter will authorize the project and project manager. The following bullets highlight some of the major tasks performed during the Initiation Phase: • Develop the Project Charter o Business Needs & Objectives o Initial Scope (Requirements) o Stakeholder Register o Milestone Schedule o Assumptions & Constraints o Initial Risk Assessment o Initial Cost Estimate • Submit Project Charter • Project Charter Signed/Approved • Commit initial financial resources • Facilitate Quarterly Project Review (As Required) • Independent Review (Optional) • Conduct CD-0 Review 2) Planning Phase At the Planning Phase, the project stakeholders identified at the Initiation Phase are brought together by the project or program manager to support in defining requirements, developing the project plan, and to baseline project Scope, Schedule, and Cost. The project’s Business Owner supports the project manager and team in many facets of the Planning Phase such as helping to capture business and functional requirements, facilitating communication with business stakeholders, and in determining performance metrics and success criteria. The bullets highlight some of the major tasks performed during the Planning Phase: • Collect Business & Functional Requirements • Develop Project Management Plan (PMP) o Scope Management Plan o WBS/Schedule Management Plan o Cost Management Plan o Communications Management Plan o Change Control Management Plan o Risk Management (Plan) o Quality Assurance Plan 10 DOE G 415.1-1 7-17-2014 Lifecycle Phases Activity o (Other as required for specific project)

• Develop Cybersecurity Plan • Develop Alternative Analysis • Submit Project Management Plan • Complete Enterprise Architecture Worksheet • Obtain Chief Architect Approval • Baseline Project Scope • Baseline Cost Performance • Baseline Project Schedule • Define Performance Metrics • Project Management Plan Approval • Perform Change Control Management • Perform Risk Management • Facilitate Quarterly Project Review (As Required) • Independent Review (Optional) • Conduct CD-1 Review 3) Execution Phase: The Execution Phase includes processes performed to complete the activities (tasks, milestones, deliverables, and artifacts) defined in the Planning Phase. Processes are performed to track, review, report, and regulate project progress and performance. Changes to the baseline plan (Scope, Schedule, and Cost) may require a formal change control process as specified in the Change Control Plan or PMP. The Design, Development, and Testing Stages are addressed during the Execution Phase. These stages may be executed within a waterfall or modular/agile approach. The three Execution Phase stages are described: 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 bullets highlight some of the major tasks performed during the Design Stage: • Manage & Communicate Project Progress (Reviews/Reports/Escalations) • Define and Document System Requirements • Perform System Design Review • Design Approval • Perform Change Management • Perform Risk Management • Update PM Documents (As Required) DOE G 415.1-1 11 7-17-2014 Lifecycle Phases Activity • Facilitate Quarterly Project Review (As Required) • Independent Review (Optional) • Conduct CD-2 Review Development Stage: At this stage, procurement is executed and developers begin to develop a prototype of the system, product, or feature in a lab or limited production environment. The Project Manager and project team rely on the Business Owner to help in completing the (business) User Acceptance Test Plan and Training Material by confirming user types, access/licensing, data security, and other test and training logistics. The bullets highlight some of the major tasks performed during the Design Stage: • Manage & Communicate Project Progress (Reviews/Reports/Escalations) • Procure Hardware/Software/Human Resources • Install /Develop System • Complete Training Material • Test Readiness Review & Acceptance • Perform Change Management • Perform Risk Management • Update PM Documents (As Required) Testing Stage: Begins after the system, product, or feature has been developed. The test plans developed during the planning phase are utilized to verify that the system, product, or feature being tested meets the business requirements. The Project Manager and project team rely on the Business Owner to help facilitate the communication and coordination for the business user acceptance testing. The bullets highlight some of the major tasks performed during the Testing Stage: • Manage & Communicate Project Progress (Reviews/Reports/Escalations) • Test Prototype or Lab Environment • Production Readiness Review & Acceptance • Perform Change Management • Perform Risk Management • Update PM Documents (As Required) • Facilitate Quarterly Project Review (As Required) • Independent Review (Optional) • Conduct CD-3 Review

4) Production Phase The Production Phase includes the Implementation, Closure, and Maintenance Stages of the project. The three Production Phase stages are described: 12 DOE G 415.1-1 7-17-2014 Lifecycle Phases Activity Implementation Stage: In this stage, the system, product, or feature is implemented in the production environment. Training is provided to all end-users and a post implementation review is conducted with the Sponsor to evaluate if the implementation fulfilled business requirements and is ready for formal release. The bullets highlight some of the major tasks performed during the Implementation Stage: • Install or Implement in Production Environment • Deliver User Training (Operation, Business, and End-User) • Conduct Post Implementation Review • Obtain Post Implementation Sponsor Acceptance • Perform Change Management • Perform Risk Management • Update PM Documents (As Required) • Facilitate Quarterly Project Review (As Required) Closure Stage: In this stage the project is formally handed-off to operations, business, and/or end-users. All procurement and project management processes are closed. Project artifacts are archived. Final project disposition and status is communicated to stakeholders. The project team is released from the project. The bullets highlight some of the major tasks performed during the Closure Stage: • Formal hand-off to Operations, Business, or End-User • Close PM Processes (Risk, Change Control, etc.) • Close Procurement • Archive PM Artifacts • Communicate Project Closure • Release Project Team • Independent Review (Optional) • Conduct CD-4 Review Maintenance Stage: After the Closure Stage, 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 (retirement), 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. The bullet below highlights the major task performed during the Maintenance Stage: • Perform Annual Operational Analysis DOE G 415.1-1 13 7-17-2014 2.3.2 Critical Decision (CD) Critical Decisions (CDs) are formal stage gates or transition points during a project’s lifecycle where a set of required deliverables (CD Package) are evaluated by CD Approvers to ensure they were properly and fully completed. Approval at a CD Review suggests that the project is both prepared and adequately funded to enter the next phase or stage in the IT PEM lifecycle. Table 2: IT PEM Critical Decision (CD) describes the five CD Reviews used in the IT PEM framework, its respective IT PEM phase, and its descriptive milestones. Table 2: IT PEM Critical Decision (CD) CD CD Title IT PEM Phase Descriptive Milestones CD-0 Approve Project Charter Initiation • Project Charter Approved • Initial Scope Identified CD-1 Approve Performance Measurement Baseline (PMB) Planning • Project Management Plan Approved • Project Baselined (Scope, Schedule, Cost) CD-2 Approve Start of Development Execution • Architecture or System Design Approved • Approval to Begin Development Stage CD-3 Approve Start of Production Execution • Test Readiness Review Approved • Operational Readiness Review Approved

CD-4 Approve Project Closure and Start of Maintenance Stage Production • Post Implementation Review Approved by Sponsor • Formal Hand-Off to Operations, Business, or End-User Completed 2.3.2.1 CD Approvers 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. In addition, 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. The ultimate goal of a CD Approver is to advance a project to its successive phase or stage. 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). A unanimous decision is required from all CD Approvers at each CD review before advancing the project to its successive phase or stage. It is the PM’s responsibility to resolve any CD Review conflict/s to achieve unanimous acceptance. Section 3.1.1: Critical Decision (CD) Review in this guide offers the CD Review process flow as it may be applied in the IT PEM. 14 DOE G 415.1-1 7-17-2014 2.3.3 Deliverables and CD Packages IT PEM deliverables can be both tangible (i.e. artifacts) and intangible (i.e. activities). When deliverables required for a particular CD are grouped together (in a package) they are referred to as a CD Package. Figure 4: Deliverables, CD Package, and CD Review illustrates the composition of a CD package and its progress towards a CD review. A CD Memorandum is an artifact utilized at each CD Review to summarize all the required deliverables and to declare their completed status. Figure 4: Deliverables, CD Package, and CD Review Deliverables required for each of the five CD Packages should be defined by CD-1 as part of the performance measurement baseline milestone. Deliverables introduced beyond CD-1 may require acceptance via a change control process as they may bring about scope, schedule, and/or cost implications which may need to be pre-determined.  Note: Where applicable, the term “Deliverable is utilized in this guide to mean both activities and artifacts.  Note: DOE O 415.1 requires that IT projects implement formal stage gates or transition points during the project’s lifecycle to validate that the project is proceeding as planned and a go, no-go, or hold decision is made.  Note: IT projects may choose to tailor (combine, waive, or modify) CDs as appropriate. It is at the discretion of each project team and their respective governance to determine how to structure the CDs throughout the project lifecycle.  Note: Deviations from the standard PEM framework should still satisfy the intent of each CD (CD-2 through CD-4) and comply with federal and governmental requirements such as Cybersecurity, OMB, and Enterprise Architecture. DOE G 415.1-1 15 7-17-2014 2.3.4 Project Stakeholders Various project stakeholders are utilized throughout the IT PEM framework. The PM should establish, assign, and ensure project team understanding of these roles and their respective responsibilities early in the project lifecycle (i.e. Initiation Phase). Well-defined roles and responsibilities promote proper and timely management of deliverables, processes, reviews, and approvals. Table 3: Roles and Responsibilities lists and describes the typical project stakeholders found in most DOE IT projects.

Table 3: Roles and Responsibilities Roles Responsibilities Executive Sponsor (Mission Owner) Senior Federal Executive who specifies the business need or mission to the Federal Sponsor or to the organizational level. The Executive Sponsor is also responsible for allocating and/or designating the funding for the business need. Business Owner The Business Owner has ultimate responsibility for seeing that the intended benefits are realized to create the value forecast in the business case. The Business Owner represents the business users and serves as part of the Integrated Project Team (IPT). The business owner's job is to help ensure that the end users become satisfied end users and that they understand and anticipate the development and deployment process, appreciate the product's benefits, welcome training, accept the new system and eventually adopt it as their own. The business owner may perform, participate (or lead) the following core activities: • Business Case Development • Business Process & Business Requirements identification • Functional Requirements Development • Business User Acceptance Testing • Business User Training • Quality/Integrity Oversight • Communication (Business Stakeholders & Sponsor) • Achieve Return on Investment Federal Sponsor Federal executive in appropriate level within an organization with the authority to accept and assign project management responsibility. The Federal Sponsor manages the budget within their organization. Enterprise Architecture (EA) An EA includes the rules, 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. Acquisition Executive (AE) The individual designated to integrate and unify the management system for a Program and implement prescribed policies and practices. The Acquisition Executive cannot award or modify contracts, nor commit the Government in any way, without an approved delegation of authority from the Head of the Contracting Activity (HCA) to serve as a Contracting Officer. Contract Officer Individual with authority to enter into, administer, and/or terminate contracts and make 16 DOE G 415.1-1 7-17-2014 Roles Responsibilities (CO) related determinations and findings. The CO (or Contracting Officer representative) is accountable for preparing solicitation documents with technical support from the Federal Project Manager (FPM) and acting on behalf of the Head of the Contracting Activity (HCA). Contract Officer Representative (COR) CORs are qualified individuals appointed by the (CO) to assist in the technical monitoring or administration of a contract. Critical Decision (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). Federal Project Manager (FPM) Federal official with formal project management certification and or training. Responsible for the overall success of the project and for reporting to key project stakeholders. Responsible for the development, maintenance, and implementation of the PMP. Defines, monitors, and reports project cost, schedule, performance, and scope baselines. Manages the CD approval process. Oversees the development of, and provides concurrence with all CD packages. Recommends independent reviews. Ensures compliance and coordination with the OMB-required and DOE-required reporting activities. Contractor Project Manager (CPM) Contractor responsible with supporting the FPM with the day-to-day management of the project. Assists with the development and implementation of the PMP and successor artifacts. Manages assigned project resources. Reports status and performance issues to the FPM. Identifies and remediates risks. Delivers all required documentation to the FPM in a manner conducive to the PMP, Project Schedule, and CD process. Conducts internal reviews and testing activities that ensure the quality of the developed solution. Project Team The Project Team is the group responsible for planning and executing the project. The Project Team members execute their tasks according to the Project Schedule. Their responsibility includes executing tasks and producing deliverables as outlined in the Project Plan and directed by the PM, at whatever level of effort or participation has been defined or assigned to them. Integrated Project Team (IPT) Inter-disciplinary stakeholder group with the specific knowledge, skills, and abilities necessary to support and complement the decision-making process. IPT members may be fully or partially part of the Project Team. The IPT may consist of Federal and contractor staff. Provides advice and recommendations on key project decisions. Facilitates communication between the project and the affected organizations. Facilitates execution of the Capital Planning and Investment Control (CPIC) process, cybersecurity, Enterprise Architecture (EA), and related activities. Assists the FPM in the performance of in-stage and post-stage assessments of project performance. May serve as Subject Matter Expert (SME) in their area of responsibility for the full scope of the project. May support the FPM in other ways, as required and assigned. Prepares and submits reports per the PMP or project schedule. 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 DOE G 415.1-1 17 7-17-2014

Roles Responsibilities the IPT or FPM. Focus Group Technical subgroup designated by the IPT, FPM, or Working Group to carry out the development of a task, analysis, or deliverable. The Focus Group does not make decisions and reports directly to the Working Group. Change Control Board (CCB) The CCB is composed of 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. Independent Reviewer (IR) Individual or group not directly involved with the project but provides the PM with an objective assessment of whether the project is ready for a CD review, and ultimately request approval to proceed to the next phase. Figure 5: Project Stakeholders and their Communication Paths illustrates the relationship between key project management stakeholders and their reporting and collaboration paths. Figure 5: Project Stakeholders and their Communication Paths  Note: The term Project Manager (PM) is utilized throughout this guide to mean both Federal Project Manager (FPM) and Contractor Project Manager (CPM).  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 less or more stakeholders depending on project size, complexity, or specific program office protocol. 18 DOE G 415.1-1 7-17-2014 MONITORING AND CONTROLLING PROCESSES This section of the IT PEM will introduce the processes and reviews utilized throughout the IT PEM framework to manage project scope, schedule, cost, and quality. This section may be utilized as a guide or standard when developing such artifacts as the quality management plan, risk management plan, change control plan, communication plan, and other segments of the PMP. The processes and procedures covered in this section include: • Quality Management • Risk Management • Change Control Management Figure 6: IT PEM Monitoring & Controlling provides a view of the IT PEM framework as it relates to the monitoring and controlling processes and reviews covered in this section. The illustration suggests the order in which each process and reviews may occur in the IT PEM lifecycle. Figure 6: IT PEM Monitoring & Controlling Processes DOE G 415.1-1 19 7-17-2014 2.4 Quality Management The IT PEM promotes three types of project reviews which are essential for building structure and quality into the project. These reviews also set the foundation to facilitate timely and effective decision-making for the project. The three types of reviews covered in this section include the: • Critical Decision (CD) Review • Independent Reviews • Quarterly Project Reviews 2.4.1 Critical Decision (CD) Review As previously defined in Section 2.3.2: Critical Decision (CD), CDs are formal stage gates or transition points during the project’s lifecycle where predefined activities and artifacts (CD Packages) are evaluated to confirm its successful completion. Upon confirmation that the CD package has been successfully completed, the appropriate CD approver/s can agree on advancing the project to the next phase or stage in the IT PEM project lifecycle. The following bullets highlight some of the benefits that can be realized with a sound CD review process:

• Quality deliverables and artifacts; • Increased probability of project success; • Reduced project risk by providing a clear evaluation criteria; • Building quality directly into the project; • Reduced development cycle time, getting it done right the first time and; • Increased focus on a well-designed product or service The CD Review process should be performed in preparation for all CDs (CD-0 to CD-4). The process begins when the PM and project team are ready to confirm that all required deliverables (CD package) for the current phase or stage have been successfully completed. It is at this point when the PM performs the steps shown in the process diagram (Figure 7: Critical Decision Review Process). The PM and project team may also choose to coordinate an “independent review” to determine if the project is prepared for a CD review. Section 3.1.2: Independent Reviews (IR) in this guide describes the independent review process as it may be applied in the IT PEM framework. 20 DOE G 415.1-1 7-17-2014 Figure 7: Critical Decision Review Process  Note: There may be circumstances when the PM and project team agree to proceed to the CD Review with an incomplete CD package (Steps 2a to 2b in diagram). In these circumstances, the PM should assign a risk to the phase prior to proceeding to the CD review. 2.4.2 Independent Reviews (IR) To complement the CD review process, the IT PEM also recommends that PMs coordinate an Independent Review (IR). The reviewer or reviewing party should consist of personnel that have no association with the project being reviewed and has knowledge of Software Quality or Mission Assurance Processes. The IR will provide the PM with an objective assessment of the project status and whether or not the CD package should be submitted for review. The ultimate goal is to request approval to proceed to the next phase. The degree of independence and rigor of the review should be commensurate with the criticality of the project or the CD under review. DOE G 415.1-1 21 7-17-2014 The results of the IR should be documented in an IR report, which would be submitted as part of a CD package. Table 4: Independent Reviews for Critical Decisions summarizes the recommendations for an IR by CD. Table 4: Independent Reviews for Critical Decisions Phase Critical Decision Recommendation for Independent Review* Pre-Project N/A: Approve Business Case Not Required Initiating CD-0, Approve Project Charter Optional – Not Recommended Planning CD-1, Approve Performance Measurement Baseline (PMB) Highly Recommended. Executing CD-2, Approve Start of Development Highly Recommended. CD-3, Approve Start of Production Highly Recommended. Production CD-4, Approve Project Closure and Start of Maintenance Stage Optional – Not Recommended 2.4.3 Quarterly Project Reviews (QPR) One of the most important elements for a successful IT project is effective communication between all key project stakeholders. In conjunction with other reviews specified in the project’s Communications Plan, projects should conduct a Quarterly Project Reviews (QPR) on a routine basis after CD-0. These reviews should continue until the IT project’s solution reaches steady state. The QPR should cover key topics including, but not limited to: • Accomplishments (to date and/or during previous quarter); • Planned activities (until completion and/or planned for next quarter) • Critical risks and issues • Topics that require decision by the Acquisition Executive and other key stakeholders • Measurement of project performance against baseline (metrics)

The QPR should be a management briefing (with any supporting documentation) used by the PM to brief the AE and other key stakeholders on the status of the IT project. 2.5 Risk Management A risk is an event or condition that if it occurs, could have a positive or negative effect on a project’s objectives. The PM working with the project team will ensure that risks are actively identified, analyzed, and managed throughout the life of the project. Risks should be identified as early as possible in the project so as to minimize their probability and potential impact. Figure 8: Probability and Impact Analysis (Sample Only) illustrates a sample criteria and matrix for determining the probability and impact of a particular risk. 22 DOE G 415.1-1 7-17-2014 Figure 8: Probability and Impact Analysis (Sample Only) The probability of risk occurrence can range anywhere from just above 0% to just below 100%. If a risk is guaranteed to occur (100%) then it is no longer a risk but an issue and should be managed using an issue management process. Table 5: Risk Management describes the general process for managing project risk. Table 5: Risk Management Steps Responsible Description Key Artifact 1) Develop The Risk Management Plan Project Manager The Risk Management plan documents how, when, and by who risks are to be identified, addressed and handled. The document is prepared by the PM with inputs from appropriate project stakeholders to ensure alignment on process and risk tolerance levels. Risk Management Plan 2) Identify Risks Risk Creator A risk can be identified by anyone and at any point during the project. PMs should facilitate proactive risk identification sessions with the project team and pertinent stakeholders to identify risks at the beginning of the project, as well as at periodic checkpoints during the project. A Risk Register is utilized to input and track the risks to the project. The Risk Register attempts to characterize all of the risks associated with the project. The document is typically set up in table form (spread sheet). Each risk is characterized by its probability of occurring, the impact it would have on the project, and the steps being taken to address it. Risk Register 3) Risk Analysis Risk Owner Once a risk is identified, it is assigned to a Risk Owner who will assess the probability and impact of the risk if realized. The result of this analysis is used to prioritize the risk and assign it a value or rank (or as specified in the Risk Management Plan). Figure 8: Probability and Impact Analysis (Sample Only) above provides a suggested sample for assigning a probability and impact value to a risk. Risk Register DOE G 415.1-1 23 7-17-2014 Steps Responsible Description Key Artifact 4) Risk Response Planning Risk Owner Once a risk’s probability and impact has been assessed, the following approaches may be selected to address it: • Avoid – Eliminate the threat or condition or to protect the project objectives from its impact by eliminating the cause; • Mitigate – Identify ways to reduce the probability or the impact of the risk; • Accept – Nothing will be done; • Contingency –Define actions to be taken in response to risks; or • Transfer – Shift the consequence of a risk to a third party together with ownership of the response by making another party responsible for the risk (buy insurance, outsourcing, etc.). Risk Register 5) Risk Control Risk Owner & Project Manager

Open risks should monitored on a regular basis. During monitoring, the risk content and status should be reevaluated. The Risk Owner and PM may need to seek management support and escalate high probability, high impact risks for visibility, input, and senior management decision making. Risk Register 6) Close Risk Project Manager A risk can be closed by the PM when one of the four actions occurs: 1. The risk was successfully eliminated or averted; 2. The risk occurs and becomes an issue; 3. The end date of the risk has passed; or 4. The project has been completed. Risk Register  Note: Projects differ in size, complexity, and risk tolerance. As result, the method for assigning probability and impact values to a risk may differ from that provided above. The chosen risk management methodology should be well documented in the projects Risk Management Plan.  Note: The probability cannot be 100%; at 100% it becomes a certainty, not a risk. Also it cannot be 0%, or there would be no risk. 24 DOE G 415.1-1 7-17-2014 2.6 Change Control Management The aim of this section is to provide a basic understanding of the change control management process and to help promote a standard for managing changes that may impact scope, schedule, or budget. The Change Control Management Plan is developed during the Planning Phase and should describe how, when, and who will be involved in the process. This process should be followed from this point onward to appropriately assess the impact changes will have on the project’s scope, schedule, and budget. Following a Change Control Management Process becomes even more important after the project is baselined (e.g. CD-1) as it can help to appropriately analyze and accept changes and avoid scope creep. The process outlined below may be utilized as a guide and not a replacement or in conflict with each project’s Change Control Plan. Table 6: Change Control Management describes a general process for managing project changes. Table 6: Change Control Management Step Responsible Description Key Artifact 1) Change Request (CR) Requestor The requestor, generally a direct project stakeholder will identify a required change and submit a Change Request Form (CR Form) to the PM. The CR Form is a document used to submit a request for change in a project. The Change Request Form summarizes the reasons and costs associated with a particular change. CR Form 2) Receive & Process the CR Form PM & Project Team The PM will review the CR Form for quality and completeness. If accepted, the CRs are added to the Change Request Log (CR Log). The CR Log is a document used to log and track change requests throughout the life of the project. The CR Log should be updated as new change requests are submitted or as existing change requests are approved, rejected, or deferred. Most of the information on the change log will come directly from the CR Form. CR Form CR Log 3) Approve the Request PM & CCB The PM will present the accepted CR Form to the CCB who will recommend the approval or rejection of the change request. The CR Log is updated with the outcome from the CCB review. CR Form CR Log 4) Start Impact Assessment Impact Assessment Team If approved, the CR Form is provided to the individual or team responsible for conducting the impact assessment. The Impact Assessment Team will analyze the change request and estimate the level of effort and/or impact to scope, schedule, and cost. The Impact Assessment Team documents their assessment in the designated section within the CR Form.

CR Form 5) Assessment Review PM & CCB The PM reviews the Impact assessment with the CCB and may request clarification or further analysis from the impact assessment team if CR Form CR Log DOE G 415.1-1 25 7-17-2014 Step Responsible Description Key Artifact required (The CR Log is updated). 6) Approve Implementation PM, CCB, (or as specified in the CC Plan) The PM and CCB (or as specified in CC Plan) approve or reject the CR based on the impact assessment information. The CR Log and CR Form are updated with the approval or rejection information. Impact Assessment CR Form CR Log 7) Update PM Documents and Communicate to Stakeholders PM The PM communicates the approval or rejection of the CR to the requestor and pertinent stakeholders. The PM will update other PM artifacts such as the PMP, Project Schedule, and Risk Register. The CR Log and CR Form are updated and closed. CR Form CR Log Other PM Artifacts 8) Implement Approved CR PM The PM manages the implementation of the approved CR. Other PM Artifacts Figure 9: Change Control Management Process provides a high-level view of the IT PEM change control management process. The process begins once a project has been baselined which in the IT PEM occurs at CD-1. Figure 9: Change Control Management Process 26 DOE G 415.1-1 7-17-2014 3 KEY PROJECT MANAGEMENT PRINCIPLES This section of the IT PEM will introduce key principles that complement the IT PEM by promoting structure and flexibility. The principles in this section can be utilized as guides to aid in determining: • Project Complexity Level (PCL); • Tailoring Approach; and • Modular or Agile Approach; 3.1 Project Complexity Level (PCL) As mentioned in Section 1.3: Applicability and Exclusions of this guide, DOE O 415.1 has set in place the following criteria to determine those projects that are within the thresholds of the IT PEM applicability: • A Total Project Cost (TPC) equal to or more than $25 Million (M); • With an impact on more than one DOE Element; or • As determined by the Undersecretary or Head of Element, based on risk management, mission, priorities, or national interest. To support the above criteria and to further establish a method for distinguishing projects of differing costs and complexity levels, the IT PEM framework utilizes the 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. Table 7: Determining Project Complexity Level displays a matrix view of the PCL and explains the basic criteria for each of the PCL sizes. Table 7: Determining Project Complexity Level Determining the PCL will help in identifying the proper: level of governance oversight; rightful program or project office; and tailoring approach. It is therefore strongly suggested that the PCL be determined during the Pre-Project Phase along with or as part of the (high-level) business case DOE G 415.1-1 27 7-17-2014 development. The decision tree is shown in Figure 10: Decision Tree for Determining PCL & IT PEM Applicability illustrates at a high-level the suggested approach for determining the PCL of a project. Figure 10: Decision Tree for Determining PCL & IT PEM Applicability  Note: DOE O 415.1 requires that all IT projects that do not meet the above criteria be required to use a standardized project management approach as specified and approved by the sponsoring/funding organization.

 Note: DOE O 415.1 Applicability & Exclusions criteria for projects are different than the criteria used for CPIC investments. Project teams are advised to reference the latest Capital Planning and Investment Control (CPIC) documentation (i.e. DOE Guide to IT Capital Planning and Investment Control) or contact CPIC team at DOE.CPICMailbox@hq.doe.gov for specific updates to the investment levels, cost thresholds, and specific DOE and Office of Management and Budget requirements.  Note: In addition to the applicability criteria from DOE O 415.1, IT projects also have the option to assess other project criteria to determine its PCL. Other project criteria may include, but not be limited to the following: • Familiarity of requirements; • Number of system interfaces (internal or external); and • Familiarity with technology. mailto:DOE.CPICMailbox@hq.doe.gov 28 DOE G 415.1-1 7-17-2014 3.2 Tailoring This section introduces the concept of tailoring as it is applied in the IT PEM framework. This section may be utilized as a guide or standard for developing the Tailoring Plan. Figure 11: IT PEM Tailoring suggests a path for developing the Tailoring Plan. As the illustration suggests, the Tailoring Plan can be incorporated into the PMP and submitted for review at CD-1. Figure 11: IT PEM Tailoring The IT PEM tailoring process begins with the determination of the PCL. As described in Section 4.1(Project Complexity Level) of this guide, the PCL provides a method for differentiating projects based on their level of complexity (see Table 7: Determining Project Complexity Level in previous section). A project of higher complexity may require greater effort with regards to process, reviews, and the content and quantity of artifacts. The PM and project team utilize the PCL to determine an appropriate tailoring strategy. The Tailoring Strategy should include the project’s request to consolidate, modify, or waive any standard artifacts or phase gate reviews (CDs) from the standard IT PEM framework in accordance with the risks, costs, complexity, and strategic visibility of the project. The Tailoring Strategy may also describe phase, artifact, and review alterations due to using a modular or agile development approach. The strategy should then be captured in the Tailoring Plan and included with (or as part of) the PMP for review at CD-1. The project should attempt to adhere to the work pattern established in the Tailoring Plan throughout the remainder of the lifecycle. Any subsequent deviation from the approved work pattern should be analyzed and appropriately approved to ensure adequate deliverables are provided and to assess impact on project scope, schedule, and cost. Section DOE G 415.1-1 29 7-17-2014 5.1(Project Management Templates and Artifacts) in this guide provides the IT PEM Artifact Matrix which suggests project artifacts based on IT PEM phase, stage, PCL, and importance to DOE O 415.1 and other federal directives.  Note: The following principles should be followed when applying tailoring: • The Cost Baseline and Schedule Baseline should be adjusted to include the elements of the Tailoring Strategy. • The Tailoring Strategy should only apply to deviations from the standard PEM framework starting with the Planning Phase, immediately following CD-0. • All projects, regardless of PCL or project type, should complete the same processes and develop the same project artifacts outlined in the Initiation Phase, leading up to CD-1, Approve Performance Measurement Baseline (PMB).

• The proposed deviations from the standard PEM framework should still satisfy the intent of each CD (CD-2 through CD-4) and comply with federal and governmental requirements such as Cybersecurity, OMB, and Enterprise Architecture. • Tailoring should be proposed with the assertion that there is no significant advantage to staged decision making, in terms of lowering risk and increasing the probability of success. 3.3 Agile or Modular Development Agile and Modular development is an alternative to traditional waterfall project management and typically used in software development. This type of development helps project teams respond to unpredictability through incremental, iterative work patterns, also known as sprints. Every aspect of design, development, and testing is continually revisited through the iterative process. Project teams have the opportunity at every sprint planning meeting to re-evaluate the direction of the project and steer it in another direction if required. The “inspect-and-adapt” approach to development can help reduce both development costs and product or feature release to customer. The goal is to deliver a usable product or feature at the end of each successful sprint. Per the Office of Management and Budget (OMB), Contracting Guidance to Support Modular Development, agencies can recognize the following benefits through modular development approaches: • Delivery of usable capabilities that provide value to customers more rapidly as agency missions and priorities mature and evolve; • Increased flexibility to adopt emerging technologies incrementally, reducing the risk of technological obsolescence; • Decreased overall project risk as agencies plan for smaller projects and increments versus “grand design” (each project has a greater overall likelihood of achieving cost, schedule, and performance goals than a larger, all-inclusive development effort); • Creation of new opportunities for small businesses to compete for the work; • Greater visibility into contractor performance. Tying award of contracts for subsequent Task Orders to the acceptable delivery of prior projects provides agencies better visibility 30 DOE G 415.1-1 7-17-2014 into contractor performance and allows a greater opportunity to implement corrective actions without sacrificing an entire project; • A project can be terminated with fewer sunk costs, capping the risk exposure to the agency when priorities change, a technology decision does not work or the contractor’s performance does not deliver results. 3.3.1 Agile or Modular Development Using the IT PEM This section describes how an agile or modular development may be applied within the IT PEM framework. The intent is not to focus on a specific agile or modular methodology such as SCRUM, XP, Kanban, etc. Instead, the intent is to provide a general overview of common deliverables found in both agile and modular development and describe how those deliverables may be executed using the IT PEM framework. Figure 12: IT PEM Agile & Modular Development illustrates the general process flow required to execute a modular or agile approach within the IT PEM framework. The process involves: • Identifying the project scope and requirements early in the IT PEM lifecycle (Initiation & Planning Phases); • Determining whether an agile or modular development should be used for the project; • Developing and documenting the agile/modular strategy in the Agile/Modular Plan; • The Agile/Modular Plan should:

o Explain the benefits and risks of using a modular or agile approach; o Describe the agile / modular approach or methodology to be utilized (i.e. SCRUM, XP, Kanban); o Describe specific project stakeholder roles and responsibilities; o Describe iterative process and sprint/module durations; o Define the artifacts to be utilized during the iterative process to address design, development, testing, and operational readiness acceptance (i.e. System Design Review, Test Readiness Review, and Operational Readiness Review); o Describe how Monitoring & Controlling processes will be addressed during the iterative process (i.e. Change Control Management, Risk Management, CD Reviews, and Quarterly Project/Other Reviews) o Describe product or feature release method. • Submit the Agile/Modular Plan along with the PMP for approval at CD-1; • Begin agile/modular development after CD-1 (or Execution Phase); • Release system, product, or features after CD-3 approval. Figure 12: IT PEM Agile & Modular Development DOE G 415.1-1 31 7-17-2014 The following examples provide two methods of how agile or modular development could be applied in the IT PEM framework: Example 1: An IT project may combine CD-2 and CD-3 to create an effective agile process which will provide flexibility during the systems design, development, and testing stages to accommodate the inherently iterative nature of IT projects. Figure 13: CD-2 & CD-3 Combined Example 2: In the spirit of modular development, an IT project may choose to execute three software releases in order to produce key features of the product, and thereby minimizing risk with the uncertainty in software development. Therefore, the IT project may choose to complete the Execution Phase in an iterative manner. This would produce 3 different CD packages for CD- 2 (CD-2a, CD-2b, CD-2c) and CD-3 (CD-3a, CD-3b, CD-3c). 32 DOE G 415.1-1 7-17-2014 Figure 14: CD-2 and CD-3 applied for each module or iteration  Note: Deviations from the standard PEM framework should still satisfy the intent of each CD (CD-2 through CD-4) and comply with federal and governmental requirements such as Cybersecurity, OMB, and Enterprise Architecture. DOE G 415.1-1 33 7-17-2014 4 TEMPLATES & ARTIFACTS 4.1 Project Management Templates and Artifacts The IT PEM defines project management through the appropriate application and integration of logically grouped project management processes across its five lifecycle phases (Pre-Project, Initiation, Planning, Execution, and Production). Each process leads to the development of a project artifact. In this section, the aim is to provide project teams with a standard artifact table that helps them define required, beneficial, and optional artifacts based on the PCL described in Section 4.1 : Project Complexity Level (PCL) of this guide. Table 8 illustrates the IT PEM Artifact Matrix which lists the project management artifacts by IT-PEM Phase and PCL. In addition to the PCL, PEM artifacts are further categorized in the following criteria: • Required (REQ): Project management artifacts endorsed by DOE O 415.1 and/or OMB for Exhibit 300. • Essential (ESS): | Project management artifacts essential to maintain and/or support federal approaches towards strategy, business, security, and technology. • Beneficial (BEN): Best practice and other conventional artifacts that may prove beneficial for successful project management.  Note: The IT PEM Artifact Matrix (Table 8: Illustration of the "IT PEM Artifact Matrix”) is located

in the Corporate IT PMO Framework Repository. For a soft copy or access to the repository, please send your requests to IM-20, Office of IT Policy and Governance at CorporateITPMO@hq.doe.gov.  Note: DOE O 415.1 Applicability & Exclusions criteria for projects are different than the criteria used for CPIC investments. Project teams are advised to reference the latest Capital Planning and Investment Control (CPIC) documentation (i.e. DOE Guide to IT Capital Planning and Investment Control) or contact CPIC team at DOE.CPICMailbox@hq.doe.gov for specific updates to the investment levels, cost thresholds, and specific DOE and Office of Management and Budget requirements.  Note: It is at the discretion of each project team and their respective governance to determine how to structure the CDs throughout the project lifecycle.  Note: Deviations from the standard PEM framework should still satisfy the intent of each CD (CD-2 through CD-4) and comply with federal and governmental requirements such as Cybersecurity, OMB, and Enterprise Architecture. mailto:CorporateITPMO@hq.doe.gov mailto:DOE.CPICMailbox@hq.doe.gov 34 DOE G 415.1-1 7-17-2014 Table 8: Illustration of the “IT PEM Artifact Matrix”" Beneficial (BEN) OMB for Exhibit 300 Investment Enterprise Architecture (EA) Cybersecurity High Medium Low Validate w ith specific requesting organization (CPIC) before tailoring (omitting, consolidating, or modifying) below artifacts. Validate w ith specific requesting organization (EA) before tailoring (omitting, consolidating, or modifying) below artifacts. Validate w ith specific requesting organization (Cyber) before tailoring (omitting, consolidating, or modifying) below artifacts. Projects: > $25M Projects: $25M -$5M or Impacts M ore Than One DOE Element Projects: <$5M and does not Impact other DOE Elements Architecture Review Worksheet (Pre-Project Phase) * Reference "Architecture Review Process" Template for Specific Requirements X ESS ESS ESS Business Case X BEN BEN BEN Project Charter X X X REQ REQ BEN Architecture Review Artifacts (FEA, DoDAF, PRM, BRM, DRM, ARM, IRM) * Reference "Architecture Review Process" Template for Specific Requirements X ESS ESS ESS Approval of CD-0 (Memorandum) X X REQ REQ ESS Requirements Document (Business, Functional, Non-Functional, Data, and Interface) X X X REQ REQ ESS Project Management Plan (PMP) X X REQ REQ BEN Scope Management Plan X ESS ESS ESS Schedule Management Plan X BEN BEN BEN Cost Management Plan X BEN BEN BEN Work Breakdown Structure (WBS) X BEN BEN BEN Tailoring, Module, and/or Agile Plan X BEN BEN BEN Deliverables Table (Activities, Artifacts, or Products) X ESS ESS ESS Requirements Management Plan X ESS ESS ESS Configuration Management and Change Control Plan X X X REQ REQ ESS Quality Management Plan X ESS ESS ESS Performance Management Plan X X REQ REQ ESS Human Resource Plan X BEN BEN BEN Communication Management Plan X BEN BEN BEN Acquisition Plan X BEN BEN BEN Training Plan X BEN BEN BEN Risk Management Plan X X X REQ REQ BEN Cybersecurity Plan X X REQ REQ ESS Test Plan X BEN BEN BEN Alternatives Analysis X X REQ REQ BEN Basis of Estimate X BEN BEN BEN Architecture Review Artifacts (FEA, DoDAF, PRM, BRM, DRM, ARM, IRM) * Reference "Architecture Review Process" Template for Specific Requirements

X ESS ESS ESS Project Schedule (Baseline) X X REQ REQ BEN Performance Measurement Baseline X X REQ REQ BEN Risk Register X BEN BEN BEN Quarterly Project Review (QPR) Presentation X BEN BEN BEN Independent Review (IR) Documentation X ESS ESS ESS Approval of CD-1 (Memorandum) X X REQ REQ ESS System Requirements Document X X ESS ESS ESS System Design Document X X ESS ESS ESS Detailed Cost Estmate X X ESS ESS ESS Risk Register X X X X REQ REQ ESS Change Control Management Artifacts X X X X REQ REQ ESS Independent Review (IR) Documentation X ESS ESS ESS Approval of CD-2 (Memorandum) X X REQ REQ ESS Training Material Completed X BEN BEN BEN Test Readiness Review (TRR) Documentation X BEN BEN BEN Risk Register X X X X REQ REQ ESS Change Control Management Artifacts X X X X REQ REQ ESS Operational Readiness (ORR) Documentation X BEN BEN BEN Quarterly Project Review (QPR) Presentation X BEN BEN BEN Risk Register X X X X REQ REQ ESS Change Control Management Artifacts X X X X REQ REQ ESS Independent Review (IR) Documentation X ESS ESS ESS Lessons Learned Document X ESS ESS ESS Approval of CD-3 (Memorandum) X X REQ REQ ESS Training Material X BEN BEN BEN Post Implementation Report X X X REQ BEN ESS Risk Register X X X X REQ REQ ESS Change Control Management Artifacts X X X X REQ REQ ESS Project Closure Report X BEN BEN BEN Independent Review (IR) Documentation X ESS ESS ESS Lessons Learned Document X X ESS ESS ESS Approval of CD-4 (Memorandum) X ESS ESS ESS Mai nt. Annual Operational Analysis (AOA) X X REQ ESS ESS Pre-Project N/ A Production Im pl m nt Cl os ur e Initiation N/ A Planning N/ A Execution De si gn Dv lp m nt . Te st in g PEM Phase PE M S ta ge Project Artifact Required (REQ) Essential (ESS) Project Complexity Level Directive O 415.1 Best Practice Artifacts DOE G 415.1-1 35 7-17-2014 5 IT PEM Framework at a Glance Table 9: IT PEM Framework at a Glance provides a glance at the IT PEM framework as described in the previous sections. The purpose of this illustration is to provide a summary for project managers to reference when applying the IT PEM framework. 36 DOE G 415.1-1 7-17-2014 Table 9: IT PEM Framework at a Glance DOE G 415.1-1 37 7-17-2014 6 INFORMATION TECHNOLOGY PROJECT MODEL BY PHASE This section attempts to illustrate IT PEM artifact inputs and outputs for each lifecycle phase in preparation for its corresponding CD review. The intent is to provide project teams with a suggested workflow to systematically process and complete deliverables as prescribed by each CD review.  Note: The artifacts and CD packages displayed in this section have not been tailored nor designed for a particular PCL. Figures 15 to 20 may contain more or less artifacts than that actually required by a particular project.  Note: Projects may choose to tailor (combine, waive, or modify) CDs as appropriate. It is at the discretion of each project team and their respective governance to determine how to structure the CDs throughout the project lifecycle.  Note: Deviations from the standard PEM framework should still satisfy the intent of each CD (CD-2 through CD-4) and comply with federal and governmental requirements such as Cybersecurity, OMB, and Enterprise Architecture. 6.1 Pre-Project Phase: Figure 15: Pre-Project Phase 38 DOE G 415.1-1 7-17-2014 6.2 Initiation Phase: Figure 16: Initiation Phase Artifact Workflow 6.3 Planning Phase: Figure 17: Planning Phase Artifact Workflow DOE G 415.1-1 39 7-17-2014

6.4 Execution Phase: Figure 18: Execution Phase Artifact Workflow (CD-2) Figure 19: Execution Phase Artifact Workflow (CD-3) 40 DOE G 415.1-1 7-17-2014 6.5 Production Phase Figure 20: Production Phase Artifact Workflow DOE G 415.1-1 Appendix A 7-17-2014 A-1 APPENDIX A OCIO Resources and Departmental Requirements The IT PEM in accordance with DOE O 415.1 aims to support Government-wide and/or Department requirements essential to maintain and/or support federal approaches towards strategy, business, security, and technology. Table 10: 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 IT PEM. Table 10: Government-wide and DOE Requirements Integrated into the IT PEM Topic Summary OCIO Contact 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.doe.gov 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 Enterprise Architecture Enterprise Architecture (EA) 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 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. Enterprise Architecture (IM-1) - OCIO DOEEAMailbox@hq.doe.gov 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:DOEEAMailbox@hq.doe.gov Appendix A DOE G 415.1-1 A-2 7-17-2014 Topic Summary OCIO Contact 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.

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.gov 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. U.S. Department of Energy (DOE), Office of Health, Safety and Security (HSS) - OCIO mailto:EITS_PMQAD@hq.doe.gov DOE G 415.1-1 Appendix B 7-17-2014 B-1 APPENDIX B GLOSSARY Term Definition Acquisition Executive (AE) The individual designated by the Secretary of Energy to integrate and unify the management system for a Program portfolio of projects and implement prescribed policies and practices. The Acquisition Executive cannot award nor modify contracts, or commit the Government in any way, without an approved delegation of authority from the Head of the Contracting Activity (HCA) to serve as a Contracting Officer.” Agile Development Refers to an alternative to traditional 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 traditional 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. Baseline A quantitative definition of cost, schedule, and technical performance 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. Beneficial (BEN) Artifacts Best practice and other conventional artifacts that may prove beneficial for successful project management.

Benefit Cost Analysis Refers to the recommended technique to use in a formal economic analysis of government programs or projects. Guidance for Benefit-Cost Analysis is described in OMB Circular A-94. Budget A prediction of the costs associated with a particular project. These costs include labor, materials, and other related expenses. http://www.whitehouse.gov/omb/circulars_a094 http://www.whitehouse.gov/omb/circulars_a094 Appendix B DOE G 415.1-1 B-2 7-17-2014 Term Definition Business Owner The Business Owner has ultimate responsibility for seeing that the intended benefits are realized to create the value forecast in the business case. The Business Owner represents the business users and serves as part of the Integrated Project Team (IPT). The business owner's job is to help ensure that the end users become satisfied end users and that they understand and anticipate the development and deployment process, appreciate the product's benefits, welcome training, accept the new system and eventually adopt it as their own. The business owner may perform, participate (or lead) the following core activities: • Business Case Development • Business Process & Business Requirements identification • Functional Requirements Development • Business User Acceptance Testing • Business User Training • Quality/Integrity Oversight • Communication (Business Stakeholders & Sponsor) • Achieve Return on Investment Capital Planning and Investment Control (CPIC) (Also called capital programming) refers to a decision- making process that ensures IT investments integrate strategic planning, budgeting, procurement, and management of IT in support of agency missions and business needs. The term was introduced in the Clinger- Cohen Act of 1996 and generally is used in relation to IT management issues. 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. DOE G 415.1-1 Appendix B 7-17-2014 B-3 Term Definition Chief Information Officer (CIO) Senior executive responsible for the information technology and computer systems that support enterprise goals. The CIO provides leadership, establishes policy, and maintains oversight of DOE’s annual investment in information technology (IT), to enable urgent missions that span from open science to nuclear security.

Closure Stage The purpose of the closing phase is to confirm completion of project deliverables to the satisfaction of the project sponsor. In addition, all procurement and project management processes are closed. All project artifacts are collected and archived. Final project disposition and status is communicated to all participants and stakeholders. Contract A contract is a mutually binding agreement that obligates the seller to provide the specified product and obligates the buyer to pay for it. Contract Officer (CO) The CO has the authority to enter into, administer, and/or terminate contracts and make related determinations and findings. The term includes certain authorized representatives of the CO acting within limits of his/her authority as delegated by the CO. The CO and/or his/her representative are accountable for preparing solicitation documents with technical support from the IT PM and acting on behalf of the Head of the Contracting Activity. Contract Officer Representative (COR) CORs are qualified individuals appointed by the (CO) to assist in the technical monitoring or administration of a contract. 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. 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. 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. Appendix B DOE G 415.1-1 B-4 7-17-2014 Term Definition 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, Modernization, and Enhancement (DME) DME means the project cost for new projects, changes, or modifications to existing systems to improve capability or performance; changes mandated by Congress or Agency leadership; personnel costs for investment management; and direct support.

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. 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. DOE G 415.1-1 Appendix B 7-17-2014 B-5 Term Definition Essential (ESS) Artifacts Project management artifacts essential to maintain and/or support federal approaches towards strategy, business, security, and technology. 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. Executive Sponsor (Mission Owner) Senior Federal Executive who specifies the business need or mission to the Federal Sponsor or to the organizational level. The Executive Sponsor is also responsible for allocating and/or designating the funding for the business need. 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 at the organizational level with the authority to accept and assign project management responsibility. The Federal Sponsor manages the budget within the organization. Focus Group Technical subgroup designated by the IPT, FPM, or Working Group to carry out the development of a task, analysis, or deliverable. The Focus Group does not make decisions and reports directly to the Working Group. Impact Assessment Team Team responsible for the analysis and determination of cost, time, and resource impacts of a change in project scope, schedule, or cost. 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. Independent Reviewer (IR) Individual or group not directly involved with the project but provides the PM with an objective assessment of whether the project is ready for a CD review, and ultimately request approval to proceed to the next phase.

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. Appendix B DOE G 415.1-1 B-6 7-17-2014 Term Definition 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. 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. Integrated Project Team (IPT) Inter-disciplinary stakeholder group with the specific knowledge, skills, and abilities necessary to support and complement the decision-making process. IPT members may be fully or partially part of the project team. The IPT may consist of Federal and contractor staff. DOE G 415.1-1 Appendix B 7-17-2014 B-7 Term Definition IT Assets These IT assets provide the infrastructure and operational IT

services necessary for accomplishing the site Missions and Programs. Specifically, they are locally managed IT assets or IT support services. Examples include the following: • Networks; • Telecommunications; • Desktops; • Internet/Intranet; • Email; • Collaboration Tools; • IT Planning (EA/CPIC/Program Office Support); • Web Hosting; • Data Storage; and/or • Contractor Business/Financial/Administrative Systems. 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 PEM 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 & Stages • Critical Decision (CD) • Deliverables & CD Packages • Project Stakeholders 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 Management Office (IT PMO) An Organizational Element or group that defines and maintains the standards or processes generally related to Project Management within the Organization. The PMO develops project guidance, policies, and procedures. Appendix B DOE G 415.1-1 B-8 7-17-2014 Term Definition 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. 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. Mission Assurance A full life-cycle engineering process to identify and mitigate design, production, test, and field support deficiencies of mission success. 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. DOE G 415.1-1 Appendix B 7-17-2014 B-9 Term Definition 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. 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. 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. Appendix B DOE G 415.1-1 B-10 7-17-2014 Term Definition 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. 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 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 Team The Project Team is the group that is responsible for planning and executing the project. The Project Team members execute their tasks according to the Project Schedule. Their responsibility includes executing tasks and producing deliverables as outlined in the Project Plan and directed by the PM, at whatever level of effort or participation has been defined or assigned to them. http://en.wikipedia.org/wiki/Project DOE G 415.1-1 Appendix B 7-17-2014 B-11 Term Definition Quarterly Project Reviews (QPR) A quarterly management briefing (with supporting documentation) where the PM updates key stakeholders and executives on the status of the IT project. The QPR should cover key topics including, but not limited to: • Accomplishments (to date and/or during previous quarter); • Planned activities (until completion and/or planned for next quarter) • Critical risks and issues • Topics that require decision by the Acquisition Executive • Measurement of project performance against baseline (metrics) Required (REQ) Artifacts Project management artifacts endorsed by DOE O 415.1 and/or required by OMB for Exhibit 300. 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. 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. 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) Appendix B DOE G 415.1-1 B-12 7-17-2014 Term Definition 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. Steady State (SS) Steady State means maintenance and operation costs at current capability and performance levels including costs for personnel, maintenance of existing information systems, corrective software maintenance, voice and data communications maintenance, and replacement of broken IT equipment. 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. 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. 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-1 Appendix C 7-17-2014 C-1 APPENDIX C ACRONYMS Acronym Definition AUP Agile Unified Process BEN Beneficial BY Budget Year C&A Certification and Accreditation CC Change Control CCB Change Control Board CD Critical Decision CIO Chief Information Officer CO Contracting Officer COR Contracting Officer’s Representative CPIC Capital Planning and Investment Control CPM Contractor Project Manager CR Change Request DME Development, Modernization and Enhancement DOE Department of Energy EA Enterprise Architecture EM Environmental Management EOP Executive Office of the President ESS Essential EVM Earned Value Management EVMS Earned Value Management System FASA Federal Acquisition Streamlining Act FISMA Federal Information Security Management Act FPM Federal Project Manager GAO Government Accountability Office HCA Head of the Contracting Activity HHS Health and Human Services HQ Headquarters IEEE Institute of Electrical and Electronics Engineers IMS Integrated Master Schedule IPT Integrated Project Team IR Independent Review IT Information Technology M Million ($) NNSA National Nuclear Security Administration O Order OCIO Office of the Chief Information Officer OMB Office of Management and Budget PCL Project Complexity Level PEM Project Execution Model Appendix C DOE G 415.1-1 C-2 7-17-2014 Acronym Definition PMB Performance Measurement Baseline PMBOK Project Management Body of Knowledge PMI Project Management Institute PMO Project Management Office PMP Project Management Plan QA Quality Assurance QPR Quarterly Project Review REQ Required RM Records Management RTM Requirements Traceability Matrix S&S Safety and Safeguards SEI Software Engineering Institute SEM Systems Engineering Methodology SS Steady State TPC Total Project Cost UAT User Acceptance Test WBS Work Breakdown Structure XP Extreme Programming DOE G 415.1-1 Appendix D 7-17-2014 D-1 APPENDIX D REFERENCES a. DOE, Secretary Delegation Order No. 00-031.00A, dated June 7, 2007. b. DOE CIO Memorandum, Enterprise Architecture Guidance, dated January 9, 2007. c. DOE G 413.3-2, Quality Assurance Guide for Project Management, dated June 27, 2008. d. DOE G 413.18-A, Integrated Project Team Guide for Formation and Implementation, dated February 3, 2012. e. DOE O 200.1A, Information Technology Management, dated December 23, 2008. f. DOE O 205.1B, Department of Energy Cybersecurity Management Program, dated May 16, 2011. g. DOE O 243.1A, Records Management Program, dated November 7, 2011. h. DOE O 413.1B, Internal Control Program, dated October 28, 2008. i. DOE O 413.3B, Program and Project Management for the Acquisition of Capital Assets, dated November 29, 2010. j. DOE O 414.1D, Quality Assurance, dated April 25, 2011. k. Executive Order 13011, Federal Information Technology, FR 61-140, dated July 19, 1996. l. Government Accountability Office (GAO) Report – GAO-11-826, OMB Needs to Improve Its Guidance on IT Investments, dated September 29, 2011. m. Office of Science, Definition of a User Facility Memorandum, dated January 6,

2012. n. OMB Circular A-11, Preparation, Submission and Execution of the Budget, dated August 18, 2011. o. OMB Circular A-123, Management Accountability and Control, dated December 21, 2004. p. OMB Circular A-127, Financial Management Systems, dated January 9, 2009. q. OMB Circular A-130, Management of Federal Information Resources, dated November 28, 2000. r. OMB Memorandum M-00-07, Incorporating and Funding Security in Information Systems Investments, dated February 28, 2000. s. OMB Memorandum M-11-29, Chief Information Officer Authorities, dated August 8, 2011. t. OMB Memorandum M-97-02, Funding Information Systems Investments, dated October 25, 1996. u. The Clinger-Cohen Act of 1996, (CCA), (Public Law 104-106, Division E), dated February 10, 1996. v. The E-Government Act of 2002, (Public Law 107-347), dated December 17, 2002. w. The Federal Acquisition Streamlining Act of 1994, Title V (FASA V), dated October 13, 1994. x. The Federal Information Security Management Act (FISMA) of 2002, dated October 24, 2002. 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 https://www.directives.doe.gov/directives/0413.3-BOrder-b/view Appendix D DOE G 415.1-1 D-2 7-17-2014 y. The Government Information Security Reform Act (GISRA - 2000), dated October 30, 2000. z. The Government Paperwork Elimination Act of 1998, (Public Law 105-277, Title XVII), dated October 21, 1998. aa. The Government Performance and Results Act of 1993 (GPRA) (Public Law 103- 62), dated August 3, 1993. bb. The Paperwork Reduction Act of 1995, (Public Law 104-13), dated May 22, 1995. cc. The President’s Management Agenda, Office of Management and Budget, Fiscal Year 2002, dated January 29, 2001. dd. Federal Acquisition Regulation (FAR), General Services Administration, Department of Defense, and National Aeronautics and Space Administration, dated March 2005. ee. 25 Point Implementation Plan to Reform Federal Information Technology Management, U.S. Chief Information Officer, dated December 9, 2010. ff. Contracting Guidance to Support Modular Development, U.S. Chief Information Officer, dated June 14, 2012. gg. Project Execution Model (PEM), National Nuclear Security Administration (NNSA) Office of the Chief Information Officer, dated September 2009. DOE G 415.1-1 Appendix E 7-17-2014 E-1 APPENDIX E DESCRIPTION OF PROJECT ARTIFACTS Acquisition Plan: A document that details all major concerns for acquiring materials or services in support of a project. Typically, the Acquisition Plan addresses issues related to technological aspects, competition, funding, business concerns, management issues, and other significant risk factors that could potentially impact the sponsoring/funding organization. The Acquisition Plan establishes a timetable and specific milestones for the effective execution of the process to mitigate risk. 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. Architecture Review Artifacts: 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. Baseline Change Request (BCR) Form: A document that is completed whenever there is a proposed change that impacts the scope of work, schedule, and/or budget elements of the Performance Measurement Baseline (PMB), or the baseline is impacted by outside influences such as funding limitations or directed schedule delays. The BCR Form should consider impacts to the PMB – scope, schedule, and budget. Basis of Estimate: A document that details the premise, or basis, from which critical aspects of a project cost estimate were developed, including cost and labor estimates, material availability, any assumptions or deviations, any studies or analysis used as a reference and any other details which impacted the cost estimates. 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 Appendix E DOE G 415.1-1 E-2 7-17-2014 implemented, return on investment, and other essential data prescribed by internal and external federal organizations. Business Requirements Document (BRD): A document that details the business solution for a project including information pertaining to the customer needs, customer expectations, and important technical characteristics. Communication Management Plan: The document that describes: the communications needs and expectations for the project; how and in what format information will be communicated; when and where each communication will be made; and who is responsible for providing each type of communication. The Communication Management Plan is contained in, or is a subsidiary plan of, the Project Management Plan.

Configuration Management and Change Control Plan: A document that describes how configuration management and change control will be structured and performed on the project. It is contained in or is a subsidiary plan of the Project Management Plan. Configuration management refers to the process for establishing and maintaining consistency of a product’s performance and functional and physical attributes with its requirements, design, and operational information through its lifecycle. Change Control refers to the process of establishing a defined identification of, a thorough documentation of, submission of a formal approval or rejection of, and asserting control of all changes that are going to take place to the project baselines. Cost Performance Baseline: A specific version of the time-phased budget used to compare actual expenditures to planned expenditures to determine if preventive or corrective action is needed to meet the project objectives. Chief Architect’s Signature: Occurs during the Planning Phase. Chief Architect approval and signature after EA project artifacts (As described in the DOE Architecture Review Process) have been reviewed by the DOE Architecture Review Board. Cybersecurity Plan: A document that describes managerial, technical and operational security controls (defined by the National Institute of Standards and Technology) that are designed and implemented within the system (May also be referred to as System Security Plan (SSP). Detail Cost Estimate: Provides detail cost and level of effort estimate based on system design document. Earned Value Management (EVM) Report: Refers to an integrated management system that coordinates the work scope, schedule, and cost goals of a program or contract, and objectively measures progress toward these goals. EVM is a tool used by program managers to: (1) quantify and measure program/contract performance, (2) provide an early warning system for deviation from a baseline, (3) mitigate risks associated with cost and schedule overruns, and (4) provide a means to forecast final cost and schedule outcomes. The qualities and operating characteristics of earned value management systems (EVMS) are described in American National Standards Institute (ANSI)/Electronic Industries Alliance (EIA) Standard–748–1998, Earned Value Management Systems. Additional information on EVMS is available at www.acq.osd.mil/evm. http://www.acq.osd.mil/evm. DOE G 415.1-1 Appendix E 7-17-2014 E-3 Functional Requirements Document (FRD). Detailed outline of what needs to be delivered for the purpose of communicating it to technical teams and/or developers. The Functional Requirements Document is a successor of the BRD and typically completed by a business analyst. Human Resource Plan: A document describing how roles and responsibilities, reporting relationships, and staffing management will be addressed and structured for the project. It is contained in or is a subsidiary plan of the project management plan. Independent Review (IR) Documentation: A set of documentation that describes the approach for conducting an IR and describes the outcomes of the IR. The goal of the IR is to assess whether the IT project is prepared to submit a CD submission, and ultimately request approval to proceed to the next phase. Independent Verification and Validation (IV&V) Plan: (See Independent Review (IR) Documentation) Independent Verification and Validation (IV&V) Report: (See Independent Review (IR) Documentation)

Lessons Learned Document. A document that contains the learning gained from the process of performing the project. Lessons learned may be identified at any point. Lessons learned are also considered a project record. Lessons Learned may also be tracked in a knowledge base. Operational Readiness Review (ORR). A review to ensure the product or feature has been properly tested, approved, ready, and safe for operations, production environment, and / or end- user. Performance Measurement Plan: A system or standard of measurement to determine if a set of inherent characteristics fulfills requirements. 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 systems, post implementation review typically occurs after the system has been in production for a period of time (normally 6 months). Project Archives: Preservation of vital information, including both documentation of project execution and the data from the production system. 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 Appendix E DOE G 415.1-1 E-4 7-17-2014 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. Pre-Project Architecture Review Worksheet: A document that details the results of an architecture review prior to the initiation of the project. The pre-project architecture review ensures the proposed IT solution does not duplicate, interfere, or contradict another IT solution that already exists or is proposed. Procurement Documentation: Contracts, Statements of Work, Level of Efforts, Bill of Materials, and other pertinent bonding agreements required to procure project materials and resources. Project Charter: A document issued by the project initiator or sponsor that formally 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. 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 Business Sponsor to close the project. 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.

Project Scope Statement: (See Project Charter) Quality Management Plan: A document that describes how the project management team will implement the performing organization’s quality policy. The Quality Management Plan is a component or a subsidiary plan of the Project Management Plan. Quarterly Project Review (QPR) Presentation: A presentation to the IT project’s management and stakeholders that provides status. The presentation may include key topics such as accomplishments, planned activities, critical risks and issues, and items that require decision by management. Requirements Management Plan: A document that details the necessary information to effectively manage project requirements from definition, through traceability, to project delivery. Risk Management Plan: The document describing how project risk management will be structured and performed on the project. It is contained in or is a subsidiary plan of the Project Management Plan. Information in the Risk Management Plan varies by application area and project size. The Risk Management Plan is different from the Risk Register that contains the list DOE G 415.1-1 Appendix E 7-17-2014 E-5 of project risks, the results of risk analysis, and the risk responses. The Risk Management Plan should include a Security Risk Assessment Plan section to describe the analysis and assessment process for security functional requirements. The Security Risk Assessment Plan should focus on how to identify and prevent or mitigate threats and vulnerabilities to the information system; the impact or magnitude of harm that a loss of confidentiality, integrity, or availability would have on agency assets or operations and the identification and analysis of security controls for the information system. 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. Security Risk Assessment: (See Risk Management Plan) Stakeholder Register & Strategy: A list of the relevant stakeholders and a brief description of the functional role each will play in support of the project. It is used to ensure that all stakeholders are included in the project communications. System Architecture Review (SAR): The System Architecture Review, or SAR, is a process that brings stakeholders and technologists together to help ensure that technology solutions are conceived, designed, developed, and deployed in an effective and efficient manner, to maximize the benefits and functionality of the technology, while minimizing its cost and risk. The SAR ensures compliance with existing standards and practices, controlled introduction of new technologies and services, and appropriate reuse of existing technology, to increase returns on investment and decrease total costs of ownership. System Design Document: A document that defines the architecture, components, modules, interfaces, and data for a system to satisfy specified requirements. System Requirements Review (SRR): A technical review to ensure that the system under review can proceed into initial systems development, and that all system requirements and performance requirements are defined, testable, and consistent with cost, schedule, risk, technology readiness, and other system constraints.

Tailoring Plan: Strategy on how project will adapt the IT PEM specifications to the project based on its unique circumstances. The Tailoring Strategy should be clearly documented within the Project Management Plan. Technical Requirements Document (TRD): The TRD translates the FRD requirements into a systematic and technically executable list. Specifically, the TRD is specifies what system specific requirements are needed to deliver what was requested (and approved) in the FRD. 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 Appendix E DOE G 415.1-1 E-6 7-17-2014 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. Test Readiness Review: The TRR is a multi-disciplined technical review to ensure that the subsystem or system under review is ready to proceed into formal test. 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. Training Materials: A set of documentation associated with the deployment of the business product. Documentation may include, but not be limited to: instructor and student guides; audio- visual aid; and computer-based or other media used to disseminate information about the final product to the target audience that is in need of the instruction. User Manual: (See Training Material) 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. Work Breakdown Structure (WBS) Dictionary: A document that describes each component in the Work Breakdown Structure (WBS). For each WBS component, the WBS Dictionary includes a brief definition of the scope or statement of work, defined deliverable(s), a list of associated activities, and list of milestones. Other information may include: responsible organization, start and end dates, resources required, an estimate of cost, charge number, contract information, quality requirements, and technical references to facilitate performance of the work.

FOREWORD 1 INTRODUCTION 1.1 Purpose 1.2 Background 1.3 Applicability and Exclusions 2 INFORMATION TECHNOLOGY PROJECT EXECUTION MODEL 2.1 Methodology 2.1.1 PMBOK® Guide1 2.1.2 ITIL v3 2.1.3 System Engineering 2.1.4 Federal Organizations 2.1.5 Government wide or Departmental Requirements 2.2 IT PEM Framework 2.3 IT PEM Elements 2.3.1 Lifecycle Phases & Stages 2.3.2 Critical Decision (CD) 2.3.2.1 CD Approvers 2.3.3 Deliverables and CD Packages 2.3.4 Project Stakeholders 2.4 Quality Management 2.4.1 Critical Decision (CD) Review 2.4.2 Independent Reviews (IR) 2.4.3 Quarterly Project Reviews (QPR) 2.5 Risk Management 2.6 Change Control Management 3 KEY PROJECT MANAGEMENT PRINCIPLES 3.1 Project Complexity Level (PCL) 3.2 Tailoring 3.3 Agile or Modular Development 3.3.1 Agile or Modular Development Using the IT PEM 4 TEMPLATES & ARTIFACTS 4.1 Project Management Templates and Artifacts 5 IT PEM Framework at a Glance 6 INFORMATION TECHNOLOGY PROJECT MODEL BY PHASE 6.1 Pre-Project Phase: 6.2 Initiation Phase: 6.3 Planning Phase: 6.4 Execution Phase: 6.5 Production Phase APPENDIX A APPENDIX B GLOSSARY APPENDIX C ACRONYMS APPENDIX D REFERENCES APPENDIX E DESCRIPTION OF PROJECT ARTIFACTS