Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Performance Based Management Handbook

712 views

Published on

Performance-Based Management
integrates Principles, Practices, and Processes
– to assure actionable information is provided to the decision makers that can increase the Probability Of Program Success.

Successful projects deliver capabilities:
§ Not work efforts,
§ Not cost expenditures,
§ Not documentation, test results, or the processes.
§ These all needed, but they’re not the deliverables.
§ For success projects must deliver tangible beneficial outcomes, assessed in units of measure meaningful to the decision makers.

This slide deck is an extract from the Book of the same name https://www.amazon.com/Performance-Based-Project-Management-Increasing-Probability/dp/0814433308

Published in: Technology

Performance Based Management Handbook

  1. 1. PERFORMANCE–BASED PROJECT MANAGEMENT® The Principles, Processes, and Practices used to increase the Probability of Program Success (PoPS) to accompany the book of the same title from AMACOM Books, 2014. V2.0 Niwot Ridge, LLC Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017
  2. 2. 2 Performance–Based Project Management® is a registered trademark of Niwot Ridge, L.L.C. Performance–Based Project Management ® ISBN 978–0–8144–3331–7 is a publication of American Management Association, Copyright© 2014 CMMI® is a Registered Trademark of Carnegie Mellon University, Pittsburg, PA All material in this document is Copyright © 2002 ― 2017 Glen B. Alleman, Niwot Ridge L.L.C. This publication may not be reproduced, stored on a retrieval system, or transmitted in whole or in part, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission from Niwot Ridge L.L.C. Send requests for reuse to glen.alleman@niwotridge.com
  3. 3. Chapter Title Page Chapter 0 Performance–Based Project Management® 5 Chapter I Principles and Processes of Performance–Based Project Management® 53 Chapter II The 10 Principles of Performance–Based Project Management® 63 Chapter III Deploying Performance–Based Project Management® 87 Chapter IV Process 1.0 – Identify Needed Systems Capabilities 95 Chapter V Process 2.0 – Establish the Requirements Baseline 105 Chapter VI Process 3.0 – Establish the Performance Measurement Baseline 115 Chapter VII Process 4.0 – Execute the Performance Measurement Baseline 125 Chapter VIII Process 5.0 – Continuous Risk Management 135 Chapter IX Graded Application of Performance–Based Project Management® 163 Chapter X Tools and Artifacts used in Performance–Based Project Management® 179 Appendix A References for each Chapter 225 Table of Contents Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 3
  4. 4. 4 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017
  5. 5. Performance–Based Project Management® integrates Principles, Processes, and Practices, to provide actionable information to the decision makers to increase the Probability of Program Success. This information provides performance to plan, risk reduction, measures of Effectiveness and Performance of the delivered products and services, estimates to complete, and estimates at completion. 0Performance–Based Project Management® in a Nutshell Chapter Chapter 05 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017
  6. 6. FiveImmutablePrinciples ofProjectSuccess 1. What does Done Look Like? Ten Practices Implementing the Five Processes, supporting the Five Immutable Principles 2. What’s the Plan to Reach Done? 1.CapabilitiesDrive Requirements 2.RequirementsIdentify Deliverables 3.WorkPackages produceDeliverables 4.MasterSchedule SequencesDeliverables 5.ProgressMeasuredas PhysicalPercent Complete 6.WorkAuthorization AssuresProper Sequencing 7.EarnedValueIdentifies performance 8.Compliancewith TechnicalPerformance MeasuresAdjustEV 9.PerformanceFeedback adjustswork sequencing 10.Futureperformance basedonTCPI 3. What resources are needed to reach Done? 4. What risks are encountered on the way to Done? 5. What are the units of measure of progress to plan? Five Processes Supporting the 5 Principles 1.Identify Needed Capabilities Define Capabilities as operational Concepts Define Operational Concepts as Scenarios or Use Cases Simultaneously assess – needs, costs and risks of capabilities Define explicit, balanced, and feasible alternatives 2.Establish Technical, Schedule, and Cost Requirements Perform Fact Finding for technical, cost, schedule baseline Gather and classify requirements Evaluate and Rationalize Requirements Prioritize requirements using risk adjusted measures Integrate and validate Requirements 3.Establish Performance Measurement Baseline to produce products to meet the project requirements Decompose Work Packages and Planning Packages Assign Accountability for the deliverables Arrange Work packages in logical order Assign Work Package Measures of Performance Develop BCWS for Work Packages Set the Performance Measurement Baseline 4.Execute Performance Measurement Baseline Perform the authorized work in the planned order Accumulate and Report Work Package performance Take Corrective actions to stay on plan Maintain the Performance Measurement Baseline 5.Perform Continuous Risk Management Identify technical and programmatic risks Analyze risks Plan and execute the risk handling strategies Track risk handling activities Control or accept risks Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 Chapter 06
  7. 7. Chapter 0 Performance–Based Project Management® Management® In A Nutshell 5 Principles, 5 Processes, and 5 Practices to Increase The Probability of Project Success Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 20177 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017
  8. 8. Why Performance–Based Project Management®? § Successful projects deliver capabilities: § Not work efforts, § Not cost expenditures, § Not documentation, test results, or the processes. § These are all needed, but they’re not Deliverables. § For success, projects must deliver tangible beneficial outcomes, assessed in units of measure meaningful to the decision makers. Performance–Based Project Management® Principles, Processes, and Practices for Increasing the Probability of Project Success† † Program Success Probability, John Higbee, Defense Acquisition University, 9 May 2005 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 8/26
  9. 9. 1. What Does DONE Look Like? 2. How Do We Get to DONE? 3. Is There Enough Time, Money, and Resources, To Get to DONE? 4. What Impediments Will Be Encountered Along The Way to DONE? 5. What Units of Measure are used to confirm Progress To Plan Toward Done? All Successful Projects Require Credible Answers To These 5 Questions … 9 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017
  10. 10. 5 Critical Practice Groups Needed to Implement the 5 Principles of Project Success ¨ Define the Work Breakdown Structure(WBS). ¨ Identify the Organizational Breakdown Structure (OBS). ¨ Integrate the WBS and OBS. ¨Organization ¨ Schedule the work. ¨ Identify the Products and Milestones. ¨ Set the Time Phased Budget. Planning and Budgeting ¨ Record Direct Costs. Accounting ¨ Determine Variances. ¨ Sum Data and Variances. ¨ Manage Action Plans. Performance Analysis ¨ Incorporate Changes to all plan budgets and technical deliverables. Revision Management Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 Chapter0 10
  11. 11. Credible Data Is Need to Increase The Probability Of Program Success ¨ Concept of Operations (ConOps) ¨ Operational Scenarios and Use Cases ¨ Integrated Master Plan (IMP) ¨ Value Stream Maps (VSM) ¨ Key Performance Parameters (KPP) ¨ Measures of Effectiveness (MoE) ¨ Program Planning and Controls (PP&C) ¨ Integrated Master Schedule (IMS) ¨ Work Packages (WP) and Planning Packages (PP) ¨ Earned Value Management (EVM) ¨ Technical and Programmatic Risk Management (RM) ¨ Measures of Performance (MoP) ¨ Estimate At Completion (EAC) ¨ Estimate To Complete (ETC) ¨ To Complete Performance Index (TCPI) ¨ Independent Estimate At Completion (IEAC) ¨ Technical Performance Measures (TPM) Chapter0 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 11
  12. 12. Systems Management Guides the Conversion of this Data into Actionable Outcomes ¨ Systems Management is the set of organizational structures and processes to rapidly deliver dependable technological outcomes within a predictable time and budget. ¨ Complexity in large scale systems is not driven by the scale, but rather by the heterogeneity of the components and their individual underlying complexity. ¨ Managing the complex individual components, their interactions, their cost, schedule, and technical performance elements is the role of Systems Management. ¨ Performance–Based Project Management® connects cost, schedule, and schedule performance data to provide actionable information to the decision makers. Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 Chapter0 12
  13. 13. 16 Program Management Activities Program Enablers Program Process Capabilities Business Enablers Chapter0 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 13
  14. 14. Origins of Performance–Based Project Management® ¨ This is planning in the large. ¨ This is planning in the presence of change. ¨ The focus is on transformational outcomes. ¨ Capabilities start with a mission level analysis. www.rand.org Chapter0 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 14
  15. 15. Performance–Based Project Management® 4+1 questions every project must answer Performance–Based Project Management® integrates five critical program management process areas with – Cost, Schedule, and Technical Performance Measures. The inclusion of Technical Performance Measures (TPM) separates this approach from conventional methods based solely on managing cost and schedule. In conventional approaches, the cost and schedule baseline and their variances generate the data for Earned Value variables that are used to make programmatic decisions. In Performance–Based Project Management®, Earned Value measures are integrated with measures of Physical Percent Complete (PPC) derived from Technical Performance Measures (TPM) at planned assessment points in the Integrated Master Schedule (IMS). The Events and Milestones defined in the Integrated Master Plan (IMP) describe the planned technical or operational maturity of the products or services measured against their actual technical performance. The Earned Value measurements are used with Technical Performance measures for each deliverable to produce a credible measure of progress and a credible forecast of future performance using the To Complete Performance Index (TCPI). The result is increased visibility and credibility of the Independent Estimate at Completion (IEAC). As the program progresses, technical and programmatic risks are identified, their mitigation or retirement planned and executed, and adjustments to the program made to assure planned progress is maintained. Successfully executing the program requires a Program Planning and Controls discipline that identifies what “Done” looks like, measures progress toward “Done,” identifies the risks and impediments to reaching “Done,” and assures timely corrective action to maintain progress toward “Done.” “Done” is always defined in units of measure meaningful to the decision maker. The best tangible evidence are the Deliverables needed to meet the requirements that fulfill the system’s requested Capabilities recognized as success for the program. Using this approach, Deliverables fulfill the requirements that meet the system or business performance criteria, produced at the planned time, using the planned budget. This performance is measured as Physical Percent Complete and is the only Credible measurement of progress. With the planned requirements fulfilled, the system or operational capabilities become available to the customer at the planned time. Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 Chapter0 15
  16. 16. The 4+1 Questions Every Successful Project Answers Capabilities Requirements Plans Execution 2. What technical and operational requirements are needed to deliver these capabilities? 1. What capabilities are needed to fulfill the Concept of Operations†, the Mission and Vision, or the Business System Requirements? 3. What schedule delivers the product or services on time to meet the requirements? 4. What periodic measures of physical percent complete assure progress to plan? What impediments to success, their mitigations, retirement plans, or “buy downs are in place to increase the probability of success?” + Continuous Risk Management † A Concept of Operations (ConOps) describes the characteristics of a system from the point of view of an individual who will use that system. It is used to communicate the quantitative and qualitative system characteristics to all stakeholders. Œ  Ž   Chapter 0Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 201716 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017
  17. 17. Performance–Based Project Management® Addresses … Project Management Case Study, Pierre Bonnal, CNAM IIM MBA Program, June 2004 Chapter0 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 17
  18. 18. Identify Needed Capabilities Establish a Performance Measurement Baseline Execute the Performance Measurement Baseline Capabilities Based Plan Operational Needs Earned Value Performance 0% /100% Technical Performance Measures System Value Stream Technical Requirements Identify Requirements Baseline Technical Performance Measures PMB Changes to Needed Capabilities Changes to Requirements Baseline Changes to Performance Baseline Œ  Ž   Chapter 0Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 201718 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017
  19. 19. Increasing the Maturity of Project Processes and Deliverables with Meaningful Measures 1. Identify Needed Capabilities to achieve program objectives or the particular end state. Define these capabilities through scenarios from the customer point of view in units of Measure of Effectiveness (MoE) meaningful to the customer. 2. Define the Technical And Operational Requirements that must be fulfilled for the system capabilities to be available to the customer at the planned time for the planned cost. Define these requirements in terms that are isolated from any implementation technical products or processes. Only then bind the requirements with technology. 3. Establish the Performance Measurement Baseline describing the work to be performed, the budgeted cost for this work, the organizational elements that produce the deliverables from this work, and the Measures of Performance (MoP) showing this work is proceeding according to cost, schedule, and technical performance. 4. Execute the PMB’s Work Packages in the planned order, assuring all performance assessments are 0%/100% complete before proceeding. No rework, no transfer of activities to the future. Assure every requirement is traceable to work and all work is traceable to requirements. 5. Perform Continuous Risk Management for each Performance–Based Project Management® process area to Identify, Analyze, Plan, Track, Control, and Communicate programmatic and technical risk. The integration of these five process areas is the foundation of Performance–Based Project Management®. Each process area stands alone and at the same time is coupled with the other process areas. Each process area contains specific steps for producing beneficial outcomes to the project, while establishing the basis for overall project success. Each process can be developed to the level needed for specific projects. All five process areas are critical to the success of any project. If a process area is missing or poorly applied, the capability to manage the project will be jeopardized, possibly in ways not know until the project is too far along to be recovered. Each process provides information needed to make decisions about the majority flow of the project. This actionable information is the feedback mechanism needed to keep a project under control. These control processes are not impediments to progress, but are the tools needed to increase the probability of success. Chapter0 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 19
  20. 20. Increasing the Maturity of Project Work Processes and Deliverables Chapter0 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 20 Identify Capabilities Needed for Success Identify Requirements to Deliver Capabilities Establish Performance Measurement Baseline Execute Performance Measurement Baseline § Define Capabilities § Define Concept of Operations § Assess Needs, Cost, and Risk Impacts § Define Balanced and Feasible Alternatives § Fact Finding § Gather And Classify § Evaluate And Rationalize § Prioritize Requirements § Integrate And Validate § Decompose Scope § Assign Accountability § Arrange Work § Develop Budget § Assign Performance § Perform Work § Accumulate Performance Measures § Analyze Performance § Take Corrective Action Perform Continuous Risk Management (CRM) Define the Measurable Capabilities of each Project Outcome Assure All Requirements Provided In Support of Capabilities Define Measures of Performance and Effectiveness Ensure Cost, Schedule, and Technical Performance Compliance
  21. 21. What is a Deliverable? Project Management Case Study, Pierre Bonnal, CNAM IIM MBA Program, June 2004. Chapter0 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 21
  22. 22. Define the set of capabilities needed to achieve the project objectives or the particular end state for a specific scenario. Using the Concept of Operations (ConOps), define the details of who, where, and how this capability is to be accomplished, employed, and executed. Œ Define the technical and operational requirements for the system capabilities to be fulfilled. First, define these requirements in terms isolated from any implementation details. Only then bind the requirements with technology.  Build a time–phased network of work activities describing the work to be performed, the budgeted cost for this work, the organizational elements that produce the deliverables, and the performance measures showing this work is proceeding according to plan. Ž Execute work activities, while assuring all performance assessment represent 100% completion before proceeding. This means – No rework, no forward transfer of activities to the future. Assure all requirements are traceable to work & all work is traceable to requirements.  Apply the processes of Continuous Risk Management for each Performance–Based Project Management® process area to: Identify, Analyze, Plan, Track, Control, and Communicate programmatic and technical risk.  Chapter 0Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 201722 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017
  23. 23. §Partition system capabilities into classes of service within operational scenarios. §Connect the capabilities to system requirements using some visual modeling notation. §Define Measures of Effectiveness (MoE) and Measures of Performance (MoP). §Define the delivery schedule for each measure of performance and effectiveness. §Define scenarios for each system capability. §Connect these scenarios to a Value Stream Map of the increasing maturity of the program. §Assess value flow through the map for each needed capability. §Identify capability mismatches and make corrections to improve overall value flow. §Assign costs to each system element using a value flow model. §Assure risk, probabilistic cost and benefit performance attributes are defined. §Use cost, schedule and technical performance probabilistic models to forecast potential risks to program performance. §Make tradeoffs that connect cost, schedule, and technical performance in a single location that compares the tradeoffs and their impacts. §Use Measures of Effectiveness (MoE) and Measures of Performance (MoP) for these alternative tradeoffs. Define the capabilities needed to achieve a desired objective or a particular end state for a specific scenario. Define the details of who, where, and how these capabilities are to be accomplished, employed, and executed. 1.1 1.2 1.3 1.4 Œ Chapter 0Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 201723 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017
  24. 24. What Does A Capability “Sound” Like? Chapter0 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 24
  25. 25. Identifying Needed System Capabilities Identifying System Capabilities is the starting point for any successful program. Systems Capabilities are not direct requirements, but statements of what the system should provide in terms of “abilities.” For example there are four capabilities needed for the Hubble Robotic Service Mission: 1. Do no harm to the telescope. 2. Change the Wide Field Camera. 3. Connect the external battery umbilical cable. 4. Attached the de-orbit module for later use How is this to be done and what are the technical, operational, safety and mission assurance requirements? Don’t really know yet, but the Capabilities guide their development. The critical reason for starting with capabilities is to establish a home for all the requirements. To answer the question “why is this requirement present?” “Why is this requirement needed?” “What business or mission value does fulfilling this requirement provide?” Capability statements can then be used to define the units of measure for program progress. Measuring progress with physical percent complete at each level is mandatory. But measuring how the Capabilities are being fulfilled is most meaningful to the customer. The “meaningful to the customer” unit of measures are critical to the success of any program. Without these measures the program may be cost, schedule, and technically successful but fail to fulfill the mission. The process flow to the right is the starting point for Identifying the Needed Capabilities and determining their priorities. Starting with the Capabilities prevents the “Bottom Up” requirements gathering process from producing a “list” of requirements – all needed – that is missing a well formed topology. This Requirements Architecture is no different than the Technical or Programmatic architecture of the system. Capabilities Based Planning (CBP) focuses on “outputs” rather than “inputs.” These “outputs” are the mission capabilities that are fulfilled by the program. Without the capabilities, it is never clear the mission will be a success, because there is no clear and concise description of what success means. Success means providing the needed capabilities, on or near schedule and cost. The concept of CBP recognizes the interdependence of systems, strategy, organization, and support in delivering the capability, and the need to examine options and trade‒offs in terms of performance, cost and risk to identify optimum development investments. CBP relies on Use Cases and scenarios to provide the context to measure the level of capability. Chapter0 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 25
  26. 26. What Should We Do? Where Are We Now? Identifying Needed System Capabilities Abstracted from: “Capabilities‒Based Planning – How It Is Intended To Work And Challenges To Its Successful Implementation,” Col. Stephen K. Walker, United States Army, U. S. Army War College, March 2005 Identifying Needed System Capabilities Chapter0 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 26
  27. 27. §Produce an overall statement of the problem in the operational context. §Develop the overall operational and technical objectives of the target system. §Defined the boundaries and interfaces of the target system. §Gather required system capabilities, functional, nonfunctional and environmental requirements, and design constraints. §Build the Top Down capabilities and functional decomposition of the requirements in a Requirements Management System. §Answer the question “why do I need this?” in terms of operational capabilities. §Build a cost / benefit model using probabilistic assessment of all variables, their dependencies, and impacts. §For all requirements, perform a risk assessment to cost and schedule. §Determine criticality for the functions of the system. §Determine trade off relationships for all requirements to be used when option decisions must be made. §For all technical items, prioritize their cost and dependency. §Address the completeness of requirements by removing all “TBD” items. §Validate that the requirements are traceable to system capabilities, goals, and mission. §Resolve any requirements inconsistencies and conflicts. Define the technical and operational requirements that must be met for the system capabilities to be delivered. Define these requirements in terms isolated from any technology or implementation. Assure each requirement is connected to a need system capability. 2.1 2.2 2.3 2.4 2.5  Chapter 0Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 201727 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017
  28. 28. What Is a Requirement? Chapter0 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 28
  29. 29. Identifying Requirements Requirements are defined attributes for an item prior to the efforts to develop a design for that item. System requirements analysis is a structured, or organized, methodology for identifying an appropriate set of resources to satisfy a system need (the needed capabilities) and the requirements for those resources that provide a sound basis for the design or selection of those resources. Requirements act as the transformation between the customer’s capabilities needs and the design concept implemented by the organization’s engineering resources. The requirements process decomposes a statement of the customer need through a systematic exposition of what that system must do to satisfy that need. This need is the ultimate system requirement which all other requirements and designs flow. There are two fundamental classes of requirements. § Process Performance Requirements § Product Performance Requirements Process Performance Requirements define how the work processes are used to produce a beneficial outcome to the customer. Product Performance Requirements define the product specifications and how they are related to the process requirements. As well as the product and process requirements, there are functional and non‒functional requirements. These non‒functional requirements play a significant role in the development of the system. Non‒functional requirements are spread across the entire system or within individual services and cannot be allocated to one specific software artifact (e.g., class, package, component). This makes them more difficult to handle than functional requirements. The specifics of the system’s architecture, such as highly distributed services bring up additional difficulties. The distinction between process and product requirements lays the foundation for the Work Breakdown Structure (WBS). The WBS, the Related Integrated Master Plan (IMP) and Integrated Master Schedule (IMS), also focus on this separation. The success of the project or program depends on defining both the product and the processes that support or implement the product. When properly connected, the Requirements Taxonomy, the Work Breakdown Structure, the IMP, and the IMS “foot and tied” to the Performance Measurement Baseline (PMB) to provide the traceability of the increasing maturity of the deliverables (vertical) and the physical percent complete of the work efforts (horizontal). Chapter0 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 29
  30. 30. Identifying Requirements† † Systems Requirements Practices, Jeffery O. Grady, McGraw Hill, 1993 Chapter0 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 30
  31. 31. Build a time–phased network of activities describing the work to be performed, the budgeted cost for this work, the organizational elements that produce the deliverables from this work, and the performance measures showing this work is proceeding according to plan. Decompose the program Scope into a product based Work Breakdown Structure (WBS), then further into Work Packages describing the production of the deliverables traceable to the requirements, and to the needed capabilities. 3.1 Assign responsibility to Work Packages (the groupings of deliverables) to a named owner accountable for the management of the resource allocations, cost and schedule baseline, and technical delivery. 3.2 Arrange the Work Packages in a logical network with defined deliverables, milestones, internal and external dependencies, with credible schedule, cost, and technical performance margins. 3.3 Develop the Time–Phased Budgeted Cost for Work Scheduled (BCWS) for the labor and material costs in each Work Package and the Project as a whole. Assure proper resource allocations can be met and budget profiles match expectations of the program sponsor 3.4 Assign objective Measures of Performance (MoP) and Measures of Effectiveness (MoE) for each Work Package and summarize these for the Project as a whole. 3.5 Establish a Performance Measurement Baseline (PMB) used to forecast the Work Package and Project ongoing and completion cost and schedule performance metrics. 3.6 Ž Chapter 0Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 201731 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017
  32. 32. What Does a Credible Plan and Schedule Look Like? Chapter0 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 32
  33. 33. Establishing the Three Elements of the Performance Measurement Baseline The Performance Measurement Baseline (PMB) is the primary assessment document for assuring the credibility of a program plan. The PMB is the baseline of the cost, schedule and deliverables for each Work Package in the plan. Constructing the PMB requires knowledge of the business requirements, skill in developing the Work Packages that produce the deliverables for these requirements, and discipline in assembling the cost, schedule and relationships between the Work Packages. It is the discipline that requires the most focus for the planners and program controls staff. Without this discipline, the development of a credible baseline is simply not possible. In the end the planners and program controls staff must “know” in intimate detail each Work Package, its deliverables and resource requirements, the performance measurement criteria, and the dependencies that form the critical path through the program schedule. The concept of Performance–Based Project Management® is. § Deliverables are the units of measure of progress to plan. § Deliverables are what the customer has paid money for. § Deliverables contain the business capabilities, the associated value that fulfill the requirements of the business plan. There are three elements to the Performance Measurement Baseline: The Technical Performance Baseline is the requirements flow down and traceability map for each deliverables in the program. § A critical performance measure of the Technical Performance Baseline is the stability of requirements. The expected technical achievement for the actual progress is compared using periodic measurements or tests starts with the Technical Performance Baseline. § An important aspect of the Technical Performance Baseline is to define the units of measures for each deliverable that defines what “done” looks like at each incremental assessment of maturity. The Schedule Performance Baseline is the sequence of Work Packages and Planning Packages that produce the products or services from the program. This baseline contains the schedule margin derived from the Monte Carlo simulation described in DID 81650. The Cost Performance Baseline is the “authorized time‒phased budget‒at‒completion (BAC) used to measure, monitor, and control overall cost performance on the program.” This budget (BCWS) is held in the Control Accounts, the Work Packages and Planning Packages owned by the Control Account Manager. Chapter0 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 33
  34. 34. Establishing the Three Elements of the Performance Measurement Baseline Cost Baseline Schedule Baseline Technical Baseline Determine Scope and Approach Develop Technical Logic Develop Technical Baseline Develop WBS Define Activities Estimate Time Durations Sequence Activities Finalize Schedule Identify Apportioned Milestones Determine Resource Requirement Prepare Cost Estimate Resource Load Schedule Finalize Apportioned Milestones Determine Funding Constraints Approve PMB Chapter0 Perform Functional Analysis Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 34
  35. 35. Execute the planned work, assuring all work is 100% complete before proceeding to the next planned work package. No rework, no forward transfer of activities or features. Assure every requirement is traceable to work and all work is traceable to requirements. § Using the Work Package sequencing, release work to be performed as planned. § With the responsibility assignments, identify the accountable delivery manager to guide the development of the products or services for each Work Package. 4.1 § Using Physical Percent Complete or Apportioned Milestones, capture measures of progress to plan for each Work Package. § Report this Physical Percent Complete in a centralized database for each Work Package and the program as a whole. 4.2 § Compare the Physical Percent Complete against the Planned Percent Complete for each period of performance. § Construct cost and schedule performance indices from this information and the Physical Percent complete measures. 4.3 § With Cost and Schedule performance indices, construct a forecast of future performance of cost, schedule, and technical performance compliance. § Take management actions for any Work Packages not performing as planned. 4.4 § Record past performance based on Work Package completion criteria. § Record past future forecast performance estimates in a historical database. § Forecast next future performance estimate against the Performance Measurement Baseline. § Report this next future performance estimate to the program stakeholders. 4.5  Chapter 0Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 201735 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017
  36. 36. How Do We Know We Are Making Progress to Plan? Chapter0 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 36
  37. 37. Executing the Performance Measurement Baseline (PMB) With the Performance Measurement Baseline established, its execution is now the next critical activity. The execution process is called the “program rhythm.” this means the processes are performed in a repeated manner – at least on a monthly basis and many times on a weekly basis. This business rhythm must create actionable information for the program manager on a time scale that actually allows actions to be taken. For Government programs this time scale is at a minimum once a month – the Contract Performance Report – in the form of DI‒MGMT‒81466A. A larger question must be answered though. How long is the Program Manager willing to wait before she discovers she is late? Waiting one month seems risky. Many programs have weekly status reviews which answer the question “where are we in terms of progress to plan?” In the Performance–Based Project Management® method, the measure of this “progress to plan” is provided by the tangible physical deliverables from the work efforts. These tangible, physical deliverables must be defined in the work packaged created during the Planning process of Performance–Based Project Management®. The measures of physical percent complete can be applied on weekly boundaries in a variety if ways: 1. To actually have weekly deliverables. 2. Have apportioned milestones for each week. 3. Have tasks that are one week long and record 0%/100% complete at the end of each week. In all cases, a measure of physical percent complete is mandatory if the program manager is to receive actionable information. The important process here is to have an agreed on measure of performance that is defined before the work starts. Keep these measures and the work efforts that produce to “fine grained” durations. Focus on answering the question How long are we willing to wait before we find out we’re late? The answer to this question must be short enough to take corrective action so you are in fact not late. Chapter0 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 37
  38. 38. Executing the Performance Measurement Baseline (PMB) Chapter0 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 38
  39. 39. § Identify and classify risks in a Risk Register. Separate reducible and Irreducible risks § Manage this Risk Register through a Risk Management Board. § Connect these risks and their handling and margins in the Master Schedule. § Convert risk data into risk decision‒making information. § Use this analysis information as the decision basis for the program manager to work on the “right” risks. § Turn risk information into decision making information and actions (both present and future). § Develop actions to address individual risks, prioritize risk actions, and create an integrated risk management plan to retire the risk or handle it when it turned into an issue. § Monitor the status of risks and actions taken to ameliorate risks. § Identify and monitor risks to enable the evaluation of the status of risks themselves and of risk mitigation plans. § Risk communication lies at the center of the model to emphasize both its pervasiveness and its criticality. § Without effective communication, no risk management approach can be viable. Continuous Risk Management starts with the underlying principles, concepts, and functions of risk management and provides guidance on how to implement risk management as a continuous practice in programs and the organizations that management programs. 5.1 5.2 5.3 5.4 5.5  Chapter 0Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 201739 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017
  40. 40. Analyze Plan Track Control Identify Risks, Issues, and Concerns Evaluate, classify, and prioritize risks Decide what should be done about each risk Monitor risk metrics and verify/validate mitigations Make risk decisions Subproject and partner data/constraints, hazard analysis, FMEA, FTA, etc. Risk data: test data, expert opinion, hazard analysis, FMEA, FTA, lessons learned, technical analysis Resources Replan Mitigation Program/project data (metrics information) Statement of Risk Risk classification, Likelihood Consequence, Timeframe Risk prioritization Research, Watch (tracking requirements) Acceptance Rationale, Mitigation Plans Risk status reports on: Risks Risk Mitigation Plans Close or Accept Risks Invoke contingency plans Continue to track Perform Continuous Risk Management Chapter0 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 40
  41. 41. Integrating all the Parts Into a Whole For increase the probability of project success, we need all the parts of the project’s architecture to being place. This starts with the Statement of Work, the Concept of Operations, Statement of Objectives and a similar narrative document and the supporting graphics showing what the system will do, who is involved, and the artifacts and outcomes of the results from the project. With these in hand, we can build the Work Breakdown Structure for the deliverables. The WBS is product centric, along with the services that produce the products. The WBS does not describe the organizations producing the products. That is done in the Organizational Breakdown Structure (OBS). At the terminal nodes of he WBS are the Work Packages that produce the deliverables. From the WBS, the technical and operational requirements can be derived. These define the behaviors of the deliverables through Key Performance Parameters. The customer’s KPPs come first, followed by the project’s KPPs in the CWBS. The Integrated Master Plan (IMP) describes the Program Events, Significant Accomplishments, and Accomplishment Criteria needed to increase the maturity of each deliverable through the project’s lifecycle. The IMP is the single most important document for properly executing the project. Without the IMP, we cannot tell what Done looks like. From the IMP, the Integrated Master Schedule (IMS) is developed. The IMS sequences the Work Packages that perform the work to produce the deliverables. This sequence defines the critical path, the resources needed to perform the work, the order of the work, and the dependencies between the work efforts. Using the IMS, the Earned Value Management techniques for each Work Package is defined. Measures of Physical Percent Complete are the best choice. For each Work Package, Technical Performance Measures (TPM) are used to assure the resulting outcomes meet the requirements of the SOW, SOO, and ConOps. With all these components, the Performance Measurement Baseline can be established, showing the time phased budget, work effort, deliverables, and assessment of increasing maturity of the outcomes. This PMB is then risk adjusted for reducible and irreducible risks. With risk retirement work activities for the reducible risks funded on baseline and schedule margin in front of key deliverables to protect them from the irreducible risks. After each status period, the risks are reassessed, margin burn down recalculated, risk reduction reassessed from the baseline work and a new risk adjusted Estimate to Complete developed and changes made to “Keep the Program Green.” Chapter0 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 41
  42. 42. Integrating all the Parts into a Whole Chapter0 Risk Management SOW SOO ConOps WBS Technical and Operational Requirements CWBS & CWBS Dictionary Integrated Master Plan (IMP) Integrated Master Schedule (IMS) Earned Value Management System (EVMS) Objective Status and Essential Views to support the proactive management processes needed to keep the program GREEN Performance Measurement Baseline (PMB) Measures of Effectiveness (MOE) Measures of Performance (MOP) Measures of Cost – Schedule Progress JROC Key Performance Parameters (KPP) Program Specific Key Performance Parameters (KPP) Technical Performance Measures (TPM) CWBS Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 42
  43. 43. From Mission Capabilities to Done Measures of Effectiveness (MOE) – are the operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in the operational environment, under a specific set of conditions. These measures are stated in units ,meaningful to the buyer. They focus on the capabilities independent of any technical implementation. Measures of Performance (MOP) – characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions. These measures are attributes that assure the system has the capability and capacity to perform. They are an assessment of the system to assure it meets the design requirements to satisfy the Measures of Effectiveness. Key Performance Parameters (KPP) – Represent the capabilities and characteristics so significant that failure to meet them can be cause for reevaluation, reassessing, or termination of the program. KPPs have a threshold or objective value that characterize the major drivers of performance that are considered Critical to Customer (CTC). Technical Performance Measures (TPM) – are attributes that determine how well a system or system element is satisfying or expected to satisfy a technical requirement or goal. TPMs assess design progress, define compliance to performance requirements, identify technical risk, are limited to critical thresholds, and include projected performance goals. Connecting the Mission Need – capabilities produced by the project – with the MoEs, MoPs, KPPs, and TPMs must be done for the project to have a chance of success. Along with these attributes are …ilities, many times are called non-functional requirements § Usability § Maintainability § Scalability § Availability § Extensibility § Security § Portability Chapter0 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 43
  44. 44. From Mission Capabilities to Done Chapter0 “Coming to Grips with Measures of Effectiveness,” N. Sproles, Systems Engineering, Volume 3, Number 1, pp. 50–58 MoE KPP MoP TPMMission Need Acquirer Defines the Needs and Capabilities in terms of Operational Scenarios Supplier Defines Physical Solutions that meet the needs of the Stakeholders Operational measures of success related to the achievement of the mission or operational objective being evaluated. Measures that characterize physical or functional attributes relating to the system operation. Measures used to assess design progress, compliance to performance requirements, and technical risks. Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 44
  45. 45. Chapter 0Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 201745 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017
  46. 46. Chapter 0Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 201746 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017
  47. 47. 4+1Critical Success Processes Capabilities, Requirements & Deliverables Program Architecture & Dependencies Work Planning and Sequencing Performance Measurement Baseline Programmatic & Technical Risk Management §Balanced Scorecard §Concept of Operations §Statement of Objectives §Integrated Master Plan (IMP) §Gaps §Overlaps §Interfaces §Integrated Master Schedule (IMS) §Schedule margin to protect critical deliverables §Cost And Schedule Baseline §WBS §RAM §Resource Loaded IMS §Risk Registry §Risk Handling Plans §Contingency And Management Reserve §Requirements Traceability §Value Stream Mapping (VSM) §Work Packages §Planning Packages §Technical Performance Measures (TPM) §Risk Integrated With IMS §Risk Trending §Measures Of Effectiveness (MoE) §Design Structure Matrix (DSM) §Earned Value Management §Measures Of Performance (MoP) §Monte Carlo Simulation Chapter0 47
  48. 48. Program Support Services Business Process Reengineering Balanced Scorecard Organizational Change Management DCMA Compliance DCAA Compliance § Michael Hammer trained reengineering processes § Program governance scorecard § Integrated Project Team development § Earned Value Management System Deployment § Cost Accounting Standard (CAS) system deployment § Project Management process improvement § Program performance dashboards § Performance management training § EVM System Description development and application § Integration of the EV Engine with a CAS compliant accounting system § Value stream mapping § Strategic management connected with execution § Measurable Process improvement § EVMS Validation preparation § DCAA and DCMA compliance of EVMS Chapter0 48
  49. 49. Tangible Benefits of Performance–Based Project Management® Performance–Based PM Capabilities Benefits to the Customer Program, Planning, and Controls Rapid creation of the risk adjusted Performance Measurement Baseline. Earned Value Management ANSI‒748C compliant processes, tools, and training. Programmatic and Technical Risk Management Credible integrated risk management process guided by DoD, DOE, AACE, and PMI standards. Management Process Improvement Value focused organizational change management. Program Performance Assessment Unbiased External Independent Reviews (EIR). Proposal support – Management Volume IMP/IMS, Basis of Estimate (BoE), and Risk sections. Chapter0 49
  50. 50. Performance–Based Project Management® Puts You On the Road to Success … Where are we going? How do we get there? Are there enough resources? What are impediments to progress? How do we measure progress? Chapter 0Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 201750 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017
  51. 51. Chapter 0Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 201751 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017
  52. 52. 52 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017
  53. 53. Practices of Performance– Based Project Management® guide the application of the 5 Principles and the 5 Process Areas in this handbook. These practices define the reasons for each process, connect each practice to a beneficial outcome, and integrate the processes into a seamless delivery system. IConnecting Principles and Processes With Practices Chapter Chapter I53 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017
  54. 54. 10 Practices of Performance–Based Project Management® Principles are the source of guidance for the Performance– Based Project Management® Practices. A principle is a “general truth, a law on which other are founded or from which others are derived.” [Webster] For the principles of program and project management to be effective they must : § Express a basic concept § Be universally applicable § Be capable of straightforward expression § Be self evident The 10 Practices of Performance–Based Project Management® guide the application of the process areas. These practices encompass the entire life cycle of a project or program, from inception and the discovery of the business or system capabilities, through requirements elicitation, to the creation of the Performance Measurement Baseline (PMB), to the execution of this baseline. The practices of Performance–Based Project Management® provide several feedback loops to assure that subsequent activities provide measurable information to correct gaps that exist in the previous activities. This iterative and incremental approach to program management assures the periods of assessment for corrective actions are appropriately spaced to minimize risk while maximizing the delivered value to the program. Performance–Based Project Management® can be the basis of conventional as well as Lean and Agile program management methods. The illustration the next page are the 10 Practices of Performance–Based Project Management®. Each Practice is developed in detail later in this handbook. For now understanding the dependencies between the principles is important. Information produced by the Practices derived from the Processes must be done in a sequential manner. This is not a “waterfall” approach, but rather an incremental elicitation of the information needed to successfully manage the program. Skipping forward in the sequence of Principle, creates systemic risk for both the programmatic and technical elements of the program. ChapterI Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 54
  55. 55. 10 Practices of Performance–Based Project Management® Assess the capabilities being provided through the deliverables Fulfill the requirements through effort held in the Work Packages Produce deliverables from Work Packages Planned BCWS Physical % Complete WP’s contain deliverables that fulfill requirements Capabilities topology defines requirements flow down WP flow must describe the increasing maturity of the product or service Producing the deliverables in the planned sequence maintains the value stream to the customer ChapterI Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 55
  56. 56. 5 Process Areas of Performance–Based Project Management® Five core process form the basis of Performance–Based Project Management®. These processes represent a sequence of activities that increase the maturity of the programmatic aspects of a project or program. The plans that result from these efforts describe the increasing maturity of the product or services that are the deliverables from the program. In order to develop and execute a Plan, a set of requirements is needed. Before these requirements can be developed, an understanding of the system capabilities should be developed. 1. Identify Needed System Capabilities ‒ Define the set of capabilities (business, operational, or technical) needed to achieve the program objectives or a particular end state for a specific scenario using the Concept of Operations (ConOps). CONOPs is a verbal or graphic statement, in broad outline, of an assumption or intent in regard to an operation or series of operations, mission, or system. 2. Establish Requirements Baseline – defines the technical, organizational, and operational requirements that must be in place for the system capabilities to be fulfilled. Define these requirements in terms isolated from the implementation details. Only then, bind these requirements with the technical alternatives. 3. Establish Performance Measurement Baseline – build a time‒phased network of scheduled activities describing the work to be performed, the budgeted cost for this work, and the organizational elements that produce the deliverables from this work. Define the technical performance measures showing how this work proceeds according to the technical and programmatic plan. 4. Execute the Performance Measurement Baseline – execute the Performance Measurement Baseline Work Packages, while assuring all performance assessments represent measures of Physical Percent Complete. 5. Continuous Risk Management – identify, plan, and budget risk mitigation or retirement activities at assure impediments to progress are handled. These five process areas must all be present in some form, for program success. To skip any process area, or performance the process area out of order Capabilities, Requirements, Baseline, and Execution, with Continuous Risk Management lays the foundation for a Troubled Project. Each process area builds on the previous area to increase the fidelity of the actionable information needed by the decision makers. This method is independent of any specific development of engineering process – iterative, incremental, and linear processes are all equally effective ChapterI Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 56
  57. 57. 5 Processes of Performance–Based Project Management® 10PracticesofPerformance–BasedProjectManagement® Chapter I 5 Identify Needed Capabilities Establish a Performance Measurement Baseline Execute the Performance Measurement Baseline Capabilities Based Plan Operational Needs Earned Value Performance 0% /100% Technical Performance Measures Business or Mission Value Stream Technical Requirements Identify Requirements Baseline Technical Performance Measures PMB Changes to Needed Capabilities Changes to Requirements Baseline Changes to Performance Baseline Chapter IPerformance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 201757 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017
  58. 58. 5 Performance–Based Project Management® Processes Performance–Based Project Management® is a comprehensive approach to managing cost, schedule, and technical performance of programs and projects by assessing the interaction between programmatic and technical processes. The method starts by capturing the technical and operational needs of the proposed system. These are stated in a Concept of Operations describing how the system operates, how it fulfills the stated mission, what major components comprise the system, and how they interact with each other. From the capabilities description of the Concept of Operation, technical and operational requirements are elicited. These requirements define the development progress of the deliverables captured in the Performance Measurement Baseline (PMB). This PMB is constructed from a collection of Work Packages, arranged in a logical network describing the increasing maturity of the products or services needed to deliver the stated capabilities. Measures of physical percent complete are used for each Work Package and the deliverables they produce. Performance–Based Project Management® is a Systems Engineering approach to program and project management [INCOSE], [Stevens]. This method incorporates all three aspects of a program performance measurement process – Cost, Schedule, and Technical Performance Measures (TPM). The inclusion of the TPMs distinguishes the Performance– Based Project Management® from more conventional approaches to Program, Planning, and Controls. In conventional approaches, the cost and schedule baseline and the variances generate the values for Earned Value. In the Performance–Based Project Management® method, measures of Physical Percent Complete are derived from pre–defined targets of Technical Performance. The Earned Value variables are augmented with adjustments from the Technical Performance compliance for each deliverable to produce a true assessment of progress. Technical Performance Measures integrate technical achievement with earned value using risk assessments that provides a robust program management tool to identify early technical and programmatic disruptions to a program. [Pisano] TPMs: Provide an integrated view across all programmatic and technical elements. Support distributed empowerment implicit in the IPT approach, through interface definitions. Logically organizes data resulting from systems engineering, risk management, and earned value processes. Provide a "real time" indication of contract performance and future cost and schedule risk. Support the development of systems thinking within an integrated program model focused on the interface definitions. ChapterI Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 58
  59. 59. 5 Performance–Based Project Management® Processes ChapterI Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 59
  60. 60. 1. Identify Needed Systems Capabilities – Define the Measures of Effectiveness (MoE) Performance–Based Project Management® DEFINE CAPABILITIES AS OPERATIONAL CONCEPTS Partition system capabilities into classes of service within operational scenarios, identifying actors, processes, and data Connect capabilities to system requirements using sysML, or some modeling tool to reveal interdependencies and resolve conflicts Define Measures of Effectiveness (MoE) for these capabilities in units meaningful to the customer and connect each MOE to a Mission need statement Develop an Integrated Master Plan for the sequence of delivering the needed Capabilities DEFINE OPERATIONAL CONCEPTS WITH SCENARIOS OR USE CASES Define scenarios for each system capability, and the measureable benefits to the program’s outcomes Connect these scenarios in a Value Stream map showing the sequence of work and the produced value Assess value flow through the map for each needed capability Identify capability mismatches and make corrections to improve overall value flow ASSESS NEEDS, COST, AND RISK OF THE CAPABILITY SIMULTANEOUSLY Assign costs to each system element using a value process model Assure risk, probabilistic cost and benefit performance attributes are defined Use cost, schedule, and technical performance probabilistic models to forecast potential risks to program performance DEFINE EXPLICIT, BALANCED, AND FEASIBLE ALTERNATIVES Make tradeoffs that connect cost, schedule, and technical performance in a single “trade space” model Measures of Effectiveness and Measures of Performance are the raw materials for these tradeoffs 2. Establish Requirements Baseline – DEFINE MEASURES OF PERFORMANCE (MOP) PERFORM FACT FINDING Produce an overall statement of the problem in the operational context Develop the overall operational and technical; objectives of the target system through Measures of Performance (MoP) for the requirements Define the boundaries and interfaces of the target system GATHER AND CLASSIFY THE REQUIREMENTS Gather required operational capabilities, functional, nonfunctional, and environment requirements and design constraints Build a Top Down Capabilities and Functional decomposition of the requirements in a flow down tree using a requirements tool EVALUATE AND RATIONALIZE REQUIREMENTS Answer the question “why do we need this?” in terms of operational benefits Build a cost / benefit model using probabilistic assessments of all variables and dependencies For technical requirements, perform a risk assessment to the cost and schedule PRIORITIZE REQUIREMENTS Determine the criticality for the functions for the system’s mission Determine tradeoff relations for all requirements to be used when option decision are made For technical items, prioritize the cost and dependencies INTEGRATE AND VALIDATE REQUIREMENTS Address completeness of requirements by removing all TBD items Validate the requirements agree and are traceable to capabilities, goals, and the mission Resolve any requirement inconsistencies and conflicts Chapter IChapter IPerformance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 201760 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017
  61. 61. 3. ESTABLISH PERFORMANCE MEASUREMENT BASELINE – DEFINE TECHNICAL PERFORMANCE MEASURES (TPM) Performance–Based Project Management® DECOMPOSE REQUIREMENTS INTO WORK PACKAGES AND PLANNING PACKAGES Decompose the program scope into a product based Work Breakdown Structure (WBS) Decompose the WBS into Work Packages describing the production of all deliverables and processes traceable to the requirements ASSIGN ACCOUNTABILITY FOR THE DELIVERABLES FROM EACH WORK PACKAGE Assign accountability for Work Packages to a named owner for the management of resource allocation, cost baseline, and technical delivery ARRANGE WORK PACKAGES IN A LOGICAL ORDER Arrange Work Packages in a network with defined deliverables, milestones, internal and external dependencies, appropriate schedule and cost margin DEVELOP THE BUDGETED COST FOR WORK SCHEDULED (BCWS) FOR EACH WORK PACKAGE AND PLANNING PACKAGE Develop a time‒phased Budgeted Cost for Work Scheduled (BCWS) for labor and material costs in each Work Package Develop a time‒phased Budgeted Cost for Work Scheduled (BCWS) for the program as a whole Assure proper resource allocations can be met and budget profiles match expectations of the program sponsor ASSIGN WORK PACKAGE MEASURES OF PERFORMANCE (MOP), KEY PERFORMANCE PARAMETERS (KPP), AND TECHNICAL PERFORMANCE MEASURES (TPM) Assign an objective Measure of Performance (MoP) for each critical Work Package deliverable Trace critical deliverables to the Measure of Effectiveness (MoE) defined in the Capabilities baseline Summarize these Measures of Performance (MoP) and Measures of Effectiveness (MoE) for the program as a whole Assign measures of Physical Percent Complete for each Work Package Assign measures of Physical Percent Complete for the program as a whole SET THE PERFORMANCE MEASUREMENT BASELINE (PMB) Establish a Performance Measurement Baseline (PMB) used to forecast Work Package and Project ongoing and completion cost and schedule metrics 4. Execute the Performance Measurement Baseline (PMB) – Maintain Cost, Schedule, and Technical Performance PERFORM AUTHORIZED WORK IN THE PLANNED SEQUENCE Using the Work Package sequencing, release work to be performed as planned With the RACI based RAM, the Accountable delivery manager guides the development of the products or service for each Work Package ACCUMULATE AND REPORT WORK PACKAGE PHYSICAL PERFORMANCE Using Physical Percent complete or Apportioned Milestones, capture the measures of “progress to plan” for each Work Package Report the Physical Percent Complete in a centralized system for each Work Package and he program as a whole ANALYZE WORK PACKAGE PERFORMANCE Compare the Actual Percent Complete against the Planned Percent Complete for each period of performance Construct cost and schedule performance indices from this information and the Physical Percent Complete measures TAKE CORRECTIVE MANAGEMENT ACTION FOR ANY VARIANCE IN WORK PACKAGE PERFORMANCE With the cost and schedule performance indices, construct a forecast of future performance of cost, schedule, and technical performance compliance Take management actions for any Work Packages not performing as planned MAINTAIN PERFORMANCE MEASUREMENT BASELINE’S INTEGRITY Record past performance based on Work Package completion criteria Record previous future performance estimates in a historical database Forecast future performance against the Performance Measurement Baseline Report the future performance estimate to the program stakeholders Chapter IChapter IPerformance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 201761 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017
  62. 62. Program Events Define the availability of a Capability at a point in time. Accomplishments Represent requirements that enable Capabilities. Criteria Represent Work Packages that deliver the Requirements. Work Package Work Package Work Package Work Package Work Package Work Package Work package Structure of a Performance–Based Plan § Each Event or Milestone represents the availability of one or more capabilities. § The presence of these capabilities is measured by the Accomplishments and their Criteria. § Accomplishments are the pre–conditions for the maturity assessment of the product or service at each Event or Milestone § Performance of the work activities, Work Packages, Criteria, Accomplishments, and Events or Milestones is measured in units of “physical percent complete” Integration of Planning and Scheduling ChapterI Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 62
  63. 63. 10 practices guide the deployment of Performance– Based Project Management® and the application of the 5 Process Areas. These 10 practices form the basis of the “theory” of Performance–Based Project Management®, while the Process Areas enable the Principles. II10 Practices Chapter Chapter II63 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017
  64. 64. 10 Practices of Performance–Based Project Management® Assess the capabilities being provided through the deliverables Fulfill the requirements through effort held in the Work Packages Produce deliverables from Work Packages Planned BCWS Physical % Complete WP’s produce deliverables that fulfill requirements Capabilities topology defines requirements flow down WP flow must describe the increasing maturity of the product or service Producing the deliverables in the planned sequence maintains the value stream to the customer ChapterII Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 64
  65. 65. 10 Practices of Performance–Based Project Management® Practices in Order of Increasing Maturity 1 Capabilities drive system requirements. All requirements must be traceable to a capability. Requirements identify technical and process deliverables. All deliverables must be traceable to a requirement. Work Packages describe the production of deliverables. Integrated Master Schedule (IMS) arrange the Deliverables, Accomplishments, Criteria, and Work Packages into a logical – risk adjusted – activity network. Work Package progress is measured as Physical Percent Complete against the planned progress at time of the performance assessment. Work Authorization assures the sequence of Work Packages produce progress at the planned rate for the planned cost, with the planned product maturity at each assessment point in the IMS. Earned Value describes the current performance and provides information about future performance. Conformance with Technical Performance Measures adjusts Earned Value for rework, quality, or delayed features, using Units of Measure meaningful to the decision makers. Performance feedback from each WP and program level Earned Value adjusts the WP sequence and resource allocation to reestablish an on–time, on–budget schedule. Future performance is based on the To Complete Performance Index (TCPI), Independent Estimate At Complete (IEAC), and the adjusted work sequence. ChapterII 65
  66. 66. Capabilities Drive System Requirements The practices for defining a capability address the flexibility needed to ensure system responsiveness and sustainability in a context of constant change, while delivering tangible benefits to the buyer. These include: Agility, Tailorability, and measures of a System Element’s coupling and cohesion. Governance principles provide guidance to institutionalize a process, including its continued assessment and evolution over time in support of the tangible system benefits. These include: Enforced Rules & Responsibilities, Workflow Guidance, Continuous Improvement, Transformation enablers. The core concept of Capabilities Based development is to focus on the delivery of value. The concept of “Value Focused Thinking” starts with two methods of decision making: the 1st focuses on competitive analysis between the various alternatives, and the 2nd focuses on attaining organization values as the fundamental objective of any decision making process. [Pagatto 07] During the development of the Concept of Operations for each capability, assumptions must be made in the absence of specific technical and operational information. To avoid unwelcome surprises, some form of assumptions based planning is needed. 1) Make operational plans, 2) Describe plausible events, 3) Identify the “signposts” for potential problems, 4) Discover shaping actions that shore up uncertain assumptions, and 5) take hedging actions to better prepare for the possibility that an assumption will fail [Dewer02]. Capabilities planning consists of several core processes that describe the system capabilities in the absence of the specific technical or operational requirements. Discover what is not known by reaching a sufficient basic knowledge level setting the problem space. Identify problems by understanding the current process, along with people and technology involved. Establish boundaries and solution elements. These are grouped into five categories: 1. Orientation principles align the process on a sound theoretical basis issued from generally accepted practices in the areas of engineering, modeling, and acquisition. These principles include: Capability Thinking, Architecture Models, Evolutionary Development, and Deliverables Centric planning. 2. Communication principles enforce the standardization of vocabulary and structure of information to be exchanged within or outside the process. These include: Standardized Formats and Common Terminology to describe the system capabilities. 3. Collaboration principles enable active and timely participation of all stakeholders involved in the engineering of a capability. These include: Collaborative Engineering and Information Sharing between the contributors of the system capability elements. ChapterII Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 66
  67. 67. Capabilities Drive System Requirements ¨ Establish the system capabilities by describing the fundamental ideas about the system through the operational behavior. ¨ Do this before the technical and process requirements are elicited. ¨ Use these Operational Concepts (OC) to describe how the system achieves the beneficial outcomes before any commitments are made to the implementation. ¨ Use a Capabilities Based Assessment (CBA) to define gaps in the current system and the approaches to providing capabilities within a specified functional or operational concept. ¨ Construct three capability assessments: Functional Area Analysis (FAA), Functional Needs Analysis (FNA), and Functional Solutions Analysis (FSA). ¤ Functional Area Analysis (FAA) is a capabilities based task analysis that provides the framework for assessing required capabilities for the success of the system. ¤ Functional Needs Analysis (FNA)assesses the ability of the current system to accomplish the needed tasks identified in the FAA, in the manner prescribed by the concept under the operating conditions and to prescribed standards. ¤ Functional Solutions Analysis (FSA) is an operationally based assessment of the potential strategies, organizations, training, leadership and education, personnel, facilities, and materials (technologies) for solving open of more of the capability needs. ChapterII Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 67
  68. 68. Requirements Identify Technical and Process Deliverables Inadequate requirements engineering is a common problem in the development of any complex system. There are many issues associated with requirements engineering, including failure to define the system scope, failure to foster understanding among the different communities affected by the development of a given system, and failure to deal with the volatile nature of requirements. These problems lead to poor requirements and the cancellation of development, or else the development of a system that is later judged unsatisfactory or unacceptable, has high maintenance costs, or undergoes frequent changes. [Young04], [Grady06] By improving requirements elicitation, the requirements engineering process can be improved, resulting in enhanced system requirements and potentially a much better system. Requirements engineering is decomposed into the activities of requirements elicitation, specification, and validation. Most of the requirements techniques and tools today focus on specification, i.e., the representation of the requirements. The Performance–Based Project Management® approach concentrates on elicitation concerns, those problems with requirements engineering that are not adequately addressed by specification techniques. The elicitation methodology to handle these concerns. Is provided by [Cristel92]. Whatever the actual process used, the following activities are fundamental to all Requirement Engineering processes:[Sommerville05] § Elicitation – Identify sources of information about the system and discover the requirements from these. § Analysis – Understand the requirements, their overlaps, and their conflicts. § Validation – Go back to the system stakeholders and check if the requirements are what they really need. § Negotiation – Inevitably, stakeholders’ views will differ, and proposed requirements might conflict. Try to reconcile conflicting views and generate a consistent set of requirements. § Documentation – Write down the requirements in a way that stakeholders and software developers can understand. § Management – Control the requirements changes that will inevitably arise. ChapterII Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 68
  69. 69. Requirements Identify Technical and Process Deliverables ¨ Derive the system requirements for each system capability. ¨ Assure a requirement exists for each system capability needed to fulfill the mission of the system. ¨ Develop the traceability from capabilities to requirements to produce a “minimalist” system, with each requirement being present only because of a needed system or mission capability. ¨ Test requirements by answering the question “why do we need this feature, function, service, or capability?” ¨ Create Technical Performance Measures: [IEEE 1220] ¤ High priority requirements that have an impact on: mission accomplishment, customer satisfaction, cost, system usefulness. ¤ High risk requirements or those where the desired performance is not currently being met: the system uses new technology, new constraints have been added, the performance goal has been increased, but the performance is expected to improve with time. ¤ Requirements where performance can be controlled. ¤ Requirements where the program manager is able to rebalance cost, schedule and performance. ChapterII Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 69
  70. 70. Work Packages Describe Production of Deliverables Staying focused on decomposing the system capabilities into clearly defined streams of functionality is a critical success factor. This effort decouples the technical functionality from the system capabilities – increasing cohesion and reducing coupling between each stream. This decomposition is almost never optimal the first time around. The false sense of urgency to decompose the system requirements into a Work Breakdown Structure will cause extra work later on. Investing in a carefully developed WBS will pay back later in the program by isolating the work processes into supporting value streams. There is no set of instructions on how to do this. But starting the WBS in a graphical form, putting that diagram on the wall and asking coupling and cohesion questions about the terminal nodes in the WBS is one way to “test” to goodness of the WBS. The construction of the Work Breakdown Structure (WBS) starts with the decomposition of the requirements into collections of deliverables. Focusing on the deliverables is critical. The Work Packages that result from this decomposition are the vehicles for producing the deliverables. When these deliverables exist they provide the capabilities requested by the system to perform it function. All resources – internal and external, their dependencies, and any other items needed to produce the deliverables – are defined in Work Packages. The Work Package Manager is accountable for managing all these resources. If resources are not under the control of the Work Package Manager, the risk to the success of the deliverables is greatly increased, because … Accountability is no longer traceable to a single person – violating the principles of the Responsibility Assignment Matrix. Performance reporting for Physical Percent Complete is no longer represented by tangible items within Wok Package. Each Work Package produces one deliverable. This deliverable may have a Technical Performance Measure attached – a Measure of Performance (MoP) or Measure of Effectiveness (MoE). These Technical Performance Measures connect the dots between Cost, Schedule, and Technical maturity of the deliverable. In the absence of Technical Performance Measures, the Performance Measurement Baseline lacks the ability to connect physical percent complete with the increasing maturity of the product or service. ChapterII Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 70
  71. 71. Work Packages Describe Production of Deliverables ¨ Use the Work Packages (WP) executable tasks to produce deliverables at the conclusion of each WP duration. ¨ Avoid connections between WPs that are not Finish‒to‒Start at the WP boundaries, this “hides” dependencies. ¨ Work contained in the WP produces a single or small number of deliverables. ¨ Use performance measures at the Work Package level to assess the progress of the increasing maturity of the deliverables produced by each WP. ¨ Do not measure effort, the passage of time, or consumption of resources as assessments of progress. ¨ Use apportioned milestones, 0%/100%, 50%/50%, and other forms of incremental physical progress as a credible measures of percent complete at the WP level. ¨ When performance measures of actual delivered value are used, the physical progress of the program becomes a credible measure success. ¨ Measuring Earned Value for each task within the WP may be of little value for the program without a measure of Technical Performance (Measures of Effectiveness and Measures of Performance). ChapterII Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 71
  72. 72. Master Schedule Sequences Deliverables, and Work Packages in a Network Arranging the Work Packages in a logical network is an iterative process. It should be obvious which major deliverables come first, second and later. Building an initial network, plotting that network in the Big Visible Chart, hanging that chart on the wall and standing in front of it with all the Work Package Managers is part of developing a credible PLAN for the program. The PLAN is the strategy for delivering the business capabilities the customer asked for. With the Big Visible Chart, this strategy is made visible – or at least more visible than a list of Work Packages. The strategy for delivering the program should be mapped out in some wall walk manner to make the connections obvious. This hands on approach is much better than burying the relationships in a program plan or spread sheet. Making the first cut is a hands on process. The arrangement of Work Packages should start with some simple rules: 1. All relationships are Finish to Start. This initial arrangement provides visibility into the dependencies that will drive schedule compression. Non FS relationships create opportunities to use partially complete work in future efforts, resulting in “rework,” the predecessor efforts are complete. 2. There should be no “lead” or “lag” arrangements. These create hidden dependencies and hidden schedule compression. 3. The only constraints on the network should be a “Must Start On” (MSO) for the start date and “As Soon As Possible” (ASAP) for all other activities. Any other constraints create hidden dependencies. This appears harsh at first, but is the basis of an “ideal” schedule. Other constraints may be added later, but only for necessary reasons, that are described in the IMS Narrative. 4. The flow of Work Packages should create a description of the increasing maturity of the products or services of the project – not just the consumption of resources and production of deliverables. This Maturity description should be meaningful to the customer in terms of business capabilities. At this point in time we will be able to perform the following business capabilities. 5. Speaking in these terms, the customer gains insight into the actual progress of the program. Speaking in consumption of resources, production of code, passage of milestones is not that meaningful to the customer 6. Point estimates of cost and schedule are meaningless without the range of possibilities, the level of certainty in achieving each value, and how these estimates impact the credibility that the program will complete on time, on schedule, and with the planned technical performance. ChapterII Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 72
  73. 73. Master Schedule Sequences Deliverables, and Work Packages in a Network ¨ Arrange Work Packages in an un–constrained Activity Network. ¨ This network is a description of the flow of increasing maturity of the product or service resulting from the completion of each Work Package. ¨ This network answers the 6 critical questions needed for success: ¤ Who is responsible for performing this the work? ¤ What are the constituent components of the work and what is the evidence that they are complete? ¤ When is this the work required to be completed? ¤ Where will this work be performed? ¤ Why does this work need to be done? ¤ How does this support the acceptance of the product or service by the customer? ¨ Postpone the detailed scheduling until there is a credible WP process flow increases the visibility into dependencies as well as programmatic and technical risk and its mitigation. ¨ Define the Exit criteria for each WP the describes what “done” looks like and what technical maturity is needed to proceed to the next WP. ¨ The schedule of work within the WP can then be developed by the “owners” of the work effort – the Work Package Manager (Control Account Manager). ¨ Cost, Schedule, and Technical Performance values must be described in statistical terms, within a range of possible values and the probability of their occurrence. ChapterII Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 73
  74. 74. Work Package Progress Measured as Physical % Complete Against Plan Measuring progress to plan can ONLY be done with Physical Percent Complete (PPC). Any other measure of progress can not be connected to the delivery of business value to the customer. This is the basis of Earned Value and it is also the basis of Agile Software Development methodologies. Deliver working code at all times. Using the 0% /100% assignment or the Apportioned Milestone assignment, the Physical Percent Complete is multiplied by the Budgeted Cost of Work Scheduled (Planned Value, PV) for the entire Work Package to produce the Budgeted Cost of Work Performed (Earned Value, EV). PMI has used BCWP(EV) = PPC X Budget at Completion, where BAC = Sum(all Work Packages BCWS) This is the ONLY way BCWP(EV) can be produced. Any other way creates an invalid baseline measure of progress to plan. With the Work Packages defined, the BCWS(PV) spreads for each Work Packages established and the Work Packages assembled into a credible network, a Performance Measurement Baseline can be established. Step by Step check list for setting the baseline: 1. All BCWS spreads have been balanced against available resources for that Work Package and the program as a whole. This is a long, difficult and very unpleasant process. But letting a scheduling tool do this work has several undesirable outcomes: § The longest date usually results, since the tool spreads the resources according to their availability. § The planners of the program will not actually understand the resource spreads assigned by the machine § The day to day decisions of assigning work will now be removed from those who can make the decisions § The visibility into the logical process of assigning work is lost and the planners are simple observers 2. All Work Packages have apportioned milestones, 0/100, 50/50, or 25/75 assignments of Earned Value (BCWP)(EV) 3. All data fields in the schedule have been assigned and checked ChapterII Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 74
  75. 75. Work Package Progress Measured as Physical % Complete Against Plan ¨ Measure progress as Physical Percent Complete to provide a credible assessment of the increasing maturity of the delivered product or service. ¨ Use each work activity in the Work Package to provide some form of progress toward producing the deliverable. ¨ Use this progress as an incremental measure of the overall progress of the Work Package. ¨ Predefine how each work effort contributes to the overall progress of the Work Package. ¨ Have the Work Package owner describe the incremental Physical Percent Complete is terms of tangible evidence of progress to plan. ¨ Assure what “done” looks like is defined in terms of the Physical Percent Complete of the Work Package, Measures of Effectiveness, and Measures of Performance. ¨ Capture this definition in the Work Package documentation. ¨ Ask the question: ¤ How Long Are You Willing to Wait Before You Find Out You Are Late? ¨ Measure physical progress to plan soon enough before that period of performance arrives, so management corrections can be made to stay on cost, schedule and technical performance. ChapterII Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 75
  76. 76. Work Authorization Assures Work Packages Produce Planned Progress The work authorization system is used by the program manager and his or her designees in order to approve all work throughout the course of the current program management venture. The work authorization system will typically be in the form of a list of formally adopted and well‒ documented procedures. Work authorization procedures specifically detail who may authorize work to be completed and how those authorizations may be obtained. These procedures will include which documents must be completed prior to work being initialized, and whether there are any other prerequisites to work being performed at any particular level during the program. To better assist the efficiency of program management in larger programs, work authorization systems sometimes detail the timeline of the program. For instance, the work authorization system might include at which points in time certain portions of the program should be completed, in which order those tasks are to be completed, and by whom. It is important for program management to be aware of how they convey the work authorization to their staff. To ensure that spoken words are not misinterpreted, written directions for the Work Packages provide explicit guidance. The Work Package can be anything which might need to be accomplished to produce a deliverable. By providing a written work authorization, those in program management can be assured that their wish to have the job done by the right people, at the correct time, and in the right order. The Project Manager needs to be cautious to write out the exact steps on the work authorization. This prevents misunderstandings and mistakes along the line. To have the work done correctly the first time, the manager must have good communication skills with his workers, both in the writing of the authorization and in answering any questions which might arise. Proper direction given to employees in the work permitting directive will ensure that the task is completed in the expected manner. ChapterII Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 76
  77. 77. Work Authorization Assures Work Packages Produce Planned Progress ¨ Executing the Work Packages (WP) in the agreed sequence assures the program proceeds as planned. ¨ This approach starts with a Work Authorization and control processes and continually monitors, Late Starts, Late Finishes, Schedule Margin erosion, and Technical Performance Measure compliance. ¨ Work Authorization does not inhibit the performance of work, but assures that work is performed in the planned sequence with the planned programmatic risk reduction, to continuously increase the maturity of the product or service. ¨ “Out of sequence work” creates programmatic and technical risks: ¤ It disrupts the Earned Value calculations – work without a budget in the planned period is an overrun. Planned budget without actual work being performed is recorded as an under run. In both cases EV is reported improperly. ¤ The strategy developed for sequencing work to increase the maturity of the product or service is disrupted. ChapterII Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 77
  78. 78. Earned Value Describes Current Performance From the ANSI‒748 Guideline: § The Earned Value Management System (EVMS) incorporates business best practices to provide strong benefits for program or enterprise planning and control. § The processes include integration of the program scope, schedule, and cost objectives, establishment of a baseline plan for accomplishment of program objectives and the use of earned value techniques for performance measurement during the execution of the program. § The EVMS provides a sound basis for problem identification, corrective actions, and management replanning as may be required. § Any Earned Value Management System must: § Plan all work scope for the program through completion. § Integrate program work scope, schedule, and cost objectives into a baseline plan against which accomplishments can be measured. § Objectively assess accomplishments at the work performance level. § Analyze significant variances from the plan and forecast impacts. § Provide data to higher levels for management decision making and implementation of management actions. For the benefits of Earned Value to be fully realized, thorough planning, combined with the establishment and maintenance of a baseline for performance measurement is needed. The combination of advanced planning, baseline maintenance, and earned value yields earlier and better visibility into program performance than is provided by non‒integrated methods of planning and control. The key to success is to establish the performance baseline at the Work Package level. The Work Package is the point at which work is planned, progress is measured, and earned value computed. ChapterII Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 78
  79. 79. Earned Value Describes Current Performance ¨ Recognize Earned Value is cost based. Cost Variance and Schedule Variance have the same units of measure – Dollars. ¨ Use the To Complete Performance Index (TCPI) and the Independent Estimate At Completion (IEAC) as measures of progress derived from Earned Value. But they are also measured in dollars. ¨ Using the TCPI and IEAC, the program manager has visibility into the work performance needed to stay on schedule and the forecast cost of this effort. ¨ Recognize the credibility of these indices depends on the credibility of the underlying earned value numbers. This is the primary motivation for maintaining good data on the program. Otherwise the Earned Value numbers are not only wrong, they provide no real value for guiding management in decisions that impact the future performance of the program. ¨ Consider using Earned Schedule [ES] to complement Earned Value [PMI EV]. Earned Schedule is a method of deriving schedule performance from Earned Value data [Lipke], [Henderson04], [Vanhoucke] ChapterII Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 79
  80. 80. Conformance with Technical Performance Measures Adjusts EV Performance Values Technical Performance Measures (TPMs) are traditionally defined and evaluated to assess how well a system is achieving its performance requirements. Typically, dozens of TPMs are defined for a system. Although they generate useful information and data about a system’s performance, little is available in the program management community on how to integrate these measures into a meaningful measure of the system’s overall performance risk. TPMs may be combined to measure and monitor the overall performance risk of a system. The approach consists of integrating individual technical performance measures in a way that produces an overall risk index. The Program Manager must be cognizant of three basic program elements (baselines): § Cost § Schedule § Technical Performance The first two are tracked through cost and schedule control systems (earned value). The last is tracked through the technical performance measurement (TPM) system. TPM is the program manager’s early warning system, when correlated to cost and schedule reports, to provide the complete status of the program. The TPM method includes selecting Technical Performance Parameters; assigning weights; linking to CWBS; planning progress over time; getting data; evaluating variances; and taking corrective action as needed. Variances indicate level of risk and detect new risks before their effects on cost/schedule are irrevocable. The TPM approach involves: § Assessing technical characteristics of the system and identify problems through tests/analyses. § Surfacing inadequacies in time and dollars. § Complements cost/schedule performance measurement § Providing a basis for cost/schedule revisions. § Facilitating the verification of results achieved against technical requirements and what remaining technical work can be accomplished within established budgets. ChapterII Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 80
  81. 81. Conformance with Technical Performance Measures Adjusts EV Performance Values ¨ Adjust the “Earned Value” forecast of future performance by the compliance with Technical Performance Measures (TPM). ¨ Correlate Technical Performance Measures with cost and schedule to provide the complete status of the program. ¨ Use Technical Performance Measures to add “technical achievement” to Earned Value’s cost and schedule metrics. ¨ Assess the program’s progress in terms of technical compliance, potential rework, postponed functionality (to later Work Packages or rolling waves) and other dilutions of the physical progress of the program. ¨ Use Technical Performance Parameters (TPPs) to indicate key areas for risk reduction and program success. ¨ Technical Performance Measures (TPMs) are a time–phased progress plan for achievement of critical TPPs. ChapterII Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017 81

×