DOE G 413.3-5A Chg 1 (Admin Chg 1), U.S Department of Energy Performance Baseline Guide

NOT MEASUREMENT SENSITIVE DOE G 413.3-5A Approved 9-23-2011 Chg 1 (Admin Chg) 10-22-2015 U.S. DEPARTMENT OF ENERGY PERFORMANCE BASELINE GUIDE [This Guide describes suggested nonmandatory approaches for meeting requirements. Guides are not requirements documents and are not to be construed as requirements in any audit or appraisal for compliance with the parent Policy, Order, Notice, or Manual.] U.S. Department of Energy Washington, D.C. 20585 AVAILABLE ONLINE AT: INITIATED BY: www.directives.doe.gov Office of Project Management Oversight & Assessments http://www.directives.doe.gov/ DOE G 413.3-5A i (and ii) 9-23-11 FOREWORD This Department of Energy (DOE) Guide is for use by all Departmental elements and suggests approaches for implementing Performance Baseline (PB) development requirements of DOE Order (O) 413.3B, Program and Project Management for the Acquisition of Capital Assets. DOE Guides, which are part of the DOE Directives System, provide non-mandatory information for fulfilling requirements contained in rules, regulatory standards, and DOE directives. Guides are not requirements documents and are not to be construed as requirements in any audit or appraisal for compliance with the parent Policy, Order, Notice, or Manual. DOE G 413.3-5A iii (and iv) 9-23-11 PURPOSE This guide identifies key PB elements, development processes, and practices; describes the context in which DOE PB development occurs; and suggests ways of addressing the critical elements in PB development. SCOPE The scope of this Guide includes the overall process for the development of PBs; describing key elements of PBs in context of the DOE project management system; defining key deliverables associated with PBs; and providing useful guidance for achieving the desired outcomes for the approved PB. The original PB is established at Critical Decision (CD)-2. A revised PB via a baseline change proposal (BCP) should be avoided. Refer to DOE O 413.3B, page A-19, Performance Baseline Changes. Performance baseline changes should be comply with change control procedures. Refer to DOE G 413.3-20¸ Change Control Management Guide. DOE G 413.3-5A v 9-23-11 TABLE OF CONTENTS FOREWORD ................................................................................................................................... i PURPOSE ...................................................................................................................................... iii SCOPE ........................................................................................................................................... iii 1.0 BASELINES IN DOE PROJECT MANAGEMENT SYSTEMS ....................................... 1 1.1. Characteristics of Performance Baseline at CD-2 ............................................................ 1 2.0 PERFORMANCE BASELINES ESTABLISH DOE CORPORATE COMMITMENTS .. 2 3.0 DEVELOPMENT & MANAGEMENT AS KEY ACTIVITY IN PROJECT PHASES .... 3 3.1. Initiation ........................................................................................................................... 4 3.2. Definition ......................................................................................................................... 5 3.3. Execution .......................................................................................................................... 5

3.4. Closeout ............................................................................................................................ 5 4.0 THE PERFORMANCE BASELINE DEVELOPMENT PROCESS .................................. 5 4.1. People and Partnerships ................................................................................................... 6 4.2. Baselining Processes ........................................................................................................ 6 4.3. Tools and Methods ........................................................................................................... 7 5.0 TECHNICAL BASELINE DEVELOPMENT .................................................................... 7 5.1. Mission Need.................................................................................................................... 8 5.2. Identify Requirements and Evaluate Alternatives ............................................................ 9 5.3. Organize Project Requirements ...................................................................................... 10 5.4. Document Project Definition ......................................................................................... 10 5.5. Develop Design Basis .................................................................................................... 11 6.0 ESTABLISHING KEY PERFORMANCE PARAMETERS (KPPs) ............................... 11 7.0 SCHEDULE BASELINE DEVELOPMENT .................................................................... 12 7.1. Define Project Activities ................................................................................................ 13 7.2. Sequence Project Activities ............................................................................................ 14 7.3. Estimate Activity Durations ........................................................................................... 14 7.4. Conduct Network Analysis ............................................................................................ 15 7.5. Allocate Activity Resources ........................................................................................... 16 7.6. Establish Schedule Contingency .................................................................................... 17 8.0 COST BASELINE DEVELOPMENT .............................................................................. 17 8.1. Develop Estimating Basis .............................................................................................. 18 vi DOE G 413.3-5A 9-23-11 8.2. Develop Time-Phased Cost Estimate ............................................................................. 19 8.3. Escalation ....................................................................................................................... 19 8.4. Establish Cost Contingency ........................................................................................... 20 8.5. Review Estimates ........................................................................................................... 20 Appendix A. Glossary ................................................................................................................ A-1 Appendix B. References ............................................................................................................ B-1 Appendix C. Acronyms ............................................................................................................. C-1

DOE G 413.3-5A 1 9-23-11 1.0 BASELINES IN DOE PROJECT MANAGEMENT SYSTEMS Establishing a PB is a central feature of the DOE project management system. DOE O 413.3B promotes well-defined and managed project scope and risk-based PBs and stable funding profiles that support the original PB as one of its key project management principles. The Department’s ultimate objective is to deliver every project at the original PB on schedule, within budget, and fully capable of meeting mission performance, scope, design, key performance parameters (KPP), safeguards and security, quality assurance, sustainability, and environmental, safety, and health requirements. Consistent with this objective, it is DOE’s goal that a project will be completed at CD-4 within the original approved PB, unless otherwise impacted by a directed change. The original PB, in general, is established at CD-2. Revised PBs after CD-2 approval via BCPs should be avoided. . Refer to DOE O 413.3B, page A-19, Performance Baseline Changes. Performance baseline changes should be comply with change control procedures. Refer to DOE G 413.3-20¸ Change Control Management Guide. The term PB applies to defining project objectives; formalizing corporate DOE commitments via CD-2 approval; establishing a project’s readiness for obtaining commitment and funding from the Office of Management and Budget (OMB) and Congress; establishing change control authorities; and communicating project progress to a wide range of stakeholders. Refer to DOE O 413.3B, Table 2.2, page A-9, for CD-2 requirements. 1.1. Characteristics of Performance Baseline at CD-2 Regardless of type or sources of funding, a PB needs to be developed for each individual project. The project PB documents the high-level summary statement of the project’s key technical, schedule, cost, and performance parameters. It formalizes these elements and places them under formal change management procedures. The federal project director (FPD), along with the Integrated Project Team (IPT), and associated contract, engineering, design, safety, and management professionals develop the PB using an extensive and diverse collection of project planning processes and tools, requirements and assumption documents, resource loaded schedules, and detailed cost estimates to build reasonable and defensible plans to achieve project goals. The objective is to provide the acquisition executive (AE), for approval at CD-2, a complete and accurate baseline that can reasonably and confidently be achieved. The remaining sections of this Guide describe the significance of PBs as a DOE corporate commitment and place development activities in context of the overall project phases. Table 1.1 outlines the processes and products that can be used to develop the technical, cost, and schedule information needed to achieve the desired outcomes at CD-2. 2 DOE G 413.3-5A 9-23-11 Table 1.1. Characteristics of a Performance Baseline at CD-2 PB Element Characteristics at CD-2 Scope Work breakdown structure (WBS) encompasses all project scope and/or contractual scope requirements/work authorization defined to levels sufficient to support detailed cost and schedule estimates under formal change management procedures and configuration management. Design Is mature when a point estimate can be developed, can establish a high-quality, reliable cost and schedule estimate for a PB, and is ready for an independent review. Refer to

DOE O 413.3B, Figure 3, page C-6, Facility Design Maturity General Guidelines for CD-2. KPPs Primary KPPs defined, understood, and agreed to by the AE, Program sponsor, and FPD, and forms the requirements of the prime contract. Cost Total Project Cost (TPC) established with 70-90% confidence level. Higher confidence level should be considered for changes to the PB. Refer to DOE O 413.3B, page C-21. Schedule Project completion date established with 70-90% confidence level. Higher confidence level should be considered for changes to the PB. Refer to DOE O 413.3B, page C-21. Documentation All baseline documentations should be complete, approved by an appropriate authority, and effectively organized to enable traceability of supporting plans, assumptions, and analyses from the lowest to the highest level, and summary statement of the PB should be contained in the Project Execution Plan (PEP) or in the program requirements document (PRD) for NNSA projects. 2.0 PERFORMANCE BASELINES ESTABLISH DOE CORPORATE COMMITMENTS PB approval establishes the organization’s corporate commitments (based on the funding profile established at baseline) and defines cost, schedule, performance, and scope commitments for successfully delivering projects. Table 2.1 identifies key DOE project stakeholders for whom the PB serves as a corporate commitment. Table 2.1. Key DOE Project Stakeholders Key Stakeholders Nature of PB Commitment Congress The PB is a commitment to deliver on time and within budget and a justified investment of taxpayer dollars. OMB The PB is a result of realistic priorities; well coordinated plans and budgets; and provides measureable benefits. AE Project performance, scope, schedule, and cost are well defined, reasonable, and achievable. DOE Program Mission need will be satisfied. User Community End-state achieved will be reflective of the needs, inputs, and commitments. Regulators Regulatory requirements will be met. DOE G 413.3-5A 3 9-23-11 Baselining processes incorporate elements that are fundamental to project planning and execution in any organizational setting. These commitments are published in highly visible project documents and systems such as the PEP, OMB Exhibit 300s, Congressional Budget Requests, Project Data Sheets (PDS), and the Project Assessment and Reporting System (PARS). Refer to DOE G 413.3-15, Department of Energy Guide for Project Execution Plans, Departmental budget guidance, and PARS II guidance. The PB represents the Department’s commitment to Congress to deliver the project’s defined scope/KPPs by a particular date and at a specific cost. Estimates of PB elements in advance of CD-2 do not represent such commitments. Developing PBs allow: Effective coordination and integration of top-down and bottom-up planning, decision making, and documentation among diverse DOE organizations represented in IPTs (Headquarters, site offices, and contractors). Routine monitoring and reporting on all aspects of project performance by a large number of external oversight organizations (i.e., OMB, Government Accountability Office (GAO), Inspector General, Defense Nuclear Facilities Safety Board, Congress, etc.) Driving for improved project definition to ensure that requirements are progressively and rigorously refined to validate and approve PBs at CD-2. Establishing KPPs appropriate for the unique portfolio of DOE projects (nuclear weapons

stockpile stewardship; radiologic and hazardous waste cleanup; and large-scale, basic, and applied energy and scientific research facilities). Delivering a large number of first-of-a-kind projects that typically have a high degree of uncertainty, high cost, high impact on stakeholders, and high visibility. 3.0 DEVELOPMENT & MANAGEMENT AS KEY ACTIVITY IN PROJECT PHASES While the PB is formally established by the AE approval at CD-2, the PB development should begin at the earliest stages of a project. The planning process matures as more data and analyses provide greater definition and detail, relying on a continuous and iterative process throughout the project. The DOE acquisition management system for capital asset projects consists of four major phases - initiation, definition, execution, and transition/closeout. Refer to DOE O 413.3B, Figures 1 and 2 and alignment with CD approvals. The PB development is a key process leading up to CD-2, the original PB. The PB management (configuration control and change management) becomes a critical effort through the remainder of the project. 4 DOE G 413.3-5A 9-23-11 Table 3.1 illustrates the relationship of the PB components as the project progresses. The PB components should be clearly documented in the PEP or in the PRD, for NNSA projects, along with high-level assumptions and constraints. The original PB components and, if applicable, the latest approved PB component must be archived because they are the basis to determine if CD-4 is achieved. Further, the PB cost elements that are identified in the DOE Earned Value Management System (EVMS) Gold Card should be clearly documented. Refer to DOE G 413.3- 10, Earned Value Management System, Appendix B. Table 3.1. DOE Project Phases PB COMPONENT PROJECT PHASES Initiation Definition Execution Closeout Technical Baseline Preliminary functions and requirements from pre- conceptual design Preliminary design requirements baseline Final design requirements configuration baseline As-built configuration baseline KPPs Preliminary KPPs derived from technical goals based on the mission need Preliminary KPPs Final KPPs Demonstration of KPPs Schedule Baseline Order of magnitude project duration and forecast need date Preliminary schedule and milestones Complete schedule hierarchy Actual completion date Cost Baseline Order of magnitude cost estimate Preliminary cost estimates Final TPC estimate Actual project costs 3.1. Initiation In the initiation phase the project’s need is identified and justified, high-level objectives and functional requirements to meet those objectives are outlined, rough order-of-magnitude cost estimate ranges and a few key milestones are established, and project team formation begins. In this phase preliminary KPPs are used to describe and communicate the mission need to project stakeholders. After CD-0 is approved, the project may request funding as part of the budget process (e.g., using a PDS and Exhibit 300). DOE G 413.3-5A 5 9-23-11 3.2. Definition In the definition phase additional information is gathered or developed to enhance conceptual development; alternative courses for achieving project objectives are identified; design criteria are developed; more accurate estimates of technical scope, schedule and cost are developed for the identified alternatives; and value management/trade off study processes are typically

employed to refine project systems and functions. Accordingly, there should be more discrete KPPs based on the selected alternative. At this point the project team should begin to articulate and document a preliminary PB and begin some form of informal configuration management of key baseline parameters to start mapping baseline elements to supporting assumptions, plans, documentation, etc. 3.3. Execution In the execution phase a preliminary project design is finalized, a finalized technical baseline, work scope, and KPPs are created, and final cost and schedule baselines are established. Completion of full project definition indicates that the project has been adequately defined to commit resources. Once these elements are complete, the final PB is documented. Prior to CD-2 approval, for projects with a TPC of $100M or more, an External Independent Review (EIR) of the project PB, lead by the Office of Engineering and Construction Management (OECM) is required, and OECM will develop an Independent Cost Estimate (ICE) to support validation of the PB. For projects with a TPC between $50M and $100M, an Independent Project Review (IPR) by the program with a project management support office is performed on the project PB. Upon approval of CD-2, the PB sets the final course for the project and is subject to formal change management procedures. Accordingly, the PB is updated with each BCP. 3.4. Closeout When the project nears completion and has progressed into formal transition and commissioning, which generally includes final testing, inspection, and documentation, the project is ready for operation, long-term care, or closeout. The PB, and especially KPPs, serves as a basis for assessing, verifying, and documenting completion of the project. 4.0 THE PERFORMANCE BASELINE DEVELOPMENT PROCESS The PB development process should be a continuous, iterative, and recursive process. For any PB development effort to be successful it should be developed by motivated and qualified people, follow well-defined processes, be subject to rigorous quality assurance requirements and processes, and be supported by the careful consideration and application of appropriate project definition tools. PB development is a demanding effort that requires the constant engagement and expert technical direction by the owner Program Organization; strong leadership by the AE, the FPD, and creative, dedicated support by the IPT. Accordingly, qualified staff (including contractors) must be available in sufficient numbers to accomplish all contract and project management 6 DOE G 413.3-5A 9-23-11 functions. Project staffing requirements should be based on a variety of factors. Refer to DOE G 413.3-19, Staffing Guide for Project Management, for additional guidance. 4.1. People and Partnerships Personnel involved in the PB development process have a major effect on the accuracy, completeness, and overall quality of the final deliverables. Roles and responsibilities should be clearly defined, understood, and accepted. Individuals with the appropriate capabilities and experience should be engaged in all phases of the PB development and proactive communication is a necessity. Many project management studies have identified the need to align all parties to the project goals and objectives as a prerequisite for project success. Many studies have gone further by suggesting that project roles are most effectively executed when relationships among participants

are viewed as partnerships. 4.2. Baselining Processes The overall processes have been developed by contractors at major DOE installations and the process has been shared and adopted informally by project management organizations. The overall baselining process has been packaged into workflows similar to the diagram in Figure 4.1, and supports the GAO-09-3SP 12 steps of the cost estimating process. Project Baseline Components Develop Mission Need Statement Identify Requirements and Evaluate Alternatives Define Project Activities Program Mission Select Alternative Organize Project Requirements Go Document Project Definition Develop Design Basis Summary Sequence Project Activities Estimate Activity Durations Conduct Network Analysis Allocate Activity Resources Recycle` NO Establish Schedule Contingency Develop Estimating Basis Develop Time-Phased Cost Estimate Calculate Escalation Establish Cost Contingency Review Estimate Develop Total Estimated Cost and TPC Technical Baseline Schedule Baseline Cost Baseline Baseline Documents P re lim in a ry Disposition Alternatives Figure 4.1. Overall Performance Baseline Development Process DOE G 413.3-5A 7 9-23-11 4.3. Tools and Methods The tools and methods used by project teams are extensively reported in the literature and are included here, grouped into categories, only to highlight those most common and to provide a starting point for further research: Front-end planning (project/scope definition ratings; gap analysis; benchmarking, checklists). Two specific tools are provided below: o The Project Definition Rating Index (PDRI) to assess the project definition. Refer to DOE G 413.3-12, Project Definition Rating Index Guide. o The Technology Readiness Assessment (TRA) to assess the maturity level of a new proposed technology. Refer to DOE G 413.3-4, U.S. Department of Energy Technology Readiness Assessment Guide. Systems engineering (functional analysis; requirements definition; configuration management). Alternatives analyses (life-cycle cost analysis; cost-benefit analysis; trade studies). Refer to DOE G 413.3-7A, Risk Management Guide, and DOE G 413.3-21, Cost Estimating Guide, for additional information. 5.0 TECHNICAL BASELINE DEVELOPMENT The technical baseline defines technical goals, objectives, and scope, and provides the basis for estimating project cost and schedule. Development should encompass project team actions necessary to identify, define, integrate, and document the project mission, functional objectives, design requirements, and detailed specifications in order to define, execute, and control the technical method of accomplishing the project’s scope of work. A well-defined and documented technical baseline is a key factor for ensuring project success. It should be established in such a way that technical requirements can be understood, broadly communicated, and effectively controlled throughout the life of the project. The technical baseline should include design requirements, criteria, and characteristics that provide the basis for project definition. The DOE O 413.3B process is based on industry methods of conducting iterations of requirements during each project phase. As requirements are defined, design and/or studies are conducted to gain more project knowledge, and refinement of requirements is made based on the designs and/or studies. An iteration of these steps, providing more detail, occurs for each

phase throughout the project until final and mature systems architecture is achieved. 8 DOE G 413.3-5A 9-23-11 This iterative project planning process should start by defining the project’s mission need. Once internal and external stakeholders understand and commit to the mission need, the project team identifies functional requirements, evaluates alternatives for satisfying requirements, conducts appropriate analyses, and recommends a preferred alternative. Evolving technical requirements and supporting assumptions should be captured initially in informal but complete scoping documents and then after conceptual designs have been approved, they should be incorporated into a formalized technical baseline. The IPT should ensure that as the scope and technical requirements become better defined, they trace back to the mission need and functional requirements developed earlier in the project definition effort. The IPT should use a graded approach for determining the level of detail required for technical baselines. Additionally, information in all technical baselines should be traceable to clearly identifiable assumptions, a methodology that is consistent with industry standards, and well- documented supporting information. The benefit of the iterative process is that internal and external stakeholders can agree on high-level requirements before spending significant time and effort defining any particular alternative. Project requirement identification and definition are two of the most critical elements of PB development. Not achieving agreement on the path forward early in the project definition process can cause significant cost increases or schedule delays later in the process. The technical baseline development process is described in Figure 5.1. 5.1. Mission Need The mission need defines the project’s high-level technical goals and requirements and should: provide direction for future planning, engineering, and decision making; initiate more detailed technical definition - project requirements, project definition, and design basis - that guide cost and scheduling estimating; and help build commitment and buy-in from project stakeholders. Mission need should clearly and concisely identify project purpose, goals, and benefits to ensure that the rationale justifying the project is easily understood. DOE G 413.3-5A 9 9-23-11 Develop Mission Need Statement Identify Requirements and Evaluate Alternatives Organize Project Requirements Document Project Definition Develop Design Basis Summary Clearly stated project goals Anticipated results/ benefits Integration w/ other projects High-level cost/ schedule High-level functional reqts. Define what must be done Define how well it must be done Examine reasonable range of alternatives Verify alternative meets reqts. Rank alternatives and select one Definition of objectives Description of alternative Functional, performance, & other reqts. Applicable permit/ license reqts., regulations, codes, and standards Identify and assess constraints Technical description Design criteria Statement of work Tech. standards and specifications Eng. control drawings and design documents Technical description WBS with dictionary Changes from prelim. reviews Engineering control drawings Site infrastructure reqts. Preliminary method of accomplishment Performance measures/criteria Long-lead procs. identified

WBS and all info. for cost/schedule estimates Performance measures/criteria Recycle Go No Select Alternative Disposition Alternatives Figure 5.1. Overall Performance Baseline Development Process 5.2. Identify Requirements and Evaluate Alternatives At this stage, it is a good practice to identify and screen alternatives to increase the likelihood of satisfying project objectives. Alternative evaluations should identify a single approach that fulfills the mission need in the most effective manner (cost, time, and operationally). In some cases, the alternatives may be competing concepts or simply variations on a common approach. A high-level definition of each alternative should be developed sufficiently to permit an informed selection. At the conclusion of the identification and evaluation activities, the best alternative that safely fulfills the mission in the most effective manner should be selected. In some cases, it might be necessary to carry forward a limited number of short-listed alternatives to address major uncertainties that require further design development to resolve. Project objectives are drafted and revised throughout the alternative evaluation and selection phase. These objectives ultimately become the basis for developing project requirements. The evaluation and selection of alternatives lends itself to a systems engineering approach that transforms project objectives into an operational system. Through systems engineering, an identified mission can be transformed into system performance parameters and a preferred system configuration by an iterative process of definition, synthesis, analysis, design, and evaluation. The approach integrates related technical parameters to ensure compatibility of all physical, functional, and program interfaces in a manner that optimizes the total system definition and design. The basic systems engineering process functional flow is as follows: 10 DOE G 413.3-5A 9-23-11 Define what must be done (e.g., construct or demolish within defined physical boundaries); Define how well it must be done (e.g., performance specifications such as speed or volume output requirements); Evaluate alternatives for getting it done; Rank alternatives and select a solution; and Verify that the proposed solution meets the requirements. 5.3. Organize Project Requirements Clearly defining project requirements at the earliest time in project execution is essential to ensure that objectives and design criteria are complete and consistent by translating mission need into a technical plan. The requirements clearly articulate a set of technical expectations that guide overall project definition. The project objectives should be stated as measurable goals, performance parameters, or end states. Multiple objectives may be prioritized into primary and secondary objectives. Primary objectives are the ones without which the project would not be undertaken. Secondary objectives are additional benefits, but are not sufficient to justify the project. By categorizing objectives in this way and then ranking them, the IPT establishes design priorities. Design criteria relate project objectives to technical design requirements to ensure that all design efforts will be developed in an orderly fashion. The primary purpose of the design criteria is to focus the design effort. Development of design criteria is generally the first effort to formalize

the technical approach and performance requirements for the project. 5.4. Document Project Definition Project definition should focus on defining the selected alternative to the level of detail necessary to ensure that the functional requirements, design criteria, major physical attributes, and performance parameters are clearly established. Engineering drawings and specifications should be developed to control engineering and field construction. When project definition activities are complete and a design basis document issued, the project should be adequately defined to commit resources to the final detailed design, execution, completion, closure, and/or operational activities. Assessing the project definition utilizing the PRDI and the maturity level of a new proposed technology are critical prior to the execution phase and CD-2. A formal Value Engineering (VE) review is conducted when the design effort has progressed to the point when detailed drawings, hardware definition, and layouts are available. Although VE reviews can and should be conducted at other times, the most opportune time is relatively early in project definition when changes can be made without substantial cost or schedule impact. DOE G 413.3-5A 11 9-23-11 In practice, the end of project definition is traditionally marked by the selection of an alternative and completion of the conceptual design. If the engineering effort is carried beyond this milestone, the project runs the risk of committing resources that may be abandoned if the project is not formally approved. Proceeding with less engineering effort runs the risk of committing resources before a project is adequately defined with valid baselines. Accordingly, the level of project definition has a direct correlation with the range of accuracy for the cost and schedule estimates. Developing a WBS is an essential element of project definition. The level of detail included in the WBS should be sufficient to develop resource loaded schedules. To ensure common interpretations of WBS activities, the WBS should be accompanied by a dictionary that defines all elements of the WBS. Good project definition practices are essential to limiting the impact of project changes. At the end of project definition, the project should have developed sufficient design detail to freeze the scope from that point forward. Design changes that occur after the definition are both expensive and time-consuming. It should be the goal of the project team to minimize late design changes. 5.5. Develop Design Basis The design basis is a comprehensive technical project description including reviewed and approved engineering design drawings. This package provides the appropriate level of definition necessary to approve an Architectural and Engineering contractor to begin detailed engineering designs, represents completion of project definition, and marks the beginning of the execution phase. Technical requirements are finalized during the development of the design basis summary; should provide sufficient detail to ensure that defined objectives are achieved and an accurate work scope is furnished to direct execution phase efforts; and should be developed thoroughly enough to ensure a high probability of project execution success and minimize the probability of scope changes. 6.0 ESTABLISHING KEY PERFORMANCE PARAMETERS (KPPs) Traditionally, in DOE, a project “baseline” was comprised of three components - technical, cost,

and schedule - each of which is related to the others. Recently, the requirement to establish KPPs has become a prominent feature of DOE project management. The KPPs, in DOE O 413.3B, are defined as a vital characteristic, function, requirement or design basis that if changed, would have a major impact on the facility or system performance, scope, schedule, cost and/or risk, or the ability of an interfacing project to meet its mission requirements. A parameter may be a performance, design, or interface requirement. Appropriate parameters are those that express performance in terms of accuracy, capacity, throughput, quantity, processing rate, purity, reliability, sustainability, or others that define how well a system, facility, or other project will perform. In aggregate, KPPs comprise the scope of the project. 12 DOE G 413.3-5A 9-23-11 KPPs are defined in terms of what is desired and what is required. Each KPP succinctly and in quantitative terms, if possible, states the desired objective value and the associated minimum threshold value. The objective value is the desired performance, scope, cost, or schedule that the completed asset should achieve, whereas the threshold value is more conservative representing the minimum acceptable performance, scope, cost, or schedule that an asset must achieve. The objectives and thresholds form the boundary condition within which the project manages to completion - striving to meet the objectives, but achieving at least the minimum thresholds. The IPT can trade within this space to maintain the performance, scope, cost, and schedule requirements. In other words, performance can be traded-off to control cost or schedule. However, trade-offs must never compromise the threshold values, which are the minimum required to meet the mission and form the essence of the commitment to Congress. Accordingly, KPPs are a basis for the CD-4 approval criteria. Any change in scope and/or performance that affects the ability to satisfy the mission need or are not in conformance with the current approved PEP and PDS requires senior AE approval. KPPs should be identified during the concept development phase. They are a result of the analysis which leads the IPT to the conclusion that a particular concept is the appropriate solution that will meet the required mission need. The total number of KPPs should be the minimum number needed to characterize the major drivers of project performance. The number and specificity of performance parameters may change over time. Early in PB development, the KPPs should reflect broadly defined, operational-level measures of effectiveness or measures of performance to describe needed capabilities. As a project matures, system-level requirements may provide a better basis for establishing KPPs. KPPs not only define the technical performance of the ultimate project deliverable (e.g., site end- state, facility capability), they also play a significant role in driving PB development and establishing measures for formal baseline change control. It is important for the Program sponsor (typically possessing technical understanding and expertise) to provide strong leadership in the development and agreement on KPPs. The more technically complex the project is, the more the owner needs to be involved. 7.0 SCHEDULE BASELINE DEVELOPMENT The schedule baseline establishes the overall project duration and completion date. It should

clearly identify critical path activities and key project milestones. A tailored approach should be used to determine how much detail to include in the schedule. The number of activities should not be so few as to prevent suitable progress tracking and not so numerous that the number of activities overwhelms the system and its users—rendering the schedule logic incomprehensible and too burdensome to status. The schedule should reflect planning by appropriate technical experts as to how the activities will be accomplished. DOE G 413.3-5A 13 9-23-11 All known project and contract requirements, major procurements, milestones, and constraints should be identified during the planning and scheduling process. Activities external to the project that could reasonably be expected to impact the project should also be considered. The overall schedule baseline development process is described in Figure 7.1. 7.1. Define Project Activities An activity is a basic element of work that consumes time and resources and has a definable beginning and end. Activities are performed in order to produce the results and deliverables identified in the project WBS. The activities necessary to accomplish a defined scope of work are often based on historical information from similar projects that have been modified to meet the constraints and assumptions of the current effort. Define Project Activities Conduct Network Analysis Allocate Activity Resources Detailed Activity List Brief Activity Descriptions Documented Roles and Responsibilities Supporting Activity Detail Estimate Activity Durations Activity Resource Requirements Most Likely Duration Estimates Range Estimates Sequence Project Activities List of Logical/ Technical Requirements List of Inter-Activity Dependencies Activity Sequence Establish Schedule Contingency Network Diagram Activity BOEs Project Calendars List of Activity Constraints List of Resource Constraints Resource Loaded Schedule List of Activity Criticality Indices Resource Leveled Schedule Compressed Schedule (Optional) Early and Late Start/Finish Dates Project Critical Path Activity and Project Float Risk Factors Sensitivity Analysis Risk Methodology Contingency Allocation Figure 7.1. Schedule Baseline Development Process The definitions of these activities should flow from the project planning and scope definition processes, and the level of definition will depend on the project phase. Some of the major components of the activity definition process are listed below: Identification - A list of activities should be developed based on historical site information or data from a similar project. In some cases, generic project activity templates may facilitate the identification process. When determining the appropriate level of detail, the project team should strike a balance between the need to decompose projects into a number of activities sufficient to facilitate accurate cost estimating and scheduling, and the ability of project management and control systems to maintain effective traceability and reporting capabilities. Description - Activity descriptions should be brief but unambiguous and should include quantitative measures or reference points whenever possible. 14 DOE G 413.3-5A 9-23-11 Detail - Supporting details should be documented and included in the cost and schedule estimating files. This information, including all assumptions and constraints, will be necessary

for ensuring the future traceability and defensibility of estimates, for managing change control procedures, and for performing activity resource loading and leveling procedures. In addition, the owner of each activity (i.e., the project team member responsible for ensuring activity completion) should be documented as part of the description. 7.2. Sequence Project Activities Sequencing involves the development of chronological relationships among project activities based on the technological, organizational, and contractual requirements governing their completion. A sequence of activities is best displayed graphically in the form of a network diagram. Three common methods of network diagramming include arrow, node, and precedence diagrams. Activities should be sequenced logically to establish the foundation for an achievable project work plan. A sequence of activities in the form of a network diagram is necessary for performing critical path, total float, and resource leveling analyses. The results of these analyses are implicitly tied to the mandatory, discretionary, and external dependencies identified by the project team and included in the network schedule. Activity sequencing is driven by technological characteristics and requirements of the products, processes, and deliverables comprising the project scope. These may include the physical layout of a plant to be constructed, infrastructure requirements of an existing facility, or cleanup and disposal requirements of a contaminated release site. In addition to these technical requirements, administrative, organizational, regulatory, and legal requirements may drive the necessary completion dates of milestone activities. These requirements should be documented in the form of activity dependencies, constraints, and assumptions, and should be reflected in the sequencing of the network schedule. The project team should discuss and establish a realistic sequence of events for the completion of activities based on inter-activity dependencies. 7.3. Estimate Activity Durations Estimates of the time required to perform each project activity are based on assumed labor, equipment, efficiency and productivity, and material requirements and availability. These durations may take the form of a single point estimate describing the mean or most likely number of work periods needed to complete an activity (e.g., based on historical data), or may be defined by a range estimate that captures a continuum of durations spanning from the most optimistic to the most pessimistic as conceived by one or more subject matter experts on the project team. Similar to the sequencing of activities, estimating activity durations is essential for developing a sound project schedule. Because of the inter-activity dependencies inherent in network scheduling, the effects of poorly defined duration estimates can be compounded through precedence relationships and milestone constraints. Successful critical path and resource leveling analyses are therefore directly dependent upon the accuracy of the duration estimating process. DOE G 413.3-5A 15 9-23-11 Activity durations should be estimated by the project team member most familiar with the nature of a specific activity and who is responsible for ensuring its completion. The duration of most activities will be significantly influenced by both the amount of resources applied to a task (e.g.,

part-time versus full-time, single versus multiple crews) and the capabilities of those specific resources (e.g., novice versus experienced laborers). These trade-offs should be considered and documented during the estimating process; however, they may be adjusted later during a resource allocation exercise. Whenever possible, duration estimates should be based on expert judgment that is supported by historical information contained in project files or commercial estimating databases. The duration estimates provide the basis for performing critical path scheduling calculations. The basis of estimate (BOE) used to develop each activity estimate (i.e., the resource requirements, assumptions, and constraints driving the estimated duration) should be documented in an accompanying project file. This information will be essential for maintaining the traceability and defensibility of the estimates during later project phases, especially for change control and reporting purposes. 7.4. Conduct Network Analysis The critical path is the longest path through a network schedule that consequently defines the shortest possible duration for completing a project. This path and its duration are determined by performing forward and backward passes through the network diagram based on the defined activity sequence and estimated activity durations. The basic scheduling computations performed on a network diagram provide the earliest and latest allowable start and finish times for each activity and as a by-product, indicate the amount of slack or float time associated with each noncritical path. This information forms the basis of the project management plan and subsequently is used for performance measurement and earned value reporting, baseline change control, milestone tracking, and schedule contingency management. The mathematical analysis involved in calculating theoretical early and late start and finish dates for all project activities should be performed initially irrespective of resource pool limitations. The resulting dates indicate the time periods within which the activities should be scheduled provided existing resource limitations and other known constraints are met. These calculations, generally performed by scheduling software applications, require several input parameters: Calendars - Project calendars establish the periods when work will be performed. This is essential because some resources will be available only during normal business hours, while others may be available continuously, on weekends and holidays, or in some other combination. Constraints - Imposed dates and major milestones are constraints to consider. Imposed dates are driven by completion of activities and deliverables assigned by sponsors, customers, or other external entities. Major milestones are key events or deliverables established by project owners or stakeholders to meet organizational, funding, or other commitments. Both can be used to constrain the network schedule but may result in trade-offs in the form of additional resources in 16 DOE G 413.3-5A 9-23-11 order to be met. Application on constraints should be used with restraint since this will limit the schedule from following the natural paths of the activities. Leads and Lags - Activities requiring significant lead or lag times (e.g., procurement of specialty items, curing of concrete prior to further structural work, receipt of laboratory testing

results to determine further cleanup requirements) should be specified in the project schedule, and these delays should be reflected in the associated network logic. 7.5. Allocate Activity Resources The feasibility of a network schedule should be validated with respect to labor, equipment, and material requirements not explicitly considered in the initial critical path analysis. The process of allocation is used to distribute resources across multiple project activities within known limits and expected constraints. Some activities may be re-sequenced to compress the schedule and/or to obtain a more level distribution of resources. Critical path computations performed during the network analysis determine the slack along each path in the project schedule. Based on the length and location of this slack, certain activities can be moved forward or backward in time without affecting the completion date of the project. Consequently, this movement can be used to develop a schedule that satisfies external constraints placed on the type and quantity of resources available during various phases of the project. Resource allocation often entails several iterations of the basic scheduling computations and should include modification of some project activities to achieve an acceptable plan (i.e., one that meets all milestone dates and externally imposed constraints without exceeding the available labor, material, and equipment levels). Leveling heuristics should be used to rebalance resources based on anticipated quantity thresholds and the relative criticality of activities; however, these heuristics often produce project durations that are longer than the initial schedule. Schedule compression is another form of resource allocation that seeks to shorten the project schedule without changing its scope. This process includes techniques such as the following: Crashing—Schedule crashing requires the analysis of trade-offs between cost and schedule to determine how the total project duration can be reduced by the greatest amount for the least incremental cost. This technique, which is available in most automated scheduling tools, does not always produce a viable project schedule and usually results in greater TPCs. Fast Tracking—This technique involves the re-sequencing some activities in the schedule so that they are performed in parallel rather than in sequence during project execution. The negative consequences include increased project risk and some rework resulting from technical uncertainties and activity sequencing problems. The project team should evaluate the decision to fast track carefully and it should be used primarily on projects with well established and proven technologies. DOE G 413.3-5A 17 9-23-11 7.6. Establish Schedule Contingency Schedule contingency is the amount of time identified within the project schedule to compensate for the potential for schedule risk factors such as technical data gaps, infrastructure constraints, labor productivity levels, labor availability, project complexity, stakeholder involvement, excessive scope changes, regulatory delays, and constructability issues. The amount of contingency to be included in the baseline schedule depends on the status of the project design, procurement, and construction and the complexity and uncertainty of various baseline elements. The duration of the project’s critical path determines the shortest possible schedule for a given

baseline. Results provided by the critical path method are accurate only when everything goes according to plan. A project, on occasion, may provide very optimistic duration estimates and plan parallel work without full considerations for the unique scheduling and work execution complexities posed by parallel activities. The project schedule therefore should contain some amount of contingency to account for the potential impacts of risk and uncertainty. Schedule contingency should explicitly address the risks identified by the project team during the schedule development and risk management efforts, especially those factors that are likely to have the greatest impact on project execution as determined by a sensitivity analysis. The quantification of schedule contingency can be developed using the Monte Carlo simulation method. To perform such simulations, the project team should estimate a range of durations for each activity to be included in the risk analysis. These estimates should reflect the full variability of activity durations, from the most optimistic prediction to the most pessimistic. Using a computer-based simulation tool, basic scheduling calculations are performed using activity duration values sampled from the range estimates. The resulting critical path durations are recorded to determine the relative completion probabilities for a range of project finish dates. Based on the desired level of confidence in meeting the schedule, the project team selects an appropriate amount of schedule contingency. The contingency allocation process is managed and documented through the baseline change control system, and the network schedule should be updated to reflect the most current field conditions throughout the project phases. 8.0 COST BASELINE DEVELOPMENT The cost baseline supports the development of the TPC and is established to ensure that costs and budgets for labor, services, and materials are defined and time-phased based. While the technical baseline ensures that technical requirements are focused on achieving the project mission, the cost baseline supports corporate planning, budgeting, and reporting processes. For instance, estimates provide the basis for formulating annual budget requests, establishing the project and activity resources, hours and quantities that are used to develop the schedule and quantitative units to be measured, evaluating contract bids and proposals, providing a sense of scale that often aids in understanding the overall scope of a project, and evaluating the impact of change to the PB. 18 DOE G 413.3-5A 9-23-11 Fundamental estimating skills and knowledge should be reinforced as a basis for estimating and controlling costs. Well documented BOE and the consistent application of rigorous estimating methods are significant defenses against concerns for estimate accuracy and credibility. The overall cost baseline development process that supports the GAO-09-3SP 12 steps of the cost estimating process is described in Figure 8.1. Prior to CD-2 approval, for projects with a TPC of $100M or more, OECM will develop an ICE to support validation of the PB. Develop Estimating Basis Develop Time- Phased Cost Estimate Establish Cost Contingency Review Estimate Project Description General Design Criteria Type of Estimate Cost Data Sources/ Code of Accounts Identify Summary Level Activities Resource Load Summary Activities Organize Time- Phased Cost Estimate

Define Contingency Describe Methodology Completeness/ Reasonableness Calculate Escalation Determine Escalation Rate(s) Escalation Methodology Document Escalation Document Total Estimated Cost and TPC Organize Cost Estimate Components Seek Qualified Peers Estimate and Document OPCs Checklists Provide Justification, if necessary Document Contingency Amount Develop Annualized Cost Estimates Assumptions and Cost Drivers Cost Estimate Documentation Estimate Methodology Figure 8.1. Cost Baseline Development Process 8.1. Develop Basis of Estimate The BOE documents known project information, assumptions, and methodologies and identifies links to supporting documentation when the estimate is developed and updated. Specifically, the BOE should provide a description of the project, general design criteria, project phase and type of estimate, date of the estimate, cost estimating methodology/tools, cost estimate data sources, WBS, significant features or components, proposed method of accomplishment, proposed schedule/milestones, regulatory drivers, resource requirements/availability and associated costs, assumptions, and other facts that may impact costs. The level of detail in the cost estimate should be consistent with the project phase or degree of project definition. This approach offers the greatest level of detail in the near-term to support current year work plan development and annual budget formulation. Top-down or parametric cost estimating can be used to support out- year life-cycle planning if necessary. DOE G 413.3-5A 19 9-23-11 Estimators should work closely with the project team to understand the influences that the technical (e.g., scope definition) and schedule (e.g., activity definition/duration) baselines have on the cost estimate. As the project matures and designs are finalized, the initial cost estimate parameters can be compared to current conditions. Changes to scope, schedule, and cost planning should be identified as part of the estimate and especially at estimate reviews. If necessary, a revised cost estimate should be prepared. Investment in developing a well defined BOE pays dividends by improving communication among project team members and with key stakeholders; highlighting items that significantly influence the estimate; and avoiding confusion over what is and is not included in the estimate. 8.2. Develop Time-Phased Cost Estimate Each project activity has a duration (planned start and expected finish dates) and a cost for resources (labor, materials, equipment) associated with it. When duration and cost are linked together, a profile that defines the project cost over time is produced. The time-phased cost profile (e.g., resource-loaded schedule) can be used to develop a funding profile for those project activities with a schedule duration of greater than a year. This is important for multi-year projects where annual budget requirements are developed, reviewed, justified, and appropriated through an annual budget formulation process. In some projects, a constrained funding profile may be provided . If this is the case, the funding profile should be based on and commensurate with the work to be performed. Once project activities have been resource-loaded the process of resource leveling or rescheduling activities based on resource limitations is extremely valuable in balancing labor and equipment requirements with schedule production requirements. It can also be used to ensure

that project planning is consistent with the realistic out-year funding expectations while maintaining regulatory compliance in the project baseline. 8.3. Escalation Escalation is the provision in a cost estimate for increases in the cost of equipment, material, labor, etc., due to continuing price level changes over time. Escalation is used to estimate the future costs of a project (predictive or forecast) or to state historical costs in current year dollars. Since the duration of larger projects can extend over several years, a method of forecasting or predicting the funds should be developed to allow for the comparison of project costs from different time frames. Escalation should be applied to each activity of an estimate and shown as a separate line item. Most cost estimating is done in current dollars and then escalated to the time when the project will be accomplished. The cost estimate should clearly identify the escalation rate used, the source, relationship to the WBS and schedule, assumptions made, and the rationale for their use. Two basic methods for calculating and applying escalation include: 20 DOE G 413.3-5A 9-23-11 Midpoint of Activity - Escalation may be applied from the date an estimate was prepared to the midpoint of the performance schedules for the major work elements. Separate Escalation by Year - Activities escalated yearly/annually. Cost of escalation for capital construction projects are calculated by establishing a midpoint for the project, and applying the yearly escalation to the midpoint of the project. In this case the impact of escalation is “averaged” over the life of the project. 8.4. Establish Cost Contingency As an integral part of a cost estimate, contingency should be included and clearly identified in the TPC. The amount of contingency is a reflection of management judgment on how best to address the probability of a project cost overrun. Contingency does not cover scope changes, but rather is an estimate based on the available scope definition and the phase of the project. DOE cost estimating directives recognize that project and operations estimates should always contain contingency. When including contingency in cost estimates meets with resistance, in some instances, contingency is hidden in the estimate by inflating activity quantities, costs, or resources, which leads to poor estimates that lack credibility. DOE guidance advises that contingency analysis be performed to ensure that appropriate allowances are included in the baseline cost estimates. The contingency analysis should indicate the rationale or process used to reach the conclusion. Approaches to contingency estimates range from formal risk-based analysis to project definition rating or scoring. A graded approach can be used in selecting a method depending on the complexity, cost, and phase of the project. It should also be noted that the cost value of schedule contingency will result in additional cost contingency and needs to factor into the cost baseline. Contingency should decrease over time as the project matures and project scope is more clearly defined. Contingency management includes establishing a process for reviewing, approving, and tracking the distribution of contingency. Change control thresholds can be established to identify the approving authority for requested changes to contingency. Tracking tools such as contingency registers can be used to monitor the status of contingency.

8.5. Review Estimates Well-executed estimate reviews will increase credibility and accuracy of the estimate, and will also help the project management team better understand the level of scope definition and the basis for the estimate. The review of estimates is important because it helps estimators understand the contents and level of accuracy of the estimate. The number of reviews will vary depending on the size of the project, type of estimate, length of time allowed for preparing the estimate, and other factors. For any estimate there should be both an internal review during development of the estimate and a final review at or near completion of the estimate. DOE G 413.3-5A 21 9-23-11 About halfway through the development of the estimate, a “reality check” should be scheduled. The purpose of this mid-point check is to avoid spending unnecessary time and money in pursuing an estimate that may be unrealistic or based on assumptions that are no longer valid. The internal mid-point estimate review is brief. Typically, the lead estimator, engineer, and project manager are involved. There may be times when it is advantageous to include other project stakeholders. This review is intended as a reality check of the data being developed to assess whether to proceed with the estimate. This is a “go/no go” point, where the results of the review will guide the estimator and the project team in following two steps: Either recycle back to the “scope of work” because the cost or scope has gotten outside of the boundaries established as a target for the project; or Go ahead with the remaining estimate process to complete the estimate. The final estimate review is a more structured process. The depth of the review depends on the type or class of estimate that is being prepared. The review is intended to validate assumptions, such as construction sequence, key supplier selection, and owner’s cost. Engineering and the customer should accept ownership of the scope that is represented in the estimate. The final estimate review may require significant time. The attendees should include the lead estimator, process engineer, discipline engineer, operations/maintenance representative, engineering manager, and constructability leader. The estimator should come to the review meeting prepared with the following information for comparisons: Historical data used in preparing the estimate (Such as the EM Environmental Cost Analysis System (ECAS) historical cost database which is available to DOE users.) Actual costs of similar projects Percent of cost on key cost accounts Comparisons of the estimate with the above information provide useful indicators for the estimate review. In some situations it may be desirable to use outside reviewers such as an experienced peer group to validate assumptions, key estimate accounts, construction sequence, and potential omissions. In other situations a third party may be engaged to perform an independent review. The reviews will provide a check to compare the estimate with past similar estimates from the perspective of a different team. Estimate reviews should focus on the big picture and follow Pareto’s Law by separating the significant few from the trivial many. Generally an estimate is prepared bottom-up, whereas the review is conducted top-down. DOE G 413.3-5A Appendix A 9-23-11 A-1 (and A-2) APPENDIX A. GLOSSARY 1. Cost Baseline. A budget that has been developed from the cost estimate that is

time-phased, supports the technical baseline, and is traceable to the WBS. 2. Key Performance Parameter (KPP). Refer to DOE O 413.3B, page C-13. 3. Performance Baseline (PB). Refer to DOE O 413.3B, pages C-14 and Attachment 2, page 9. 4. Performance Measurement Baseline (PMB). Refer to DOE O 413.3B, Attachment 2, page 10. 5. Schedule Baseline. The time-phased plan based on a logical sequence of interdependent activities, milestones, and events necessary to complete the project. 6. Technical Baseline. Performance and design requirements, criteria, and characteristics derived from the mission need that provides the basis for project direction and execution, and aligns with the contractual scope requirements. 7. Work Breakdown Structure (WBS). Refer to DOE O 413.3B, Attachment 2, page 14. DOE G 413.3-5A Appendix B 9-23-11 B-1 (and B-2) APPENDIX B. REFERENCES 1. DOE O 413.3B, Program and Project Management for the Acquisition of Capital Assets, 11-29-2010. 2. DOE G 413.3-4, Technology Readiness Assessment Guide, 10-12-2009. 3. DOE G 413.3-7A, Risk Management Guide, 01-12-2011. 4. DOE G 413.3-10, Earned Value Management System (EVMS), 05-06-2008. 5. DOE G 413.3-15, Project Execution Plans, 09-12-2008. 6. DOE G 413.3-12, Project Definition Rating Index Guide for Traditional Nuclear and Non-Nuclear Construction Projects, 07-22-2010. 7. DOE G 413.3-19, Staffing Guide for Project Management, 06-03-2010. 8. DOE G 413.3-21, Cost Estimating Guide, 05-09-2011. 9. Departmental budget guidance, http://www.cfo.doe.gov/crorg/cf30.htm. 10. PARS II guidance, http://management.energy.gov/online_resources/pars2.htm. 11. GAO-09-3SP, GAO Cost Estimating and Assessment Guide – Best Practices for Developing and Managing Capital Program Costs, dated 03-2009. http://www.cfo.doe.gov/crorg/cf30.htm http://management.energy.gov/online_resources/pars2.htm DOE G 413.3-5A Appendix C 9-23-11 C-1 APPENDIX C. ACRONYMS AE Acquisition Executive BCP Baseline Change Proposal BOE Basis of Estimate CD Critical Decision DOE Department of Energy EIR External Independent Review EVMS Earned Value Management System FPD Federal Project Director GAO Government Accountability Office ICE Independent Cost Estimate IPR Independent Project Review IPT Integrated Project Team KPP Key Performance Parameter O Order OECM Office of Engineering and Construction Management OMB Office of Management and Budget PARS Project Assessment and Reporting System PB Performance Baseline PEP Project Execution Plan PDS Project Data Sheet PDRI Project Definition Rating Index PRD Program Requirements Document SOW Statement of Work TPC Total Project Cost Appendix C DOE G 413.3-5A C-2 9-23-11 TRA Technology Readiness Assessment VE Value Engineering WBS Work Breakdown Structure FOREWORD PURPOSE SCOPE 1.0 BASELINES IN DOE PROJECT MANAGEMENT SYSTEMS 1.1. Characteristics of Performance Baseline at CD-2 2.0 PERFORMANCE BASELINES ESTABLISH DOE CORPORATE COMMITMENTS 3.0 DEVELOPMENT & MANAGEMENT AS KEY ACTIVITY IN PROJECT PHASES 3.1. Initiation 3.2. Definition 3.3. Execution 3.4. Closeout 4.0 THE PERFORMANCE BASELINE DEVELOPMENT PROCESS 4.1. People and Partnerships 4.2. Baselining Processes 4.3. Tools and Methods 5.0 TECHNICAL BASELINE DEVELOPMENT 5.1. Mission Need 5.2. Identify Requirements and Evaluate Alternatives 5.3. Organize Project Requirements 5.4. Document Project Definition 5.5. Develop Design Basis 6.0 ESTABLISHING KEY PERFORMANCE PARAMETERS (KPPs) 7.0 SCHEDULE BASELINE DEVELOPMENT 7.1. Define Project Activities 7.2. Sequence Project Activities 7.3. Estimate Activity Durations 7.4. Conduct Network Analysis 7.5. Allocate Activity Resources 7.6. Establish Schedule Contingency 8.0 COST BASELINE DEVELOPMENT 8.1. Develop Basis of Estimate 8.2. Develop Time-Phased Cost Estimate 8.3. Escalation 8.4. Establish Cost Contingency 8.5. Review Estimates APPENDIX A. GLOSSARY 1. Cost Baseline 2. Key Performance Parameter (KPP) 3. Performance Baseline (PB) 4. Performance Measurement Baseline (PMB) 5. Schedule Baseline 6. Technical Baseline 7. Work Breakdown Structure (WBS) APPENDIX B. REFERENCES APPENDIX C. ACRONYMS