Knowledge Area and Process Changes in the PMBOK 5th Edition

The 5th edition of the PMBOK (Project Management Body of Knowledge) was released this month by the PMI and there are a few changes worth noting.  The biggest change is that there is a new knowledge area called Stakeholder Management.  This knowledge area replaces and expands on two processes from the 4th editions Communications Management knowledge area, Identify Stakeholders and Manage Stakeholder Expectations.  It makes a lot of sense to me that Stakeholder Management would be its own knowledge area.  Stakeholder management is an important and complex area in Project Management and it is frequently discussed in project management circles.  I’m excited to see a focus on this area of knowledge and I look forward to diving into the material in the 5th edition PMBOK to learn the new standards.

Some other changes include the addition to the Planning process group of the Plan Scope, Schedule, and Cost Management processes to the Scope, Time and Cost knowledge areas.  There are also a few name changes to existing processes that improves naming consistency.

Here is are the knowledge areas and processes groups in a table below with the additions highlighted in yellow and the name changes in blue:

PMBOK 5e Knowledge & process table

There are other differences between the 4th and 5th editions but I will not go into them here.  As I continue to explore the new guide I will post what I learn here.  I’d love to hear from you.  What differences have you noted between the two editions and what impact if any do you think they will have?


Project Risk Management

On any project there are risks.  In many organizations project risk planning is completely overlooked.  Project risk is defined by the PMI as “an uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.”  Note that risk is not just about negative event planning, but is also about planning for positive risks that may come up as opportunities.

A risk planning process should have three key stages:

  1. Identify the risks 
  2. Analyze the risks
  3. Develop a response plan for the top risks

The process of identifying risk is really about getting everyone on the project together and getting their ideas on what could go right or wrong on the project.  This can be done using common brainstorming methods or more advanced methods such as the Delphi technique.  It is important during this process to try and be open to any suggestions that may be made, no matter how ridiculous they may seem at the moment.  Once a list of risks has been created from this process it is important to try to analyze them to come up with risk score by deciding on a probability and rating the impact, and then multiplying them.  Once each risk has a risk rating, you can focus on the top risks and come up with a response plan.  For negative risks you can try and transfer the risk to another party, you can take actions to try and avoid the risk altogether, or you can come up with contingency plans to deal with the risk if it occurs.  With positive risks you can put plans in place to try and make sure that it occurs.  This is known as risk exploitation.

This information can be organized in the form of a risk register.  The risk register usually have the following information:

  1. An identification number assigned to each risk event identified
  2. The risk rank that was determined from the risk score (probability #10 * impact #11)
  3. A short name to identify the risk
  4. A longer description of the risk
  5. A risk category such as technology or procurement
  6. The potential root cause of the risk
  7. The triggers, or indicators, for each risk (These are events that signal that a risk event is occurring or about to occur)
  8. The potential response to the risk
  9. The risk owner, or the person who will take responsibility monitoring and dealing with the risk
  10. The probability that the risk will occur
  11. The impact to the project if the risk occurs
  12. The status of the risk, i.e. did it happen or was it avoided?

Outside of the benefits avoiding risks altogether using this method, managers, customers and team members will have more confidence in the likelihood of a successful project outcome if they can see that a good risk management plan is in place.

This video by Andy Kaufman, PMP is a great, brief introduction to risk management on projects:

Getting Your Mind Around Your Project – The WBS

In a project of any size the sheer number of things that need to be done can be overwhelming.  One tool that a project manager can use to get their mind around their project is to create a work breakdown structure (WBS) and the corresponding WBS dictionary.  A WBS is a deliverable-oriented grouping of the work involved in a project that defines the total scope of the project.  The dictionary is a document that describes in detail the information needed for anyone to understand what each WBS item is.

There are many methods for going about the creation of a work breakdown structure including: the analogy approach, mind mapping, top down, bottom-up or just using the guidelines established by your company.

Regardless of the approach, the WBS should be created in conjunction with the team members who will be working with you to produce the project deliverables.  This may be as simple as a meeting where everyone gets a stack of post-its and contributes their knowledge of how the work gets done by writing down their tasks and sticking them to the white board.  This exercise also helps give the entire team an understanding the project purpose and scope while at the same time getting their commitment and buy-in for the work that needs to be done.

Check out this short video by Rita Mulcahy, PMP, as she addresses the concept of the WBS: