PMBOK th 5 Edition Changes Cesar Gonzalez PMP

PMBOK th 5 Edition Changes Cesar Gonzalez, PMP Professional Development Day October 11, 2013

BIO PMP, Senior Manager at Epicor Software Corporation, Project Manager for more than 10 years on Software solutions used across the globe, such as POS applications used by Nike, JC Penny, among others. Working as a trainer of PMI process to more than 100 students in several locations in US and Mexico. Cesar is currently establishing the Project Management Standards at Epicor Software Retail Solutions Development Group. He has a bachelor’s degree in computer science and is currently PMI-certified Project Management Professional (PMP), has a Master in Business Administration, a Six Sigma Green. Belt Certification as also a Professional Scrum Master.

Agenda • Introduction • Summary of Changes • Stakeholder Management • Other Changes • Conclusion • Q&A

Introduction • PMI has released a new edition of the PMBOK (5 th Ed) which will be the base for all certifications happening after July 31 2013. • The objective of this new version is to address some inconsistencies on the previous edition of the PMBOK, as also include several process that are required on Project Management.

This Looks familiar!

Summary of Changes • Addition of a new knowledge area called “Stakeholder Management” (going from 9 to 10 Knowledge areas) • The major change was to split communications from stakeholder management. With this we accomplish – More Focus on Stakeholders, since it is a key factor for Project Success – Communication focused on the organize & distribution of Project Information, rather than focusing on the outcome of the message • The new knowledge area is not actually new. What 5 th Edition has done is taken the Stakeholder Management part of Communications Management out and given it its own area. This is a logical move and one that highlights the importance of stakeholders in project management.

Summary of Changes • We now have 5 new processes, going from 42 to 47 Processes. • Added into Stakeholder Management: – Plan Stakeholder Management – Control Stakeholder Engagement • The following processes were added to clarify that every knowledge area requires a subsidiary plan, to review any preliminary decision required for maintaining & developing every knowledge area. – Plan Scope Management – Plan Schedule Management – Plan Cost Management

Stakeholder Management • The processes required to identify the people, groups or organizations that could impact or be impacted by the project (Identify Stakeholders) Moved from Communications to Stakeholder Management Knowledge Area • Analyze stakeholder expectations and their impact on the project, and to develop the appropriate management strategies (Plan Stakeholder Management)

Stakeholder Management • Focus on Continuous communication with Stakeholders to understand their needs and expectations & address issues as they occur (Manage Stakeholder Engagement) Changed from “Manage Stakeholder Expectations” to better identify it’s purpose, “Engagement”, and Moved from Communications to Stakeholder Management Knowledge Area. • Monitor Stakeholders relationships through the course of the project, and adjust strategies and plans for engaging stakeholders (Control Stakeholder Engagement)

Stakeholder Management

Stakeholder Management • Stakeholder satisfaction should be managed as a key project objective!!!

Other Changes The following Processes name were changed to be in better alignment with the naming convention from other knowledge areas: FROM RENAMED TO Plan Quality Management Develop Human Resource Plan Human Resource Management Plan Communications Management Plan Procurements Plan Procurement Management Perform Quality Control Quality Distribute Information Manage Communications Report Performance Control Communications Monitor and Control Risks Administer Procurements Control Procurements

Other Changes • “Direct and Manage Project Execution” changed to “Direct and Manage Project Work” – To better indicate that this Process goes beyond the execution phase of the project. • “Verify Scope” changed to “Validate Scope” – To clarify that this process are not only to accept deliverables, but also to validate them, and confirm it is providing the value expected from the project.

Conclusion

Conclusion • Formal Knowledge is necessary to deal with Stakeholders • A knowledge area now always start with the concerned subsidiary plan • Need to meet project expectations with stakeholders for a project to be successful • As you can see the process names are more standard between Knowledge Areas. • This version should be easier to understand as process names are better aligned.

Q&A