The PMBOK® Guide Distilled for the SPI Professional Ahoy Mate! The PMBOK® Guide Distilled for the SPI Professional Value: Many PMPs and SPI professionals. Both use different standards that are in many ways compatible. In the best interest of both professionals to understand the compatibility. DC SPIN Chapter Meeting October 2, 2002 Clark A. Sheakley, PMP Projenics, Inc. 703-754-6694 sheakley@hotmail.com
Questions to be Answered… How can I use the PMBOK® Guide to improve my software engineering processes? What is in the PMBOK® Guide that can support the CMMI – SW/SE practices? © 2002 Clark Sheakley
Contents Background Overview Comparison to CMM / CMMI Using the PMBOK® Guide Close © 2002 Clark Sheakley
History: One document could not contain the entire PM Body of Knowledge… hence the concept of a “Guide”. Sponsored by the Project Management Institute (www.pmi.org). 1983 and 1987 the PMBOK and Revised PMBOK were published. 1996 renamed the PMBOK® Guide and became an ANSI standard. © 2002 Clark Sheakley
About the PMBOK® Guide – 2000 Edition ANSI Standard 99-001-2000 1,700 comments from the PM community IEEE Standard Underlying reference in ISO Technical Report: ISO TR 16543 – Software Project Management Guide According to 12207 Available from www.pmi.org in hardbound, softbound, and CD ($40) The PMBOK® Guide is a subset of the PMBOK. The PMBOK is all knowledge on PM whereas the Guide is a summary and framework for the PM Body of Knowledge. The PMBOK works as a pointer to the other references that provide more detail on PM. © 2002 Clark Sheakley
The PM System The PMBOK(R) Guide The PMBOK Tool Set “Generally Accepted” Application Areas The PMBOK(R) Guide The PM System is comprised of processes and tools to support the management of a project. Process have three components – PM, Application Areas, and General Management. The tool is the repository in which a project team may manage its project. The summation of all elements makes the PM System in which the project is managed. The PMBOK is all knowledge on project management. The PMBOK® Guide is a subset of the PMBOK and so it is comprised of generally accepted knowledge. Generally Accepted means that the knowledge and practices described are applicable to most projects most of the time, and that there is widespread consensus about their value and usefulness. Generally accepted does not mean shall or should be applied to all projects. The PMBOK® Guide describes what is done most of time. As will be seen later, it’s contents provide a high-level reference with pointers to other material published in the Body of Knowledge. The PM and the PM team decides what is appropriate. The PMBOK can provide input to an organization’s defined processes (defined, meaning processes standardized at the organizational level). These defined processes are then tailored according to the requirements of the project. The application areas are the processes specific to the discipline and usually depend on the product delivered. The application area will dictate the project life cycle and the PM processes provides the overarching management within the project life cycle phases. For example, references to the need for developing a Safety Plan or developing a Test Plan will not be found in the PMBOK® Guide. Those are specific to the product being delivered. The PMBOK would consider the CMMI – Continuous Practice Categories of Process Management and Engineering Management as application areas. In summary, the PMBOK is generalized document of knowledge and processes that may be applied to all disciplines: construction, biomedical, software engineering, telecomm, and even SPI. General Management Tool Set © 2002 Clark Sheakley
PMBOK® Guide Misconceptions Not a Maturity Model It provides descriptive material with pointers A guide not a specification It is a standard Focuses on a single project There is no equivalency between the two standards. The PMBOK® Guide provides further detail to the practices. © 2002 Clark Sheakley
Terminology Project: Project Management: A temporary endeavor undertaken to create a unique product, service, or result. A definite beginning and end - not an ongoing operational process Never done before Progressive Elaboration: Because the product is unique, the characteristics of the product must be progressively elaborated. Characteristics are broadly defined at the beginning of a project and continuously refined throughout the project. Project Management: The application of knowledge, skills, tools, and techniques to project activities to meet the project requirements. © 2002 Clark Sheakley
Organization of PM Knowledge Chapters 1 & 2: Definitions & Context Chapter 3: PM Process Groups The Standard Chapters 4 – 12: The Project Management Knowledge Areas Project Integration Management Project Scope Management Project Cost Management Project Quality Management Project Human Resource Management Project Communications Management Project Risk Management Project Procurement Management Project Time Management © 2002 Clark Sheakley
Chapter 3 Project Processes Groups in a Phase Initiating Processes Planning Processes Process Groups Initiating processes: authorizing the project or phase. Planning processes: defining and refining objectives and selecting the best approach. Executing processes: Carrying out the plan. Controlling processes: Monitoring and measuring progress and taking corrective action to ensure project objectives are met. Closing processes: Formalizing acceptance of the project or phase. Controlling Processes Executing Processes Closing Processes © 2002 Clark Sheakley
Application of the PMBOK® Guide to the CMMI Process Management Process Areas Create Organizational Definition Make Org Process Assets Available OPD Process Area OPF OPP Practices OID © 2002 Clark Sheakley
Knowledge Area Definitions Chapter Number Project Integration Management – the processes required to ensure that the various elements of the project are properly coordinated. Project Scope Management – the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. Project Time Management – the processes required to ensure timely completion of the project Project Cost Management – the processes required to ensure that the project is completed within the approved budget. Project Quality Management – the processes required to ensure that the project will satisfy the needs for which it was undertaken. Project Human Resources Management – the processes required to make the most effective use of the people involved with the project © 2002 Clark Sheakley
Knowledge Area Definitions (cont.) Chapter Number Project communications Management – the processes required to ensure timely and appropriate generation, collection, dissemination, storage, and ultimate disposition of project information. Project Risk Management – the processes concerned with identifying, analyzing, and responding to project risk. Project Procurement Management – the processes required to acquire goods and services from outside the performing organization. © 2002 Clark Sheakley
Mapping Processes to Process Groups and Knowledge Areas Initiating Planning Executing Controlling Closing 4. Project Integration Management 4.1 Project Plan Development 4.2 Project Plan Execution 4.3 Integrated Change Control 5. Project Scope Management 5.1 Initiation 5.2 Scope Planning 5.3 Scope Definition 5.4 Scope Verification 5.5 Scope Change Control 6. Project Time Management 6.1 Activity Definition 6.2 Activity Sequencing 6.3 Activity Duration Estimating 6.4 Schedule Development 6.5 Schedule Control 7. Project Cost Management 7.1 Resource Planning 7.2 Cost Estimating 7.3 Cost Budgeting 7.4 Cost Control 8. Project Quality Management 8.1 Quality Planning 8.2 Quality Assurance 8.3 Quality Control 9. Project Human Resource Management 9.1 Organizational Planning 9.2 Staff Acquisition 9.3 Team Development 10. Project Communications Management 10.1 Communications Planning 10.2 Information Distribution 10.3 Performance Reporting 10.4 Administrative Closeout 11. Project Risk Management 11.1 Risk Mgt Planning 11.2 Risk Identification 11.3 Qualitative Risk Analysis 11.4 Quantitative Risk Analysis 11.5 Risk Response Planning 11.6 Risk Monitoring and Control 12. Project Procurement Management 12.1 Procurement Planning 12.2 Solicitation Planning 12.3 Solicitation 12.4 Source Selection 12.5 Contract Admin 12.6 Contract Closeout © 2002 Clark Sheakley
4.2 Project Plan Execution Planning Processes Executing Processes Initiating Processes Scope Time 6.2 Activity Sequencing Time 6.4 Schedule Development Integration Time 6.1 Activity Definition Core Scope 5.2 Scope Planning 4.2 Project Plan Execution 5.1 Initiation Time 6.3 Activity Duration Estimating Cost 7.3 Cost Budgeting Scope Procure 12.3 Solicitation Quality 8.2 Quality Assurance HR 9.3 Team Devel. 5.3 Scope Definition Cost 7.1 Resource Planning Core Processes Cost 7.2 Cost Estimating Integration Procure 12.4 Source Selection Comm. 10.2 Info. Distrib. 4.1 Project Plan Development Facilitating Risk 11.1 Risk Mgt Planning Procure 12.5 Contract Admin. Quality 8.1 Quality Planning HR 9.1 Org Planning HR 9.2 Staff Acquisition Procure 12.1 Procure Planning Procure 12.2 Solicit. Planning Facilitating Processes Comm. 10.1 Comm. Planning Risk 11.2 Risk ID Risk 11.3 Qual. Analysis Risk 11.4 Quant. Analysis Risk 11.5 Resp. Planning Comm. 10.3 Perf. Reporting Integration Core 4.3 Int. Chg Control Scope Scope Time 6.5 Schedule Control Procurement 12.6 Contract Closeout Comm. 10.4 Admin. Closeout Core Closing Process 5.4 Scope Verification 5.5 Scope Chg Control Controlling Processes Facilitating Cost Quality Risk 7.4 Cost Control 8.3 Quality Control 11.6 Risk Monitoring & Control © 2002 Clark Sheakley
Project Scope Management 5.1 Initiation Authorizing the start of a project or for it to continue to the next phase. Inputs Product description Strategic plan Project selection criteria Historical information Tool & Techniques Project selection methods Expert judgment Outputs Project charter Project manager Constraints Assumptions Planning Project selection methods: Benefit measurement methods and Decision Models Project charter: Formally authorizes the project to proceed. Contains the business need and product description. © 2002 Clark Sheakley
Project Scope Management 5.2 Scope Planning Progressive elaboration and documenting project work.. Inputs Product description Project charter Constraints Assumptions Tool & Techniques Product Analysis Benefit/cost analysis Alternatives identification Expert judgment Outputs Scope statement Supporting detail Scope management plan Planning Scope statement: Used for making future project decisions. Includes justification, product summary, and objectives. Scope management plan: Describes how scope will be identified, classified, and managed, and how scope changes will be integrated into the project. © 2002 Clark Sheakley
Project Scope Management 5.3 Scope Definition Subdividing the major project deliverables into smaller components. Define a baseline for performance measurement and control. Inputs Scope statement Constraints Assumptions Other planning outputs Historical information Tool & Techniques Work breakdown structure templates Decomposition Outputs Work breakdown structure Scope statement updates Planning Decomposition: Subdividing project deliverables, deciding if adequate cost and schedule detail can be determined at that level, and identifying constituent components for performance measurement (progress reporting), and verifying correctness of components. WBS: A deliverable-oriented grouping of project components that defines the total scope of the project. © 2002 Clark Sheakley
Project Scope Management 5.4 Scope Verification Obtaining formal acceptance of project scope by stakeholders. Inputs Work results Product documentation WBS Scope statement Project plan Tool & Techniques Inspection Outputs Formal acceptance Controlling Inspection: Measuring, examining, and testing project deliverables against requirements. Formal acceptance: Documentation that the stakeholder has accepted the product to close the project or move on to the next phase. © 2002 Clark Sheakley
Project Scope Management 5.5 Scope Change Control Influencing change, determining a change, and managing the actual change. Inputs WBS Performance reports Change requests Scope management plan Tool & Techniques Scope change control Performance measurement Additional planning Outputs Scope changes Corrective action Lessons learned Adjusted baseline Controlling Performance reports: Shows which deliverables have been completed and provides some historical data to assess the impact of a change. Scope change control: Defines procedures for changing project scope. Should be integrated with Integrated Change Control, e.g., schedule, risk, cost, and product scope. Performance measurement: Helps assess the magnitude of variance relative to the baseline and if corrective actions are necessary. © 2002 Clark Sheakley
Project Integration Management 4.1 Project Plan Development Integrating and coordinating all project plans to create a consistent, coherent document. Inputs Other planning outputs Historical information Organizational policies Constraints Assumptions Tool & Techniques Project planning method Stakeholder skills PM info system Earned value mgt Outputs Project plan Supporting detail Planning Other planning outputs: All the outputs from the planning process in the Knowledge Areas. Project planning method: A structured approach for integrating all project plans into a consistent, coherent document for project execution and project control. Earned Value Management: Integrates project scope, schedule, and resources to report project performance . © 2002 Clark Sheakley
Project Integration Management 4.2 Project Plan Execution Carrying out the activities of defined in the project plan. Inputs Project plan Supporting detail Organizational policies Preventive action Corrective action Tool & Techniques General mgt skills Product skills Work authorization sys Status review meetings PM IS Organizational procedures Outputs Work results Change requests Executing Corrective action: Anything done to bring future project performance in line with the baseline. Output from the various Control Processes.. Work authorization system: A formal procedure that ensures work is done at the right time and in the proper sequence. . © 2002 Clark Sheakley
Project Integration Management 4.3 Integrated Change Control Coordinating changes across the project. Inputs Project plan Performance reports Change requests Tool & Techniques Change control syst Configuration management Performance measurement Additional planning PM IS Outputs Project plan updates Corrective action Lessons learned Controlling Project Plan: Provides the baseline in which are controlled. Change control system: Defines how project performance will be monitored and evaluated. Includes the steps on how project documents are changed. Configuration Management: Identifies characteristics to track, control changes, record and report changes, and audit the items and CM system to verify conformance to project requirements. © 2002 Clark Sheakley
Organizational Process Definition: How can I use the PMBOK® Guide to improve my software engineering processes? Establish Lifecycle Models Organizational Process Definition: Organizational Process Assets are created Establish Standard Processes Establish Tailoring Guidelines © 2002 Clark Sheakley
Organizational Process Focus How can I use the PMBOK® Guide to improve my software engineering processes? Process Improvement Opportunities are Identified Organizational Process Focus Establish Org Process Needs Assess Organization’s Processes Identify Organization’s Process Improvements Process improvements are planned and deployed Incorporate Process-Related Experiences Deploy Process Assets Establish Process Action Plans Implement Process Action Plans © 2002 Clark Sheakley
What is in the PMBOK® Guide that can support the CMMI – SW/SE practices? Project Planning SG 1: Estimates of project planning parameters are established and maintained CMMI Specific Practice PMBOK® Guide Processes SP 1.1-1: Establish WBS to estimate scope 5.1 Initiation; 5.2 Scope Planning; 5.3 Scope Definition SP 1.4-1: Estimate the project effort and cost based on estimation rationale 6.1 Activity Definition; 6.3 Activity Duration Estimating; 7.1 Resource Planning; 7.2 Cost Estimating © 2002 Clark Sheakley
What is in the PMBOK® Guide that can support the CMMI – SW/SE practices? Project Planning SG 2: A project plan is established CMMI Specific Practice PMBOK® Guide Processes SP 2.1-1: Establish and maintain the budget & schedule 11.1 Risk Management Planning; 7.3 Cost Budgeting; 6.4 Schedule Development SP 2.2-1: Identify and analyze risks 11.1 Risk Management Planning; 11.2 Risk Identification; 11.3 Qualitative Risk Analysis; 11.4 Quantitative Risk Analysis; 11.5 Risk Response Planning SP 2.3-1: Plan for the management of project data None; 4.2 Project Plan Execution; 4.3 Integrated Change Control SP 2.4-1: Plan for resources 7.1 Resource Planning SP 2.5-1: Plan for knowledge and skills needed to perform the project 7.1 Resource Planning; 9.1 Organizational Planning SP 2.6-1: Plan the involvement of the stakeholders 10.1 Communications Planning SP 2.7-1: Establish and maintain project plans 4.1 Project Plan Development © 2002 Clark Sheakley
What is in the PMBOK® Guide that can support the CMMI – SW/SE practices? Project Planning SG 3: Commitments to the project plan are established and maintained CMMI Specific Practice PMBOK® Guide Processes SP 3.3-1: Obtain commitment from stakeholders 10.1 Communications Planning; 4.1 Project Plan Development © 2002 Clark Sheakley
What is in the PMBOK® Guide that can support the CMMI – SW/SE practices? GC 2: Generic Practices GP 2.3: Provide adequate resources… GP 2.4: Assign responsibility and authority for performing the process… GP 2.6: Place designated work products of the process under appropriate levels of configuration management GP 2.7: Identify and involve relevant stakeholders… GP 2.8: Monitor and control the process… GP 2.9: Objectively evaluate adherence of the process… to the requirements… and address noncompliance. GP 2.10: Review the activities, status, and results of the process with higher-level management… © 2002 Clark Sheakley
PMBOK® Guide and CMMI Comparison Chart Trait PMBOK® Guide CMMI - SE/SW Extent Single project level Project & organizational levels Structure Body of Knowledge: Framework of integrated processes Maturity Model: Required, Expected, Informative Standard Yes, Guide Yes, Specification Orientation Project Product & Project Intent Process definitions Preventative Definitions Discipline All (const, pyramids, DoD, cars, etc.) SW/SE © 2002 Clark Sheakley
Summary Provides a system of processes linked together by inputs, techniques, and outputs. DOES NOT REPLACE THE CMMI. It is a matter of buoyancy not equivalency. Is a Body of Knowledge and therefore requires tailoring to the business needs of the organization © 2002 Clark Sheakley
??? © 2002 Clark Sheakley