SE1 - Integrating SE and PPM to Increase the Probability of Success
•Descargar como PPTX, PDF•
0 recomendaciones•109 vistas
The document discusses integrating systems engineering and project performance management to increase the probability of project success. It argues that both are needed and describes how they can be integrated through a process-centric solution. Specifically, it advocates bringing together systems engineering processes like requirements analysis with project management processes like cost, schedule, and risk management. The goal is to consider both the technical and programmatic aspects of a project as a whole in order to deliver needed capabilities on time and within budget.
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a SE1 - Integrating SE and PPM to Increase the Probability of Success
Similar a SE1 - Integrating SE and PPM to Increase the Probability of Success (20)
Más de Glen Alleman
Más de Glen Alleman (20)
Último
Último (20)
SE1 - Integrating SE and PPM to Increase the Probability of Success
- 1. SE1 Integrating Systems Engineering (SE) and Program Performance Management (PPM) to Increase the Probability of Delivering Needed Capabilities for Project/Program Success 1 Quotes and References Attributed in Thursday’s Worksh Glen B. Alleman Tuesday 20 August 2019 1:10PM ‒ 1:50PM
- 2. 2 PGCS 2019 Master Workshop, 21‒22 August, Canberra Australia
- 3. Systems Engineering and Project Performance Management Both Needed For Success3 PGCS 2019 Key Note, Canberra Australia Increasing Probability of Program Success Delivering Needed Capabilities for Program Success Measures of Effectiveness Measures of Performance Key Performance Parameters RiskManagement Arrive at Needed Time for Needed Cost for Program Success Technical Performance Measures Schedule Performance Measures Cost Performance Measures Introduction
- 4. Seeing the Three Phases of Project as a Whole is the Foundation of Systems Thinking4 PGCS 2019 Master Workshop, 21‒22 August, Canberra Australia Concept Design and Delivery Operation and Support Introduction Quotes and References Attributed in Thursday’s
- 5. Transformation Context of SE + PPM 5 PGCS 2019 Master Workshop, 21‒22 August, Canberra Australia Mechanistic Differentiated Work the people Top-Down, Managed In Parallel Efficiency Oriented Systemic Integrated team based Work the work Outside-In, Lead Each Other, for Each Other Complexity, Robust Introduction Quotes and References Attributed in Thursday’s
- 6. 6 PGCS 2019 Master Workshop, 21‒22 August, Canberra Australia For each Idea on Integrating Systems Engineering and Project Management, We Need to Assess the Idea with Measures of Effectiveness and Measures of Performance, to see How These Increases the Probability of Project Success We need both Efficiency (Cost, Schedule, Requirements) and Efficacy (Capabilities, Effectiveness, and Performance) of the Project Success
- 7. Roles of PPM and SE Focused on the Business Requirements When are these needed? How much will they cost? Responsible for designing and operating the control system that manages the work associated with the solution that meets: Technical Performance Measures (TPM) Quantifiable Backup Data (QBD) Focused on the Business Solutions that deliver Capabilities What are they? How are they assembled? Responsible for defining, designing, and delivering this solution that meets: Measures of Effectiveness and Performance [105] Measures of Performance Key Performance Parameters Key System Attributes 7 Project ManagerSystems Engineer PGCS 2019 Master Workshop, 21‒22 August, Canberra Australia Introduction Quotes and References Attributed in Thursday’s
- 8. 8 PGCS 2019 Master Workshop, 21‒22 August, Canberra Australia Project Performance Manager Focused on Business Requirements How Much and When Responsible for designing and operating the project control system to manage work that produces the system Systems Engineer Focused on Business Requirements How Much and When Focused on Business Solution What and How Responsible for Defining, Designing, and Delivering the Solution Introduction Quotes and References Attributed in Thursday’s
- 9. Integrating these Two Perspectives 9 PGCS 2019 Master Workshop, 21‒22 August, Canberra Australia WHEN Project Schedule (IMP/IMS) HOW MUCH Cost Breakdown Structure (CBS) WHY Vision Business Case Risk Register WHO WHAT Product Breakdown Structure (PBS) How Work Breakdown Structure (WBS) Introduction Quotes and References Attributed in Thursday’s
- 10. The Core Failures Resulting from the Separate but Equal Paradigm 10 PGCS 2019 Master Workshop, 21‒22 August, Canberra Australia Capabilities as Scenarios in ConOps Analysis of Alternatives (AoA) Established MOE’s MOP’s, KPP’s and KSA’s Assessment Technical and Operational Needs, Cost, and Risks to needed Capabilities Cost, Schedule, Performance (CSP) measures needed to manage delivery of Requirements Risk Management of C,S, and P Physical % Complete EAC, ETC, TCPI CSP Margin management TLO’ Quotes and References Attributed in Thursday’s
- 11. A Process‒Centric Solution to the Organizational Problem 11 PGCS 2019 Master Workshop, 21‒22 August, Canberra Australia PM Processes Cost Schedule Technical Performance Risk Management SE Processes Mission and Vision Effectiveness Capabilities KPP’s / KSA’s Quotes and References Attributed in Thursday’s
- 12. Overview of the Integration 12 PGCS 2019 Master Workshop, 21‒22 August, Canberra Australia Quotes and References Attributed in Thursday’s
- 13. The World of Engineered Systems 13 PGCS 2019 Master Workshop, 21‒22 August, Canberra Australia
- 14. The World of Project Management 14 PGCS 2019 Master Workshop, 21‒22 August, Canberra Australia Quotes and References Attributed in Thursday’s
- 15. Motivation for Integrating SE and PPM starts with 4 Known Root Causes of Project Failure 15 Unrealistic Performance Expectations, with missing Measures of Effectiveness (MOE) and Measures of Performance (MOP). Unrealistic Cost and Schedule estimates, based on inadequate risk adjusted growth models. Inadequate assessment of risk and unmitigated exposure to these risks without proper handling plans. Unanticipated technical issues without alternative plans and solutions to maintain effectiveness of the product or service. Unanticipate d Growth of Cost and Schedule “Borrowed” with permission from Mr. Gary Bliss, Director Performance Assessment and Root Cause Analyses, Office of Assistant Secretary of Defense for Acquisition, Technology, and Logistics. PGCS 2019 Master Workshop, 21‒22 August, Canberra Australia
- 16. System Engineering Connects the Dots Between all the Project Information 16 PGCS 2019 Master Workshop, 21‒22 August, Canberra Australia Stakeholder Needs Use Cases Operational Scenarios Stakeholder Requirements System Requirement Interfaces System Architectures Verification Objectives Test CasesQuotes and References Attributed in Thursday’s
- 17. The Composite Elements of Systems Engineering 17 PGCS 2019 Master Workshop, 21‒22 August, Canberra Australia
- 18. 18 PGCS 2019 Master Workshop, 21‒22 August, Canberra Australia Work Breakdown Structure defines deliverables Needed Capabilities Requirements Derived from Capabilities Work Packages to produce deliverables in the WBS terminal nodes Credible Work Packages sequences to produce delivered value needed by the business Risk mitigation or retirement shown in the schedule Formal risk management in RM Tool All programmatic data under change control
- 19. 19 Process Inputs Customer Needs Technology base Program Decision Requiremen ts Requiremen ts applied through Specificatio ns and Standards Trade Studies Effectiveness Risk Interfaces Data Configuration Process Outputs Decisions System Configurations Specifications and Baseline † SMC Systems Engineering Handbook, Version 3, FigurePGCS 2019 Master Workshop, 21‒22 August, Canberra Australia Technical Requirements Loop System Design Loop System Verification Loop Project Control Loop
- 20. Summary of These Concepts Mission and Environment Analysis Performance Requirements and Design Constraints Definition and Refinement Functional Requirements Identification Progress Measurements Performance Analysis Control and Manage Select Preferred Alternatives 20 Requirements Analysis Loop System Analysis and Control Loop PGCS 2019 Master Workshop, 21‒22 August, Canberra Australia Verification Loop Lower Level Decomposition Define, Refine, and Integrated Functional Architecure Allocate Requirements to all Functional Levels Define, Refine Internal and External Interfaces Synthesis Transform Architecture from Functional to Physical Define Alternate Product and Process Solution Define Alternate System Concepts, CI’s, System Elements Define, Refine Internal and SE Principles
- 21. 21 SMC Systems Engineering Handbook, VersioPGCS 2019 Master Workshop, 21‒22 August, Canberra Australia
- 22. 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 All Successful Projects Require Credible Answers To These 5 Immutable Principles [59] … 22 PGCS 2019 Master Workshop, 21‒22 August, Canberra Australia
- 23. 16 Elements of Program Management Used to Implement the Five Immutable Principles 23 PGCS 2019 Master Workshop, 21‒22 August, Canberra Australia Business Enablers Program Enablers Program Process Capabilities 15: PPM Process Management 16: PPM Development and Succession 11: Organization/IPD 12: Customer Partnership 13: Program Review Process 14: Configuration/ Data Management 2: Program Planning 3: Performance Management 4: Sub-Contract Management 5: Follow-On Business Development 9: Financial Management 10: Risk Management 7: Requirements Management 8: Schedule Management 6: Earned Value Management 1: Program Management Involvement in Proposal Quotes and References Attributed in Thursday’s
- 24. Capabilities Requirements Plans Execution Continuous Risk Management † A Concept of Operations (ConOps) describes the characteristics of a proposed system from the viewpoint of an individual who will use that system. It is used to communicate the quantitative and qualitative system characteristics to all stakeholders. The 4 1 Elements Needed To Increase Project’s Probability of Success 24 PGCS 2019 Master Workshop, 21‒22 August, Canberra Australia
- 25. The Notional Project 25 PGCS 2019 Master Workshop, 21‒22 August, Canberra Australia We work for an Unmanned Aerial Vehicle (UAV) firm entering the ranching and farming marketplace. We know how to build complex equipment, including flying machines, electronics, and training systems for government agencies. We now want to do the Notional Project
- 26. 26 PGCS 2019 Master Workshop, Canberra Australia
Notas del editor
- PGCS 2019 Key Note, Canberra Australia
- What is the system ‒ the product or service, developed with Systems Engineering and Project Management ‒ is supposed to be doing, when everything is working well is beside the point. That happy path is rarely achieved in practice. The question that must be answered is: The processes and practices of the Integrated Project Performance Management System (IPPMS) need to address: How does the IPPMS fail? How well does the IPPMS function in failure mode? How can we recognize these failure modes and take corrective or preventive actions when they occur?
- The two key-note presentations prior to the work workshop presented the two parallel paradigms of Systems Engineering and Project Performance Management (PPM). The goal of this workshop will be to put these two processes together into a single Integrated Project Performance Management Systems (IPPMS). This integration thread runs throughout the workshop and across all systems based acquisitions. The key to success of this integration is the Units of Measure that form the basis of the collective outcomes between Systems Engineering and Project Performance Management. The failure of integration efforts starts with the failure to establish common and shared units of measure for the performance of all system elements and their products or services
- Systems Thinking helps ask the questions. Systems Engineering helps find the solutions. Project Management helps manage the work efforts needed to produce the solution for the needed budget at the needed time, with the needed Capabilities. To comprehend and manage the project and to develop a solution, we need to have understanding and agreement on the solutions’ boundaries.
- When Systems Engineering and Project Performance Management are isolated, silo are created and arranged in a hierarchy of people, processes, and tools. The notion of an Integrated Project Performance Management System (IPPMS) means all the moving parts are seamlessly connected through processes and their data. The seamlessness starts with an architecture of the connections from the outside in, the same a building architecure does. Another book, anyone working on integrating SE and PPM must have is [4]. The basis for integrating SE and PPM starts and ending with Architecture. Programmatic Architecture is the basis of this integration.
- There are many ideas on how perform Systems Engineering and Project Management. How to deliver the outcomes from the processes and practices. The challenge is to sort out which processes and practices are suitable for each business and technical domain. Then when these processes and practices are integrated, what is the beneficial outcomes of the integration. Measuring the Effectiveness and Performance of the integrated system is the starting point for assessing any suggestions.
- The traditional roles and responsibilities for project managers and systems engineers remains the same in the integrated system What is shared is the execution of the processes of the Integrated Project Performance Management System. It is the process that provides the benefit to the project, with individuals contributed to the shared processes. Systems Engineers define the technical architecture of the solution. Project Managers define the Programmatic architecture of the solution. Combining the programmatic and technical architectures is the role of the Integrated Project Performance Management System (IPPMS). Once cannot be successful without the other. Both interact to increase the probability of success for the solution.
- Systems engineering and project performance management are both required for successful product development. A good systems engineer maintains traceability between the elements of system design (i.e., requirements, functions, components, and verification). Same is true for the project manager using the Work Breakdown Structure (WBS) as the connection point for all other project management artifacts. A WBS is a hierarchical breakdown of products and services. WBS elements are traced to other project management artifacts, such as the Statement of Work, cost estimate, and schedule to keep the entire project aligned. To integrate PPM and SE we need to define what will be integrated and how this will increase the probability of project success Overcome challenges and improve cost, schedule, and technical performance Assess current capabilities and build to the level your organization needs Manage risk throughout all stages of integration and performance improvement Deploy best practices for teams and systems using the most effective tools
- The intersection between Project Management and Systems Engineering shares the answers to two critical questions: Why are we building this? What Capabilities does the stakeholder need to accomplish the mission or business case. Who is going to use it and for what purpose? What are the Measures of Effectiveness and Measures of Performance needed by the stakeholders to be assured there is sufficient probability of success for their investment? For each of the answers to these questions, we need to ask and answer: What can go wrong technically and programmatically?
- When each paradigm ‒ Systems Engineering and Project Management ‒ are separate there are conflicting approaches to managing the project This separation lays the ground work for problems on the project [23] Inadequate articulation of requirements Poor planning Inadequate technical skills and continuity Lack of teamwork Poor communications and coordination Insufficient monitoring of progress Inferior corporate support Other issues include [26] Compartmentalization within each discipline of Project Management and Systems Engineering Lack of cross-education between the disciplines Conflicting priorities and not being flexible Lack of better overlap definition con-ops No clear understanding of what does PPM and SE integration look like?
- Compartmentalization of Project Performance Management vs Systems Engineering Remove process islands Lack of Cross‒Education Apply CMMI integration concepts Establish a common vocabulary Integrate Change Management and Configuration Management Harmonize the project Life-Cycle Develop cross-training Conflicting Priorities Align goals at enterprise level Define decision making at lowest possible level by fixing reporting chain split Develop a common and shared definition of a Concept of Operations Integrating them: Wraps systems engineering around PPM as a system itself Creates and End to end process depiction Measures and metrics for degrees of integration Provides templates and tools for integration support (infrastructure) Rewards for cooperation and collaboration ‒ no more silos Initiates research how to do projects better Provides research of lessons learned done right Make sure independent areas that shouldn’t be integrated
- There are four core approaches for integrating Systems Engineering and Project Management and the Project Performance Management processes. Use standards for both Systems Engineering and Project Management. Select the standards best suited for the domain. Train both domains to assure alignment Write a formal description of the integration processes and the data they produce. Make these description visual. Continuous assess the effectiveness of the integration and take corrective or preventive actions to maintain the effectiveness and performance of the integration. The integration of SE and PPM is based on the integration of the responsibilities and accountabilities for the success of the integration.
- In the broad community, the term system “system,” may mean a collection of technical, natural or social elements, or a combination of all three. This may produce ambiguities at times: for example, does “management” refer to management of the SE process, or management of the system being engineered? As with many special disciplines, SE uses terms in ways that may be unfamiliar outside the discipline. For example, in systems science and therefore SE, “open” means that a system is able to interact with its environment--as opposed to being "closed” to its environment. But in the broader engineering world we would read “open” to mean “non-proprietary” or “publicly agreed upon.” In such cases, the SEBoK tries to avoid misinterpretation by elaborating the alternatives e.g. “system management” or “systems engineering management”.
- Integration management ‒ coordinates all aspects of a project Scope Management ‒ ensure that the project includes all the work required, and only the work required, to complete the project successfully Time Management (planning, forecasting and estimation) ‒ the ability to plan, execute and finish the project in a timely manner Cost Management ‒ processes involved in estimating, budgeting, and controlling costs so that the project can be completed within the approved budget Quality Management ‒ ensure that both the outputs of the project and the processes by which the outputs are delivered meet the requirements of all stakeholders Human Resource Management ‒ identify communications requirements, technologies, constraints and assumptions Communications Management ‒ identify communications requirements, technologies, constraints and assumptions Risk Management ‒ identification, evaluation and prioritization of these risks, followed by a coordinated application of resources to minimize, monitor, and control the probability and impact of risks Procurement Management ‒ the process organizations use to purchase economic resources and business input from suppliers or vendors
- There is extensive research on the Root Causes for project and program failures. I’ve participated in several of these. Here’s a summary of four key causes, developed at the Performance Assessment and Root Cause Analyses(PARCA) organization of the US DoD. You’ll see each of these starts with some form of uncertainty, that creates a risk to the success of the project in its domain – performance, cost, schedule, risk itself and technical issues.
- Systems Engineering is about Information that informs what Done looks like in units of measure meaningful to the decision makers. These measures starts with Measures of Effectiveness and Measures of Performance of the Capabilities produced by the Project to results in the System.
- Solving the puzzle of Systems Engineering means making all the puzzle parts fit properly to form an integrated whole. The Project Management and Project Performance Management pieces include: Integrated Technical Planning The impact and management of risk for Cost and Schedule impacts The integrity of the analysis includes connecting the engineered systems with the cost and schedule aspects of that work and the measurement of Physical Percent Complete for each work item. This measurement is assessed in Technical Performance Measures (TPM) and their Quantifiable Backup Data (QBD)
- For all these processes and their interactions we need to put all this into perspective. While tools and processes are critically important, having the right people in the right “seats on the bus” as Jim Collins would say in “Good to Great,” is as critical. These people must have a deep understanding of how to put the tools to work on their behave or the tools are of little value to the organization. We’ve seen this many times, where a program management or technical groups purchased a tool as the solution to their problems. Only to discover they did not understand the problem, so the tool had no chance of success.
- Customer/User needs, objectives and requirements in terms of capabilities, measures of effectiveness, environments, and constraints initiate the process. Each increment of capability is provided with its own set of attributes and associated performance values. Measures of Effectiveness quantify the results to be obtained and may be expressed as probabilities that the system will perform as required. For example, the chance that an event will be recognized with a certain probability and that the probability of false alarm is below a certain percent. Environments are the natural operating and threat environments, space, airborne, and ground segments. Internal environments, e.g., whether a particular system solution requires air conditioning or cryogenic cooling, are for the Systems Engineer to specify; it is of no consequence to the customer if the solution falls within the overall constraints and requirements. Customer-imposed constraints can take the form of interoperability with existing or other planned systems, operations and maintenance personnel skill level requirements, and costs and schedules.
- The four loops of Systems Engineering is the basis of measuring Physical Percent Complete. The Requirements Analysis loop starts with the needed Capabilities from the Mission and Environment analysis ‒ from which the Design, Performance, and Functional requirements are derived. The Systems Analysis and Control loop assigns progress measures (physical percent complete), analysis of the performance for compliance with the planned performance. Control of this performance through correction or prevention of non-compliance with plan and creation of alternatives. This assessment then requires verification that the performance is proceeding as planned. The last loop provides the process for identifying and creating alternatives when the first three loops show the project is not headed in the right direction.
- The five immutable principles of project management are: Know where you are going by defining “done” at some point in the future. This point may be far in the future – months or years from now. Or closer in the future days or weeks from now. Have some kind of plan to get to where you are going. This plan can be simple or it can be complex. The fidelity of the plan depends on the tolerance for risk by the users of the plan. Understand the resources needed to execute the plan. How much time and money is needed to reach the destination. This can be fixed or it can be variable. Identify the impediments to progress along the way to the destination. Have some means of removing, avoiding, or ignoring these impediments. Have some way to measure your planned progress, not just your progress. Progress to Plan must be measured in units of physical percent complete.
- Here are 16 program management processes that must be in place for any business that depends on managing projects for revenue generation. For the moment we’ll only talk about 7 of these. Planning, measuring performance of the Plan, requirements, finance, earned value, scheduling and risk. 2. You need a plan to know where you are going. 3. You need some way to measure progress of that plan 6. Earned Value tell you how you can measure physical percent complete and with that forecast future performance. 7. Requirements tell you what things you need to produce to meet the plan. 8. You need a schedule of the work, how it will be performed, and what order it will be performed in. 9. Finance, so one has to fund your project and will be asking what you did with their money. 10. Risk is how adults manage projects
- Here’s our first actual learning opportunity. These are the five elements needed to increase the probability of success for your project. When you read these you’ll all agree they are obvious. We know the definition of all these words. All the words have been said before. We’ve pretty much “been there done that.” Well maybe. Maybe there some subtleties here. But for the moment, let’s pretend that we know these words, but our problem is how to put them to work. How to make these words and the phrases they construct – ACTIONABLE. Actionable is a good word in project management. Because if it’s not actionable it’s not that useful. So let’s get started on the first step toward ACTIONABLE OUTCOMES FOR THE PROJECT.
- In the Live Stock business, there is a problem is keeping track of your live stock. How many cows do you have and where are they now? In the Olde days, you had to get on a horse an go out and count them. In the recent days you got on your 4-wheel horse ‒ an ATV ‒ and went out and counted them. Now there is an even better way ‒ send a machine to the pasture and count the cows without you ever leaving the house.