Successfully reported this slideshow.

Chapter 0 of Performance Based Project Management (sm)

1,053 views

Published on

Defining the needed capabilities is the critical success factor proejct success. The capabilities state what Done looks like in units of measure meaningful to the decision makers.

Published in: Business, Technology
  • Be the first to comment

Chapter 0 of Performance Based Project Management (sm)

  1. 1. Chapter Performance-Based Project Management(sm) integrates Principles, Practices, and Processes to assure actionable information is provided to the decision makers that can increase the probability of program success. 0 Performance-Based Project Management(sm) in a Nutshell 1 Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 Chapter 0
  2. 2. Performance-Based Project Management Management(sm) In A Nutshell 5 Principles, 5 Practices, and 5 Processes to Increase The Probability of Project Success Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 2 Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 Chapter 0
  3. 3. Why Performance-Based Project Management(sm)? §  For projects to be successful they must deliver capabilities: §  Not the work efforts, §  Not the cost expenditures, §  Not the documentation, test results, or the processes. Performance-Based Project Management(sm) Principles, Practices, and Processes for Increasing the Probability of Project Success† † Program Success Probability, John Higbee, Defense Acquisition University, 9 May 2005 Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 §  Projects must deliver tangible beneficial outcomes, measured in units meaningful to the decision makers. 3/230
  4. 4. Five Immutable Principles of Project Success in the form of questions … 1.  What Does DONE Look Like? 2.  How Do We Get to DONE? 3.  Is There Enough Time, Resources, And Money To Get to DONE? 4.  What Impediments Will Be Encountered Along The Way to DONE? 5.  What Are The Units Of Measures For Progress To Plan for each Deliverable? Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 4
  5. 5. 5 1. Organization Define the Work Breakdown Structure(WBS). Indentify the Organizational Breakdown Structure (OBS). Integrate the WBS and OBS. ¨  ¨  ¨  ¨  2. Planning and Budgeting ¨  Schedule the work. ¨  Identify the Products and Milestones. ¨  Set the time phased budget. Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 ¨  ¨  ¨  ¨  3. Accounting Record direct costs. 4. Performance Analysis Determine variances. Sum Data and variances. Manage action plans. 5. Revision Management ¨  Incorporate Changes. Chapter 0 5 Critical Process Areas that Answer the 5 Principle Questions of Project Success
  6. 6. 6 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) ¨  Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 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) ¨  Chapter 0 Credible Data Is Need to Increase The Probability Of Program Success
  7. 7. 7 Systems Management is the set of organizational structures and processes that 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. ¨  PBPM connects the data to provide actionable information to the decision makers. ¨  Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 Chapter 0 Systems Management Guides the Conversion of this Data to Produce Actionable Information
  8. 8. 8 Program Process Capabilities Program Enablers Business Enablers Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 Chapter 0 16 Program Management Processes
  9. 9. 9 ¨  Capabilities start with a mission level analysis. This is planning in the large. ¨  This is planning in the presence of change. ¨  The focus is on transformational outcomes. ¨  Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 www.rand.org Chapter 0 Origins of Performance-Based Project Management(sm)
  10. 10. 10 Performance-Based Project Management(sm) integrates five critical program management process areas with – Cost, Schedule, and Technical Performance Measures. The inclusion of Technical Performance Measures (TPM) separates is 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(sm), 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 define 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). Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 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 a 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 customer. The best tangible evidence are the Deliverables needed to meet the requirements that fulfill the system’s requested capabilities that are 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. Chapter 0 Performance-Based Project Management(sm) 4+1 questions every project must answer
  11. 11. The 4+1 Questions Every Project Must Answer to be Successful Capabilities Requirements Plans Execution + Continuous Risk Management 1.  What capabilities are needed to fulfill the Concept of Operations†, Œ the Mission and Vision, or the Business System Requirements? 2.  What technical and operational requirements are  needed to deliver these capabilities? 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?  † 11 What impediments to success, their mitigations, retirement plans, or “buy downs are in place to increase the probability of success?” 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. Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 Chapter 0
  12. 12. 12 Project Management Case Study, Pierre Bonnal, CNAM IIM MBA Program, June 2004 Chapter 0 Performance-Based Project Management(sm) Addresses …
  13. 13. Identify Needed Capabilities System Value Stream Operational Needs Capabilities Based Plan Identify Requirements Baseline Technical Performance Measures Technical Requirements Establish a Ž Performance PMB Measurement Baseline Technical Performance Measures Changes to Needed Capabilities Changes to Requirements Baseline Earned Value Performance 0% /100% Execute the  Performance Changes to Performance Baseline Measurement Baseline  13 Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 Chapter 0
  14. 14. 14 1.  Identify Needed Capabilities to achieve program objectives or a 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 and 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 a 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 all requirement are traceable to work and all work is traceable to requirements. 5.  Perform Continuous Risk Management for each Performance-Based Project Management(sm) process area to Identify, Analyze, Plan, Track, Control, and Communicate programmatic and technical risk. Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 The integration of these five process areas is the foundation of Performance-Based Project Management(sm). 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 developed, 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 maturity 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. Chapter 0 Increasing the Maturity of Project Processes and Deliverables with Meaningful Measures
  15. 15. 15 Identify Needed Capabilities Indentify Baseline Requirements Establish Performance Measurement Baseline Execute Performance Measurement Baseline Perform Continuous Risk Management (CRM) § Define Capabilities § Define ConOps § 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 BCWS § Assign Performance Define the Measurable Capabilities of each Project Outcome Assure All Requirements Provided In Support of Capabilities Define Measures of Performance and Effectiveness Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 § Perform Work § Accumulate Performance Measures § Analyze Performance § Take Corrective Action Ensure Cost, Schedule, and Technical Performance Compliance Chapter 0 Increasing the Maturity of Project Work Processes and Their Deliverables
  16. 16. 16 Project Management Case Study, Pierre Bonnal, CNAM IIM MBA Program, June 2004. Chapter 0 What is a Deliverable?
  17. 17. Œ 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(sm) process area to: Identify, Analyze, Plan, Track, Control, and Communicate programmatic and technical risk. 17 Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 Chapter 0
  18. 18. Œ Define the capabilities needed to achieve the desired objectives 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 § 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. 1.2 § 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. 1.3 § 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. 1.4 § 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. 18 Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 Chapter 0
  19. 19. 19 Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 Chapter 0 What Does A Capability “Sound” Like?
  20. 20. 20 Identifying System Capabilities is the starting point for any successful program. System Capabilities are not direct requirements, but statements of what the system should provide in terms of “abilities.” For example there are three capabilities needed for the Hubble Robotic Service Mission: 1.  Do no harm to the telescope. 2.  Change the Wide Field Camera. 3.  Connect the battery umbilical cable. How is this to be done and what are the technical, operational, safety and mission assurance requirements? Don’t really known 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?” Capabilities 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. Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 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. Chapter 0 Identifying Needed System Capabilities
  21. 21. Chapter 0 Identifying Needed System Capabilities 21 What Should We Do? Where Are We Now? 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 Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013
  22. 22.  Define the technical and operational requirements that must be present 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 § 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. 2.2 2.3 2.4 2.5 22 § 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. Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 Chapter 0
  23. 23. 23 Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 Chapter 0 What Is a Requirement?
  24. 24. 24 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. Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 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 product 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 are “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). Chapter 0 Identifying Requirements
  25. 25. 25 †Systems Requirements Practices, Jeffery O. Grady, McGraw Hill, 1993 Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 Chapter 0 Identifying Requirements†
  26. 26. Ž 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. 3.1 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.2 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.3 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.4 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.5 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.6 Establish a Performance Measurement Baseline (PMB) used to forecast the Work Package and Project ongoing and completion cost and schedule performance metrics. 26 Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 Chapter 0
  27. 27. 27 Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 Chapter 0 What Does a Credible Plan and Schedule Look Like?
  28. 28. 28 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. The Technical Performance Baseline represents the requirements flow down and traceability map for each deliverables in the program. 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. §  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. 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 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 DI-MGMT-81861. The concept of Performance-Based Project Management(sm) is. 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. §  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: Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 Chapter 0 Establishing the Three Elements of the Performance Measurement Baseline
  29. 29. Chapter 0 Establishing the Three Elements of the Performance Measurement Baseline 29 Perform Functional Analysis Technical Baseline Determine Scope and Approach Develop Technical Logic Develop Technical Baseline Estimate Time Durations Sequence Activities Approve PMB Develop WBS Define Activities Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 Finalize Apportioned Milestones Identify Apportioned Milestones Schedule Baseline Cost Baseline Finalize Schedule Determine Resource Requirement Prepare Cost Estimate Resource Load Schedule Determine Funding Constraints
  30. 30.  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. 4.1 § 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.2 § 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.3 4.4 4.5 30 § 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. § 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. § 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. Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 Chapter 0
  31. 31. 31 Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 Chapter 0 How Do We Know We Are Making Progress to Plan?
  32. 32. 32 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?” Management(sm) In the Performance-Based Project 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(sm). The measures of physical percent complete can be applied on weekly boundaries in a variety of 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. Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 Chapter 0 Executing the Performance Measurement Baseline (PMB)
  33. 33. 33 Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 Chapter 0 Executing the Performance Measurement Baseline (PMB)
  34. 34.  Continuous Risk Management starts 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 § Identify and classify risks in a Risk Register. § Manage this Risk Register through a Risk Management Board. § Connect these risks and their handling in the Master Schedule. 5.2 § 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. 5.3 § Turn risk information into decisions and actions (both present and future). § Develop actions to address individual risks, prioritize risk actions, and create an integrated risk management plan. 5.4 § 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. 5.5 § 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. 34 Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 Chapter 0
  35. 35. 35 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 Statement of Risk Identify Risks, Issues, and Concerns Analyze Evaluate, classify, and prioritize risks Plan Decide what should be done about each risk Program/project data (metrics information) Tr a c k Monitor risk metrics and verify/ validate mitigations Control Make risk decisions Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 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 Chapter 0 Perform Continuous Risk Management
  36. 36. 36 For project success to have a chance, we need all the parts of the project’s architecture to be in place. This starts with the Statement of Work (SOW), the Concept of Operations (ConOps), Statement of Objectives (SOO)and similar narrative documents and 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 (WBS) 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. Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 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. Chapter 0 Integrating all the Parts Into a Whole
  37. 37. Chapter 0 Integrating all the Parts into a Whole 37 SOW   Techncial  and  Opera9onal   Requirements   Customer   Key  Performance  Parameters   (JROC  KPP)   WBS   SOO   ConOps   CWBS  &   CWBS  Dic9onary   Program  Specific   Key  Performance  Parameters   (KPP)   Measures  of   Effec9veness   (MoE)   Integrated  Master  Plan   (IMP)   Measures  of   Performance   (MoP)   Integrated  Master  Schedule   (IMS)     Measures  of   Progress   Earned  Value  Management   System   Technical  Performance   Measures  (TPM)   Performance  Measurement  Baseline   Risk  Management   Objec9ve  Status  and  Essen9al  Views  to  support  the  proac9ve  management  processes  needed  to  keep  the   program  GREEN  
  38. 38. 38 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. 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. These measures are stated in units ,meaningful to the buyer. They focus on the capabilities independent of any technical implementation. TPMs assess design progress, define compliance to performance requirements, identify technical risk, are limited to critical thresholds, and include projected performance goals. Measures of Performance (MoP) – characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions. 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. 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). Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 Chapter 0 From Mission Capabilities to Done
  39. 39. Chapter 0 From Mission Capabilities to Done 39 Acquirer  Defines  the  Needs  and  Capabili9es   in  terms  of  Opera9onal  Scenarios   Supplier  Defines  Physical  Solu9ons  that   meet  the  needs  of  the  Stakeholders   KPP   Mission  Need   “Coming  to  Grips  with  Measures  of   Effec9veness,”  N.  Sproles,  Systems   Engineering,  Volume  3,  Number  1,  pp.  50–58   MoE   MoP   Opera&onal   measures  of  success   related  to  the   achievement  of  the   mission  or   opera&onal   objec&ve  being   evaluated.   Measures  that   characterize   physical  or   func&onal  a<ributes   rela&ng  to  the   system  opera&on.   TPM   Measures  used  to   assess  design   progress,   compliance  to   performance   requirements,  and   technical  risks.  
  40. 40. 40 Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 Chapter 0
  41. 41. 41 Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 Chapter 0
  42. 42. Chapter 0 4+1Critical Success Processes 42 Capabilities, Requirements & Deliverables Program Architecture & Dependencies Work Planning and Sequencing Performance Measurement Baseline Programmatic & Technical Risk Management § Risk Registry § Risk Handling Plans § Contingency And Management Reserve § Risk Integrated With IMS § Risk Trending § Balanced Scorecard § Aligned Organization Strategy § Integrated Master Plan (IMP) § Gaps § Overlaps § Interfaces § Integrated Master Schedule (IMS) § Cost And Schedule Baseline § WBS, RAM, Resource Loaded IMS § Requirements Traceability § Value Stream Mapping § Work Packages § Planning Packages § Technical Performance Measures (TPM) § Earned Value Management § Measures Of § Monte Carlo Performance (MoP) Simulation § Measures Of § Design Structure Effectiveness (MoE) Matrix (DSM)
  43. 43. Chapter 0 Program Support Services 43 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
  44. 44. 44 P-B PM Capabilities Benefits to the Customer Program, Planning, and Controls Rapid creation of the risk adjusted Performance Measurement Baseline. Earned Value Management ANSI‒748B 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. Chapter 0 Tangible Benefits of Performance-Based Project Management(sm)
  45. 45. Performance-Based Project Management(sm) 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? 45 Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 Chapter 0
  46. 46. 46 Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013 Chapter 0

×