6th Edition PMBOK® Guide–Project Management Process Groups


I am starting a project of going through the 6th Edition of the PMBOK® Guide and blogging about its contents.    The 6th Edition was released on September 22nd by the Project Management Institute, and the first chapter is a general introduction to the framework in which project management exists, starting with section 1.2 Foundation Elements (section 1.1 describes the purpose of the Guide).

The section I am going over in this blog post is section 1.2.4 Components of the Guide, although it should be titled Components of a Project (in my humble opinion).    The reason is that the preceding section, 1.2.3 Relationship of Project, Program, Portfolio, and Operations Management shows the external relationship between a project and all of these other elements within an organization.   The current section 1.2.4 now shifts from an external view of a project to an internal one, and shows what its components are.  Here they are in decreasing order of magnitude:   project life cycle, project phase, process group/knowledge area, process.   In the last posts, I discussed the project life cycle and project phases.   In this post, I will discuss project management process groups.

The 49 processes of project management can be classified according to which of the five process groups they are in and which of the ten knowledge areas they cover.    The five process groups are:

  1. Initiating–defines the new project and obtains authorization to start it
  2. Planning–establishes the scope of the project, refines the objectives, and defines the course of action required to attain those objectives
  3. Executing–completes the work defined in the project management plan to satisfy the project requirements
  4. Monitoring and Controlling–tracks, reviews, and regulates the progress and performance of the project; identifies any areas in which changes to the plan and required and initiates those changes
  5. Closing–Formally completes or closes the project.

Although they are listed sequentially, the processes will usually start with Initiating and Planning, but then cycle forth between Executing and Monitoring and Controlling, perhaps even looping back to Planning (if there are changes made to the plan), and then when the final deliverable is completed and accepted by the customer or sponsor, the last and final process group Closing will take place.

The middle three process groups can be considered similar to the Plan-Do-Check-Act (PDCA) cycle made popular by Dr. Edwards Deming for control and continuous improvement of products and processes.    A project, being defined as a temporary endeavor, puts two bookends on this cycle and adds an Initiating and Closing process group on either side.

Although there are five process groups, the 49 processes are not distributed evenly among them.    Here’s the number of processes in each process group:

  • Initiating (2)
  • Planning (24)
  • Executing (10)
  • Monitoring and Controlling (12)
  • Closing (1)

As you can see, the Planning process groups gets the lion’s share of the processes, with 24 processes, the Monitoring and Controlling process group getting 12 processes, and the Executing process group getting 10 processes.  The two “bookends”, the Initiating and Closing process groups, have only 2 and 1 process each, respectively.

The breakdown of the number of questions on the PMP exam by process group is as follows (based on the PMP exam outline published by PMI in 2015 based on the 5th Edition PMBOK® Guide):

  • Initiating (13%)
  • Planning (24%)
  • Executing (31%)
  • Monitoring and Controlling (25%)
  • Closing (7%)

If the above proportions of questions on the PMP exam based on the 5th Edition PMBOK® Guide are indicative of the breakdown on the 6th Edition published in September 2017, then one should pay close attention to the Initiating and Closing group processes, because they will be represented by a disproportionately larger percentage of questions on the exam.

The next post covers the ten knowledge areas that the 49 processes are divided into.   In the 5th Edition, a new knowledge area was added (Stakeholder Management) that was an outgrowth of another knowledge area (Communications Management).   The good news for the PMP test taker is that in the 6th Edition, there are no new knowledge areas to learn!

6th Edition PMBOK® Guide–Project Phases


I am starting a project of going through the 6th Edition of the PMBOK® Guide and blogging about its contents.    The 6th Edition was released on September 22nd by the Project Management Institute, and the first chapter is a general introduction to the framework in which project management exists, starting with section 1.2 Foundation Elements (section 1.1 describes the purpose of the Guide).

The section I am going over in this blog post is section 1.2.4 Components of the Guide, although it should be titled Components of a Project (in my humble opinion).    The reason is that the preceding section, 1.2.3 Relationship of Project, Program, Portfolio, and Operations Management shows the external relationship between a project and all of these other elements within an organization.   The current section 1.2.4 now shifts from an external view of a project to an internal one, and shows what its components are.  Here they are in decreasing order of magnitude:   project life cycle, project phase, process group/knowledge area, process.   In the last post, I discussed the various types of project life cycle, from predictive, to iterative/incremental, to adaptive (agile).   In this post, I will discuss the next largest component, the project phase.

The formal definition of a project phase according to PMI is “a collection of logically related project activities.”   Projects are broken up into phases usually when they are very large and the amount of resources that will be expended on the project are very substantial.   A phase is like a mini-project, in that each phase goes through the five process groups of Initiating, Planning, Executing, Monitoring & Controlling, and Closing. In fact the very last of the 49 project management processes is called 4.7 Close Project or Phase for that very reason.

The reason for splitting up a project into phases is that at the end of each phase, there is a phase gate where a decision is made whether or not to go on to the next phase.   In this way, it at any phase gate, the organization decides the project is not viable, then the organization can decide to pull the plug then and there and not go on to the next phase.  This reduces the cost risk to the organization by limiting the expenditures on projects that will end up adding value for the organization in the way that they were originally envisioned.

Let’s use an example to clarify what the phases are.    I used to work for a Japanese automobile manufacturer, and before producing a new model vehicle, they would first put out a concept car.   So concept development would go first.   Then the requirements would be gathered.   Now these would include customer requirements, based in part on market studies about what kinds of cars various types of people were interested in driving.   But there would also be regulatory requirements, such as new safety regulations coming out of the NHTSA or environmental regulations coming out of the EPA.    There would be a solution development which would combine these requirements and adjust the original concept development into the design and production of a prototype, which would then be builttested, and a transition made to those in manufacturing who would then take over mass production of the new vehicle.

Each of the groups of activities listed above could be made into a separate phase, with a phase gate at the end of each one where the organization would make a decision on whether or not to the go to the next phase.    There might be some event which changed the market and no longer made the concept car viable.   In which case, the organization might cancel further development.   Or a new type of regulatory requirement might make a certain car no longer feasible and require a change in the design.   Whatever the reason, the phase gate (sometimes referred to as a phase review or stage gate) is there to ensure that the proposed product, service, or result that will come out of the project is still in alignment with the business need and strategic objective of the organization.

The next post will cover the five process groups and ten knowledge areas that the processes of a project can be divided into.

6th Edition PMBOK® Guide–Project Life Cycles


I am starting a project of going through the 6th Edition of the PMBOK® Guide and blogging about its contents.    The 6th Edition was released on September 22nd by the Project Management Institute, and the first chapter is a general introduction to the framework in which project management exists, starting with section 1.2 Foundation Elements (section 1.1 describes the purpose of the Guide).

The section I am going over in this blog post is section 1.2.4 Components of the Guide, although it should be titled Components of a Project (in my humble opinion).    The reason is that the preceding section, 1.2.3 Relationship of Project, Program, Portfolio, and Operations Management shows the external relationship between a project and all of these other elements within an organization.   The current section 1.2.4 now shifts from an external view of a project to an internal one, and shows what its components are.  Here they are in decreasing order of magnitude:   project life cycle, project phase, process group/knowledge area, process.   In this first post, I will discuss the largest component, the project life cycle.

The project life cycle is a series of phases that a project passes through from its start to its completion.    There are several types of project life cycles, from predictive, to iterative/incremental, and adaptive (agile).    They vary in terms of how the project constraints of scope, time and cost evolve during the life cycle, from the most rigid (predictive) to the most fluid (agile).

Predictive–project scope, time and cost are determined in the early phases of the life cycle.   This is also known as a “waterfall” life cycle.

Iterative–the project scope is determined in the early phases of the life cycle, but the time and cost estimates are modified as the team’s understanding of the project increases.

Incremental–the project scope is produced through a series of iterations that successively add functionality of the product.    The “spiral” model of project management is an example of this type of project life cycle.

NOTE:    Anthony Mersino, in his VitalityChicago blog, says that although PMI describes these last two project life cycles, iterative and incremental as being separate, they are often done together, so that the scope as well as the time/cost estimates are modified in a series of iterations.

Adaptive–here it is often the time and cost constraints which are determined in the early phases of the life cycle; it is the scope that continuously evolves based on interactions with the customer.

Here is a comparison of how requirements, deliverables, change, stakeholders, and risk/cost are handled in the various types of project life cycles.    (Taken from Figure X3-1. The Continuum of Project Life Cycles on page 666 of the Guide.

  Predictive Iterative

Incremental

 

Agile
Requirements Defined up-front Elaborated periodically  

Elaborated frequently

Deliverables Delivered at end of project Delivered periodically Delivered frequently
Change Constrained as much as possible Incorporated at periodic intervals Incorporated in real-time delivery
Stakeholders Involved at specific milestones Involved regularly Involved continuously
Risk/cost Controlled by detailed planning Controlled by progressively elaborating Controlled as requirements emerge

There is an additional type called hybrid which combines the predictive and adaptive life cycles.   The elements that are well known or have fixed requirements follow a predictive life cycle, and those that are still evolving follow an adaptive life cycle.

Although this is often hyped as the trend in which project management is going, there are many caveats to using the hybrid approach, some of which are touched upon by Anthony Mersino in his blog about agile project management called VitalityChicago.   So mix and match project life cycles at your own risk!

6th Edition PMBOK® Guide–Components of a Project


I am starting a project of going through the 6th Edition of the PMBOK® Guide and blogging about its contents.    The 6th Edition was released on September 22nd by the Project Management Institute, and the first chapter is a general introduction to the framework in which project management exists, starting with section 1.2 Foundation Elements (section 1.1 describes the purpose of the Guide).

The section I am going over in this blog post is section 1.2.4 Components of the Guide, although it should be titled Components of a Project (in my humble opinion).    The reason is that the preceding section, 1.2.3 Relationship of Project, Program, Portfolio, and Operations Management shows the external relationship between a project and all of these other elements within an organization.   The current section 1.2.4 now shifts from an external view of a project to an internal one, and shows what its components are.  Here they are in decreasing order of magnitude:

  • Project life cycle–a large project can be broken down into various phases; the entire series of phases a project passes through from its start to its completion is referred to as the project life cycle.
  • Project phase–each individual project phase is like a mini-project that goes from the first process group (Initating Processes) to the last process group (Closing Processes).  The phases are completed in sequence, and the connection between the individual phases in the project life cycle is called a phase gate, where the decision is made whether or not to go on to the next phase.
  • Project management process group–the forty-nine project management processes are grouped logically into five process groups:   Initating (2 processes), Planning (24 processes), Executing (10 processes), Monitoring & Controlling (12 processes), and Closing (1 process).   Although a project will pass sequentially through its various phases, the passage through process groups is more complicated.
  • Project management knowledge area–the processes within each process group are identified with one of the ten knowledge areas:   Integration, Scope, Schedule, Cost, Quality, Resources, Communications, Risk, Procurement, and Stakeholder.
  • Project management process–each of the 49 project management processes, which belong to one of five process groups and ten knowledge areas, consist of the following components:
    • Inputs–items which can be outputs from other processes
    • Tools and techniques–tools are items that are used with techniques to take inputs and process them into outputs
    • Outputs–deliverables to the project or items which can be inputs to subsequent processes

In order to get a visual picture of how these various components fit together, take a look at Figure 1.5 Interrelationship of the PMBOK® Guide Key Components on page 18 of the Guide.

The next few posts will discuss each of these levels of components of a project, starting with the largest level, that of the project life cycle.   There are various types of project life cycle, and these will determine if the project is being handled in a traditional or agile framework.   This is where a lot of  change between the 5th Edition and the 6th Edition, so it will be a crucial post to pay attention to!

6th Edition PMBOK® Guide–Organizational Project Management


I am starting a project of going through the 6th Edition of the PMBOK® Guide and blogging about its contents.    The 6th Edition was released on September 22nd by the Project Management Institute, and the first chapter is a general introduction to the framework in which project management exists, starting with section 1.2 Foundation Elements (section 1.1 describes the purpose of the Guide).

The section I am going over in this blog post is section 1.2.3.6 Organizational Project Management (OPM) and Strategies.    This can be considered a synthesis of sorts of the previous sections that cover

  • the relationship between projects, programs, and portfoliios
  • the relationship between projects and operations

Projects, programs, and portfolios differ in terms of depth of scope, that is, the amount of products, services, and results they create; projects and operations differ in terms of depth of time, with projects being temporary endeavors to create unique products, services and results and operations being the ongoing production of the same.

However, what ties ALL of these together is Operational Project Management or OPM, which is the organizational framework which integrates them in order to achieve overall strategic objectives.    See p. 17 of the Guide, Figure 1-4, for a diagram of this organizational framework.

How are all of these tied together in OPM?

  • Strategy–these are the organizational goals and objectives which inform the investments a company makes (e.g., increase in market share, decrease in operating expenses, or success of a new product)
  • Portfolio–selects the right programs or projects to achieve these organizational goals and objectives, prioritizes them, and then provides the needed resources to achieve them
  • Programs and projects–focuses on the achievement of the organizational goals and objectives
  • Operations–uses the results of programs and projects to realize business value or benefit, which is then utilized to further the organization’s business strategy.

For any specific project, the relationship between a project and the strategic objectives of an organization is described in the project business case, and the relationship between a project and the ongoing business value or benefit it provides to a company’s operations is described in the project benefits management plan.    (These are described in sections 1.2.6.1 and 1.2.6.2 respectively, and will be covered in later posts.)

If you want to succeed on your project, it is important that you understand the strategic objectives that went into creating your project in the first place.    If conditions change such that those objectives are no longer served by your project, or if those business objectives themselves are changed by your company, then your project may end up being cancelled by the sponsor.

But it is also important that you understand the strategic objectives behind your project so that you can inspire your project team.    Once they understand that their daily efforts, however meager they may seem in their eyes, are tied to a much larger picture that involves the company going from merely surviving to actually thriving, they will end up doing those daily tasks with a lot more purpose and enthusiasm!

6th Edition PMBOK® Guide and the new CAPM/PMP exam


I am starting a project of going through the 6th Edition of the PMBOK® Guide and blogging its contents. The 6th Edition was released on September 22nd by the Project Management Institute, and I was wondering when PMI would announce the date for the CAPM and PMP exams.

I just got off the phone with someone from my local PMI chapter here in Chicagoland and he says it will be out at the end of Q1 2018, i.e. the end of March.   I’ll update this post with any new information I get!

6th Edition PMBOK® Guide—Projects and Operations


I am starting a project of going through the 6th Edition of the PMBOK® Guide and blogging about its contents.    The 6th Edition was released on September 22nd by the Project Management Institute, and the first chapter is a general introduction to the framework in which project management exists, starting with section 1.2 Foundation Elements (section 1.1 describes the purpose of the Guide).

The section I am going over in this blog post is section 1.2.3 The Relationship of Project, Program, Portfolio and Operations Management.    In the last post, I discussed the relationships of projects to programs, which include them as a component, and portfolios, which include both projects and programs as components.   Let’s now discuss the relationship of projects to operations which is covered in sub-sections 1.2.3.4 Operations Management and 1.2.3.5 Operations and Project Management.

 

Remember the definition of a project that was given at the beginning of the Guide?

A project is a temporary endeavor undertaken to create a unique product, service, or result.

Operations, on the other hand are the ongoing production of goods and/or services.   So you can see that behind the definition of a project is the distinction between it and the ongoing nature of operations of an organization.

However, if you look more closely at how organizations actually create and maintain business value, this distinction isn’t as clear-cut as it would first seem to be.    Here’s why:  many projects have as their objective the creation of a new product or a system for delivering a new service.    However, many projects have as their objection the upgrade of an existing product or service or the improvement of business operations.

In the 5th Edition of the PMBOK® Guide, although the definition of a project is the same as above, in the explanation below the definition it was made clear that a project could indeed include improvements to existing products as well as the creation of new ones. This means Six Sigma projects, which are designed to improve the processes of existing operations in order to reduce defects in their end results, are to be considered as included in the definition of a project.

This is made even more clear in the 6th Edition PMBOK® Guide with an even fuller explanation of projects which exist to improve existing operations.   But what if those improvements to existing operations are made on a continuous basis, which is the basis for kaizen?    If this is the case, then the distinction between projects and operations is a little fuzzier, because projects are then continuously being launched to improve those operations.    Can they be considered “temporary” endeavors any more if they are constantly being done?    Can they be considered producing a “unique” product, service, or result if they are done to simply create a new, improved version of the same?

Because the distinction between projects and operations is not as clear-cut in some organizations as in others, it is even more important that a project manager consider operations managers as stakeholders in the projects they are doing, especially if those managers are heading departments which will be the direct recipient of a new business service or result, or if they are affected in any way by it.    Also resources from those departments will often be used in carrying out the project, for the very reason that they will be eventually impacted by it.

The next section 1.2.3.6 ties together organizational project management, which is the integration of projects, programs and portfolios.

6th Edition PMBOK® Guide—Projects, Programs, and Portfolios


I am starting a project of going through the 6th Edition of the PMBOK® Guide and blogging about its contents.    The 6th Edition was released on September 22nd by the Project Management Institute, and the first chapter is a general introduction to the framework in which project management exists, starting with section 1.2 Foundation Elements (section 1.1 describes the purpose of the Guide).

The section I am going over in this blog post is section 1.2.3 The Relationship of Project, Program, Portfolio and Operations Management.    Let’s take the relationship of projects to programs and portfolios first.   Then in the next post I’ll discuss the relationship of programs and portfolios.

Programs

Remember the definition of a project is “a temporary endeavor undertaken to create a unique product, service or result.”   Projects may be grouped together into a program which is “a group of related projects … managed in a coordinated manner.”    The reason for this is so that the projects can achieve a common objective (whether it is a product, service, or result) and managing them together as a project focuses on doing them in an efficient manner.   This can be done not only by planning, executing, and controlling the various projects in a program as a group, but also by sharing resources between those projects.

Portfolios

Program management focuses on doing programs and the projects they contain in the right way; portfolio management focuses on doing the right programs and projects in order to achieve strategic objectives of the organization.    This is done by selecting the right programs, prioritizing the work, and then providing the needed resources.

There is a lot more detail about the internal structure of a portfolio and a program contained on page 12 of the Guide, and a detailed Table 1.2 on page 13 that compares the various characteristics of project, program, and portfolio management.    However, the above overview contains enough information for the project manager to understand why he or she should pay attention to the program and/or portfolio of which their project is a part.

The next post will discuss the relationship between projects and operational management.

 

 

The Agile Practice Guide


I received the 6th Edition PMBOK® Guide and am starting a project of going through it and blogging about its contents.   But before I go any further, I wanted to add a blog post about the Agile Practice Guide that comes with the PMBOK® Guide.    I was excited to see this as a harbinger of two trends, one which is the recognition of PMI of the importance of agile methodology as it spreads beyond the world of IT, and the second of which is the growing collaboration of PMI with other professional associations that handle change management, business analysis, and in the case of the Agile Alliance, agile methodologies.

This was why I was excited to get the post from Anthony Mersino’s VitalityChicago blog which reviews the agile practice guide.    Anthony Mersino is an expert in the field of agile methodologies.   I know him from the Chicagoland chapter of the Project Management Institute.   Anthony coaches and trains Agile Leaders to help them understand Agile and Scrum and how to create an environment where people come first, productivity is high, and teamwork is effective and enjoyable.   Anthony has  authored numerous articles and two books:  Agile Project Management for Teams and Emotional Intelligence for Project Managers.    For those who have been following my blog, I wanted to relate some of his thoughts on the guide, but I encourage you to read the entire post at the following site:

http://vitalitychicago.com/blog/agile-practice-guide?utm_source=newsletter&utm_medium=email&utm_campaign=2017_11_01_blog_agile_practice_guide&utm_content=Blog%20-%20Agile%20Practice%20Guide

First, what does Anthony like about the Guide?    It is broad in its coverage of agile methodologies:   it includes not only Scrum, but XP, Kanban, Lean and other frameworks.   It is deep in its exploration of agile principles, the agile mindset, and the topic of servant leadership.   He also mentions the general point I made above, which is that it is in general a good development that PMI has partnered with the Agile Alliance to produce this document and make it available to all project managers.   Also, the fact that there is a single guide means that those who are studying for PMI’s agile certification, the PMI-ACP® (Agile Certified Practitioner), can use one book rather than the current twelve that they currently have to study from!

Now let’s move onto Anthony Mersino’s warnings about using the Agile Practice Guide.  This advice is invaluable to those project managers like me who are relatively new to agile and want to learn about its contents but also want to absorb the mindset of those who actually work with agile on a daily basis.

5 Warnings about using The Agile Practice Guide

1. Focus on products, not projects

Anthony Mersino says that organizations that use agile are often product-centric, and not necessarily project-centric.    Projects are useful, but only if they help build and maintain valuable solutions and products.    This is why it is important to look at the new business document which PMI has added called the project benefits management plan.    The project business case demonstrates the business value or benefit that the project is supposed to create.   But it is also important that the business value which is created is then maintained so that the efforts of the project are not wasted, and that is what the project benefits management plan does.   Project managers should always be connecting to stakeholders who will be the beneficiaries of their project so that the impact of a project lasts long after the project has ended.

2.  Be careful with “hybrid” approaches

This was a surprising warning, given that I’ve read so many predictions about how more and more projects will be attempting a hybrid approach using both agile and traditional project management methodologies.   Anthony Mersino says that traditional project managers come to agile sometimes with the idea that they can simply utilize an agile “template” and be able to interact with agile teams.    This is like someone who wants to lose weight, and asks the doctor to give him or her a pill to help lose weight, rather than doing what is guaranteed to work (i.e., exercise), but which will require a lot more effort.

However, one thing is certain, even if a project manager engages with agile teams, he or she may still have to TRANSLATE for upper management who may NOT be conversant with agile methods.    What I mean here is that a project management should reassure management with some of the information they are used to getting (milestone charts, tools which show current status and predict future performance) from more traditional methodologies, but in a format that may be at first unfamiliar to them (i.e., based on requirements rather than earned value measurement).   This gets me to Anthony’s next point.

3.   De-emphasize Earned Value Management

One of the concepts from traditional project management that doesn’t translate well into agile projects is the concept of earned value management.   Although he doesn’t go into details of why this is so, I suspect it is because earned value management matured in an application space devoted in large part to engineering or construction projects, where such precise measurements are possible and have meaning.    In the more protean world of IT projects, such precision is not only impossible, but more importantly, trying to impose it on such projects may be meaningless at best and misleading at worst.    Agile, which has been maturing in an application space devoted in large part to IT, is just not a good fit for this type of performance metric.   These are my words, not Anthony’s, but this is my guess at the reasoning behind his comment.

4.  Don’t be mean to Lean

Let me quote Anthony on this one:   “This is a minor point, but, there is a diagram in this book that shows Agile as being a subset of Lean, with Scrum as a subset of Agile – I always thought of Agile as as the child or offspring of Lean, not necessarily a subset.”  This is important because the person who is learning about Agile and Lean at the same time should have a clearer picture of their relationship so that they are not confused by differing terminology and can instead focus on the commonality of the mindset behind these approaches.

5.   Speaking of Lean … this Guide sure isn’t!

Anthony rants (his words) about the size of the 6th Edition PMBOK® Guide.   Actually the Guide itself comprises the first 536 pages; the rest of the book (a total of 754 pages) is the actual ANSI standard for project management which is a reference for the Guide.   The Agile Practice Guide is 165 pages, which he compares unfavorably to the Guide put out by the Scrum Alliance which contains only 17 pages!

He does have a point; if I go into a fitness center to meet my potential trainer and see that he is overweight, that doesn’t give me a lot of confidence that he will make me lean!

These are points to take into consideration, but with those caveats, I recommend all project managers to read the Agile Practice Guide, but also to read the blogs of experts in the field like Anthony Mersino’s VitalityChicago blog to get how agile it actually used by organizations!