5th Edition PMBOK® Guide—Memorizing the Processes (Step 3: Risk Knowledge Area)


 

1.   Introduction

After memorizing the 5 process groups (step #1) and the 10 knowledge areas (step #2), the next step in mastering the memorization of the processes is figuring out where the 47 project management processes fit in the matrix made by those process groups and knowledge areas.    The best way to do that is to first memorize the names and order of the processes by knowledge area.    In previous posts, I have covered the knowledge areas of Integration (chapter 4 of the PMBOK® Guide), Scope (Chapter 5), Time (chapter 6), Cost (chapter 7), Quality (chapter 8), Human Resources (chapter 9), and Communications (chapter 10)   This post will cover the processes involved in the Risk Management knowledge area, which is covered by chapter 11 of the PMBOK® Guide.

Here are the 47 processes of project management; the chart indicates how many are in each knowledge area and process group.

Initiating Planning Executing Monitoring & Controlling Closing
Integration 6

1

1

1

2

1

Scope 6

4

2

Time 7

6

1

Cost 4

3

1

Quality 3

1

1

1

Human Resources 4

1

3

Communications 3

1

1

1

Risk 6

5

1

Procurements 4

1

1

1

1

Stakeholder 4      1

1

1

1

 47

2

24

8

11

2

2.  Risk Management knowledge area

Here’s the portion of the above matrix of 47 processes that lists the processes in the Risk Management knowledge area, which is covered in chapter 11 of the 5th Edition of the PMBOK® Guide.

Knowledge Area Total # of Processes Initiating Planning Executing Monitoring & Controlling Closing
Risk

6

5  1

You should notice two things about the distribution of processes among the process groups for the Risk Management knowledge area.    First of all, there are no processes in the Executing Process Group; this is true of the three so-called “triple constraint” knowledge areas of Scope, Time and Cost.    Secondly, this is like the Time management knowledge area in that there are a lot of planning processes.    The Risk knowledge area has 5 out of 6 processes in the Planning Process Group (as opposed to 6 out of 7 in the case of the Time knowledge area), and is therefore next to Time the most complicated of the knowledge areas in terms of planning.

Here’s a chart describing all of the 6 processes, 5 in the Planning Process Group and 1 in the Monitoring & Controlling Process Group.

Process Group Process Number Process Name Process Description
Planning 11.1 Plan Risk Management Defines how to conduct risk management activities on the project.
11.2 Identify Risks Determines what risks may impact the project and documents their characteristics.
11.3 Perform Qualitative Risk Analysis Prioritizes risks for further analysis or action by assessing their probability of occurrence and impact.
11.4 Perform Quantitative Risk Analysis Numerically analyzes the effect of risks on overall project objectives.
11.5 Plan Risk Responses Develops options and actions to enhance opportunities and reduce threats to project objectives.
Monitoring & Controlling 11.6 Control Risks Implements risk response plans, tracks identified risks, monitors residual risks, identifies new risks, and evaluates risk process effectiveness throughout the project.

11.1 Plan Risk Management

This planning process sets the framework for all of the other risk management processes by giving guidelines, providing templates for documents like the “risk register” that will be used throughout the various Risk Management processes, and listing definitions such as the various categories of risk that will be identified and analyzed.   The output of this process is the Risk Management Plan.

11.2. Identify Risks

Risks are identified by the various groups of stakeholders using various information-gathering techniques and are organized and put in a risk register.

11.3 Perform Qualitative Risk Analysis

The risks identified in 11.2 Identify Risks are rated according to two variables, their probability and their impact.    Whether a given risk has a) low or high probability and b) low or high impact determines what the general response to that risk should be.    Does the company want to avoid the risk, mitigate it, transfer it, or simply accept it if it occurs.    Or if it is a positive opportunity, on the other hand, does the company want to exploit the opportunity, enhance it, share it, or simply accept it if it occurs.    For those risks that are simply accepted, they are put on a watch list to be monitored during the 11.6 Control Risk process.

11.4 Perform Quantitative Risk Analysis

The risks are furthered analyzed; in this case the risk goes from having a qualitative impact and probability description (low vs. high) to having an expected monetary value, which gives a quantitative measure of the severity of the risk. 

11.5 Plan Risk Responses

The risks identified in 11.2, analyzed qualitatively in 11.3 and quantitatively in 11.4, are now planned for both in terms of resources and/or activities needed to reduce their impact on the project objectives.    The funding required for these risk responses will become part of the contingency reserve, which is added to the project cost estimate in the Cost Management Process.

All of the above are done during the planning process.   The following process is done during the Monitoring & Controlling Process.

11.6 Control Risks

This is where risks that were identified are tracked during the course of the project–do they end up occurring or not?    If not, the contingency reserves that were set aside in case they did occur may no longer be needed.    Of course, if the risks do occur, then if they were risks on the risk register, then the risk responses that were planned should be carried out using the resources set aside in the contingency reserves, which the project manager has control over.   What if the risks were not planned for?    Then a response still needs to be devised on the spot, and this is referred to as a workaround.    In this case, the funding will not come from the contingency reserves, but another source, the management reserves, which are under control of management, not the project manager.    This means that management must be informed if an “unplanned” risk occurs.

Corrective actions to take care of risks that have occurred are risk responses; there is another type of action, however, that is a preventive action, which helps prevent the risk from occurring in the first place.

Another type of control action is a periodic review of the risk register.    Are any new risks identified during the course of the project; if so, they should be added to the risk register.    Are there are any changes probabilities or impacts of any of the risks that are on the risk register?    This analysis also needs to be carried out for the risks on the so-called “watch list” that have low probability and low impact.   If a reassessment of these risks shows that some of them now have a higher probability and/or impact, they must be taken off the “watch list” and put on the risk register so that a risk response can now be developed.

To paraphrase the Serenity Prayer, a project manager should try to approach risk management using the serenity to prepare for the risks that cannot be avoided, to courage to prevent those risks that can, and the wisdom to know the difference.

The next post will cover the processes in Procurement Management, which is covered in chapter 12 of the PMBOK® Guide.

Advertisements

Integral Theory and Project Management–Tenet #8


This series of posts take the Ken Wilber’s introduction to Integral Theory called A Brief History of Everything and discusses the 12 main tenets concerning the concept of a holon and how they can be applied to the field of project management.  I have been posting one tenet a week on Sundays; this post covers tenet #8.

1.  Recap–definition of a holon, and tenets #1-7

A holon is an entity which consists of components, and yet is itself a component of a larger whole.

Tenet #1. Reality as a whole is not composed of things or processes, but of holons.

Holons must be considered from the standpoint of interacting with other holons on the same level, and with holons at higher levels (of which the holon is just a part) and lower levels (which comprise the parts of the holon).

Tenet #2 Holons display four fundamental capacities: The horizontal capacities of self-preservation, self-adaptation, and the vertical capacities of self-transcendence and self-dissolution.

Holons follow the dual rules of evolution when it comes to holons at the same level:    survival of the fittest (self-preservation) and survival of the fitting (self-adaptation).    Holons have the property of being able to evolve to the next highest level (self-transcendence), and they can also “devolve” into their component parts (self-dissolution).

Tenet #3 Holons emerge

As mentioned in Tenet #2, holons have the property of self-transcendence or evolution to the next highest level.    This is not just a higher degree of organization, but also involves emergent properties or differences in kind from the level below.

Tenet #4 Holons emerge holarchically

Holons, as seen above, are units that are both wholes containing parts and parts of larger wholes.   This kind of nested or concentric linking of holons reminiscent of the Russian matroshka dolls is considered a holarchy.    In contrast, we see in an organizational chart the traditional notion where parts are linked vertically to the levels above them (the notion of hierarchy), and horizontally to the units at the same level (the notion of a heterarchy).

Tenet #5  Each emergent holon transcends but includes its predecessor(s)

When a higher level of holons emerges, it incorporates the holons from a lower level but adds emergent properties.  A cell contains molecules, but is an entity which is capable of reproduction, where a property that goes above and beyond what a mere collection of molecules could do on its own.

Tenet #6  The lower sets the possibilities of the higher; the higher sets the probabilities of the lower.

Tenet #5  tells us that the higher level of holon has emergent properties which go above and beyond the lower level.  However, tenet #6 says that the higher level cannot ignore the lower level, and it there is bound to a certain extent by the possibilities set by the holons of the lower level.  However, the higher level also affects the lower level in that, the order imposed by the higher level of holons will influence the patterns in which the lower levels interact.

Tenet #7–The number of levels which a hierarchy comprises determines whether it is “shallow” or “deep”; and the number of holons on any given level we shall call its “span.”

The word for a hierarchy that is formed, rather than like an organizational chart by a series of horizontal and vertical lines, but rather by a concentric series of levels or organization better represented by circles, is called a “holarchy.”    At each level, the measure of the horizontal dimension, that is, the number of holons at that level, is called its “span” in the terminology of Integral Theory.    Now, the number of levels in the vertical dimension, on the other hand, is called its “depth”.     This is the number of levels of the holarchy, or concentric organization, that the holon is a part of.    The complexity of a project comes from its “depth”, not its “span.”   Bigger (in terms of span) is not always better.

In an aerospace company, a project will have a “span” equal to however many project members are involved in the project.    Its “depth” will be determined by whether, going upwards, it is part of a program and/or portfolio, and going downwards, whether there are sub-projects that are outsourced to a supplier.     The project manager has to manage not just the project, but has to be aware of the sub-projects that get integrated into the project as components purchased from suppliers, and in the other direction, of the program and portfolio of which that project is merely a part.

2.   Tenet #8  Each successive level of evolution produces GREATER depth and LESS span

This tenet follows from tenet #7 if you think about the definition of “depth” and “span” of a concentrically organized system of a holarchy.    Let’s say you have 5 projects that have been decided to be coordinated together in terms of a program in order to share resources between projects.    Before you had a “span” of 5 and a depth of “1”, meaning that at the project level, there were 5 projects in total, and only 1 level, that of the project itself.    After adding coordinating the projects in terms of a program, at the program level there is a “span” of 1 and a depth of “2”, meaning that there is only 1 program (consisting of the 5 projects) and two levels, that of the program and the projects which comprise it.

This may seem kind of a trivial point, that there will be fewer programs than there will be projects, because the programs each consist of several projects.    Ken Wilber makes this point because if you look at the concentric diagrams of any holarchy, the circle containing the highest level of organization is going to be on the outside, and the visual impact is that it has greater “span” in terms of area.    So Ken Wilber is simply emphasizing the fact that span refers to the number of holons at the same level; the reason why the circle is so large is so that it can encompass the lower levels inside of it.    The fact that the largest circle, representing the holon at the highest level, has several circles within it actually means that it has the greatest depth because it includes the most levels or holons (represented by the nested series of circles inside of it).

3.    Coordinating Complexity:   The Example of a Project Management Office

Because of the different levels of coordination needed between the subprojects (e.g., components outsourced from suppliers), projects, programs, and portfolios of an organization, many larger organizations have Project Management Office that oversees all of the project work in an organization (as opposed to the ongoing operational work) through all of its levels.    It is, in effect, one more layer of complexity or, using Integral Theory terminology, a level of holon above even the portfolio level itself.     There are three types of Project Management Organization or PMO, Supportive, Controlling, and Directive each of which has an increasing degree of control over the entire set of projects, programs, and portfolios in an organization.    The arrow below is in the direction of increasing control:

 

and a description of the 3 types of PMO is as follows in the chart below:

  PMO Type Degree of Control Description
1. Supporting Low Consultative role for projects.  Supplies templates, best practices, training, access to lessons learned on previous projects.
2. Controlling Medium Support and compliance role for projects. Supplies templates, best practices, etc. and assures compliance through audits.
3. Directive High Managing role to projects. Supplies templates, best practices, assures compliance through audits, and directs completion of projects.

Take a look at the description of the Supporting type of PMO.    It consults on the projects, and acts as a repository of knowledge based on projects that have come before.    This already benefits the organization by having a centralized place where the various templates, guidelines, training materials, and lessons learned from previous projects can all be stored for reference by any project manager in the organization.

The next level of control comes from a Controlling PMO, which adds to the supportive role in terms of a repository of knowledge, and also makes sure that the project managers are actually utilizing the best practices which they should be getting from that repository of knowledge through audits.

The final level of control comes from a Directive PMO, which adds to both the supportive and controlling role and actually takes a direct role in the execution of projects.    The project manager not only accesses the repository of knowledge built up by the PMO, but the processes which the project manager follows are audited, and the results are monitored and controlled as well.

For those who have been following Integral Theory in these posts, you will recognize that the three types of PMOs themselves form a concentric series of levels of organization, and are themselves an example of a holon.

A friend of mine who is on the board at a chapter of the Project Management Institute was hired as a project manager by an organization, and when they saw her experience, they wanted to get her input on the feasibility of creating a PMO within the organization.    Their vision of the PMO was in the form of a Directive type of PMO, which would actually monitor and control the results of all the projects.    They wanted to develop this first, but she said that the other levels, the supportive and the controlling levels of the PMO, needed to be developed first.    You can’t monitor and control the results of all the projects effectively without first making sure the project managers are using the project management processes correctly (the Controlling function of a PMO), and you can’t in turn make sure the project management processes correctly if the project management does not have access to all the knowledge and training required to know what the correct processes are.

They wanted the PMO to have one level, the Directive level, without having the “depth” that a PMO needs to have at that level, meaning that it has to ALSO have the Controlling and Supportive functions established.    Her instinct I believe was a correct one, and I wish her well in her quest to communicate that to her organization.

The next post in the series (one week from today) will cover tenet #9.

 

Alberta Tar Sands–a risk analysis by Andrew Nikiforuk (part 2)


Two weeks ago, there was a global affairs forum at a local church, and I attended in order to watch a presentation on the Alberta Tar Sands project.   Although the project is taking place in Canada, the environmental impact may end up being global, so that’s why it was included in the forum.    Jeff Green, who is a member of the Climate Reality Project, introduced a video documentary by Andrew Nikiforuk, a journalist based in Calgary, who has written a book on the project called Tar Sands:  Dirty Oil and the Future of a Continent.   Here’s a link to the video for those who want to watch the entire documentary http://www.youtube.com/watch?v=jiNgiPkF0TY

There needs to be a national debate about the pace and scale of the project, according to Mr. Nikiforuk.   He recommends that people listen to the advice of former Prime Minister Peter Lougheed, a conservative, who said this in 2006 about the project, “slow down, behave like an owner, collect your fair share, save for a rainy day, and clean up the mess.”   Yes, having the resources in Canada is a blessing to a certain extent from an economic standpoint, which is the positive risk or opportunity side of the equation.    But is there a full accounting of the potential negative impacts on the society of Canada?

6.   Declining Energy Returns (Energy Cannibalism)

To extricate bitumen from the tar sands underneath the ground, the technology called Steam-Assisted Gravity Drainage or SAGD is used.    This is where natural gas is burned to boil water, which is then turned into steam and injected into the bitumen deposits in order to melt them to the point where they can be brought up to the surface.     With SAGD, you need 4 times as much natural gas as you would in a traditional mining operation.   Every day, enough natural gas is used in the tar sands project to be able to heat 6,000,000 homes.    This consists of 1/5 of the entire natural gas supply of Canada.    Much of the natural gas is coming from the so-called “shale gale” from British Columbia, the processing of which is done by companies from Saudi Arabia, China and Korea.

It is important to understand the concept of Energy Returned on Investment or EROI.    It simply means “how much energy do you need to spend in order to get a certain amount of energy in return?”    100 years ago, the EROI in the oil industry was 100 to 1, meaning it took the energy equivalent of 1 barrel of oil to get 100 barrels of oil out of the ground.    The global EROI has been declining since the light crude oil has been taken out of the ground and the industry is moving on the heavier crude oil which is more difficult to extract and process.    For example, the current global EROI for the oil industry in general is about 20:1.    In the tar sands project, the traditional mining method has an EROI of 5:1,  but for the SAGD or steam-powered method mentioned above, the return is only 1.4:1.    Andrew Nikoforuk says the project is not sustainable simply from an economic standpoint because the return is so meager for the energy needed to obtain it.    It is a “progress trap”; a developmental dead end.    As the Catholic theologian Ivan Ilyich noted, “The energy crisis cannot be overwhelmed by more energy inputs.”

One phrase that I have invented to describe this situation is that declining energy returns can also be termed “increasing marginal futility.”

7.  Lack of Fiscal Accountability

The problem from the standpoint of the nation’s finances is that all of the wealth that is under the ground and theoretically belongs to the country as a whole is being practically given away to the oil industry.    The US Council on Foreign Relations said in 2009 that “Alberta has relatively low royalty and tax rates for the oil sands, which promotes greater production.”

Here’s a chart derived from the US Government Accountability Office report to the Canadian legislature in 2006 which shows the percentage of industry oil revenues that the government takes.    The highest is Venezuela as 89%, the lowest is Alberta at 39%.

Government Share of Industry Oil Revenues

Country

Percentage

Venezuela

89%

Nigeria

77%

Norway

76%

Angola

73%

Ecuador

61%

Louisiana

57%

California

53%

United Kingdom

52%

Wyoming

52%

Alberta

39%

in Norway, the net revenue for oil companies is about 23% of the gross, and many companies would be quite satisfied with that.    In Alberta, the government allows the oil companies to have a net revenue of 53%, almost double the rate of profit allowed by Norway.    In the last decade alone, this amounts to a $40 B giveaway to the oil companies in Canada.

This money should be saved for the future when Canada runs out of oil, and it could be used to stabilize the currency in the short run as well, which would be of immediate benefit to the economy.    Under the current conditions, the Federal government in Canada makes more money from oil sands development in the form of corporate taxes that the Alberta government makes it royalties because they have been set at such a low rate.

In Norway, there was a national debate involving all parties on the left, right, and center about how to use this natural wealth in such a way as not to undermine their democratic institutions.    The problem of relying on a natural resource for the majority of your revenue is that those in government tend to represent more and more the interests of those companies extracting the resource, and not the country as a whole, to whom the resource theoretically belongs in the first place.    This increases the political inequality of the country in the sense that it increases the divide between those who are governing and the people who are being governed.    The conclusion that the Norwegians came to in their national debate was that the revenue generated from the extraction of oil needed to be saved for exactly the reason mentioned above, because some day it will run out.    The Norwegians have saved about $500 billion since 1996, as opposed to $35 billion saved by the Canadians since 1978, of which Alberta has saved $14 billion.    The projection is that if Alberta doesn’t save $100 billion by 2030, it will likely be the most highly taxed region in North America.

The entire point of Andrew Nikiforuk’s talk, you might say, is that Canada needs to have a similar national debate because it does involve all Canadians, not just those in Alberta.   

8.   Regulatory Neglect

The Alberta Tar sands project is located in the world’s 3rd largest river basin, the MacKenzie River Basin, which provides 1/6 of Canada’s fresh water supply.   In 2009 and 2010, David Schindler and Aaron Kelly produced two scientific papers showing that the pollution from the tar sands project in the form of air particulates and watershed destruction was pouring a lot of contaminants into the Athabasca river such as bitumen and bitumen particulates such as heavy metals that were the equivalent of an annual oil spill of 5,000 barrels.    This has had an effect of increasing the number of severe deformities in fish caught in the Athabasca river.   But as for government regulatory oversight is concerned,, the one monitoring station on that river was not even calibrated to test for oil sands contaminants.    The government’s Oil Sands Advisory Panel in 2010 said an environmental monitoring system for the oil sands needed to be established.

In Alberta, the provincial government, after initially excoriating Schindler and Kelly for their findings, in essence admitted that they were correct in their conclusion that “PACs (polycyclic aromatic hydrocarbons) and trace metals are being introduced into the environment by oil sands operations.”

Not enough is known about the extent and capacity of the aquifers, and this question directly affects the question of how much groundwater loss through these tar sands operations can be sustained, and for how long.

9.   The Bitumen Debt

The oil industry has developed a PR campaign to develop “equivalent land capability” meaning that the trees on the lands that have been devoted to the oil sands project that have been destroyed will be replanted elsewhere.    The problem is that there is only $1 billion in the “reclamation fund” to clean up the mess in general, which is nowhere near an adequate amount to handle this enormous task.

The carbon intensity of the resources in Canada is among the highest in the world (Iran and Venezuela are high, but not as high as Canada).   40 million tons are being extracted in the tar sands to eventually produce 15 million barrels per day or bdp, as opposed to 15 million tons in Norway being extracted to produce 2.0 million bpd of oil.    It is a lot dirtier source of oil, in other words.

Shell Oil once described a scenario where they would face no regulatory opposition in the United States and have unfettered access to oil resources.    They called it the “scramble scenario” and they wisely said that this would in turn “attract increasing opposition from powerful water and climate lobbies that oppose the environmental footprint of these developments.”   According to Andrew Nikiforuk, that “scramble scenario” accurately describes not a hypothetical future, but the present in which we find ourselves right now.

10.   Immature Technology

We know that the SAGD technology requires 4 times as much natural gas as the traditional mining approach, but there are additional side effects of this technology to be considered, such as when the steam is released to the surface in a catastrophic explosion, like the one that occurred in May 18, 2006 and caused a 300-foot crater (luckily no one was injured).

The amount of steam is takes to create a barrel of oil has turned out to be underestimated.    It was estimated that it required 2.4 barrels of steam to extract a barrel of oil back in 1987-1989.    The average SAGD project now requires 3.5 barrels of steam, meaning that there has been a deterioration in the energy efficiency of about 50%, with companies requiring as much as 6 barrels of steam to product that same barrel of oil.

How innovative is the oil and gas industry?    Not very much, as compared to automotive, pharmaceutical, or technological companies such as Toyota, Pfizer, or Google.    They are not lean enough as operations to support the R&D required to be innovative.

Conclusion:  The Leadership Gap

St. Francis of Assisi once said, “start by doing what’s necessary; then do what’s possible; and suddenly you are doing the impossible.”   Canada needs to have a national debate on the extent of the oil sands project in Alberta and heed the advice of former Prime Minister Peter Lougheed, a conservative, who said this in 2006 about the project, “slow down, behave like an owner, collect your fair share, save for a rainy day, and clean up the mess.”

I would say that we need to have a similar debate in the United States about the extraction of shale oil and gas through hydrofracturing (fracking), and the transport of tar sands oil through the proposed Keystone Pipeline system.    

  • Is the U.S. government behaving as if it is the owner of the resources on behalf of its people?    
  • Is it collecting a fair share of the revenue generated from those resources?  
  • Is it saving for a rainy day when those resources will no longer be available?  
  • Are there sufficient resources being devoted to cleaning up the environmental mess created by that extraction?   

5th Edition PMBOK® Guide—Memorizing the Processes (Step 3: Communications Knowledge Area)


1.   Introduction

After memorizing the 5 process groups (step #1) and the 10 knowledge areas (step #2), the next step in mastering the memorization of the processes is figuring out where the 47 project management processes fit in the matrix made by those process groups and knowledge areas.    The best way to do that is to first memorize the names and order of the processes by knowledge area.    In previous posts, I have covered the knowledge areas of Integration (chapter 4 of the PMBOK® Guide), Scope (Chapter 5), Time (chapter 6), Cost (chapter 7), Quality (chapter 8), and Human Resources (chapter 9).   This post will cover the processes involved in the Communications Resources Management knowledge area, which is covered by chapter 10 of the PMBOK® Guide.

Here are the 47 processes of project management; the chart indicates how many are in each knowledge area and process group.

Initiating Planning Executing Monitoring & Controlling Closing
Integration 6

1

1

1

2

1

Scope 6

4

2

Time 7

6

1

Cost 4

3

1

Quality 3

1

1

1

Human Resources 4

1

3

Communications 3

1

1

1

Risk 6

5

1

Procurements 4

1

1

1

1

Stakeholder 4      1

1

1

1

 47

2

24

8

11

2

 

2.  Communications Management knowledge area

Here’s the portion of the above matrix of 47 processes that lists the processes in the Communications Resources Management knowledge area, which is covered in chapter 10 of the 5th Edition of the PMBOK® Guide.

Knowledge Area Total # of Processes Initiating Planning Executing Monitoring & Controlling Closing
Communications

3

1  1  1

You may notice that, for the Communications knowledge area, the pattern of distribution of the processes in the process groups is EXACTLY the same as in the Quality knowledge area:   there are three processes, one of each in the Planning, Executing, and Monitoring & Controlling Process Groups.

NOTE:    The new knowledge area of Stakeholder Management, which is covered by Chapter 13 of the the 5th Edition of the PMBOK® Guide, was an outgrowth of the Communications Management knowledge area.    However, PMI felt that it was more important than just to passively communicate with the stakeholders, but to actively engage them in the course of the project, and that is why it became its own knowledge area.

Here’s a chart which gives the names of the four processes and a brief process description.

 

Process

Group

Process

Number

Process
Name
Process Description
Planning 10.1 Plan Communications Management Developing an appropriate approach and plan for project communications based on stakeholders’ needs and requirements, and available organizational assets.
Executing 10.2 Manage Communications Process of creating, collecting, distributing, storing, retrieving project information.
Monitoring & Controlling 10.3 Control Communications Process of monitoring and controlling communications throughout the entire project life cycle.

10.1 Plan Communications Management

The purpose of this process is to set the appropriate approach for communications throughout the project; in effect, to give the framework for all of the other processes in the Communications knowledge area.    It has as an output the Communications Management Plan, which shows what information various stakeholders need based on their requirements, and the format in which those communications will take place, given the organization’s available assets.   It is a planning process, which one can immediately see by the word “Plan” in the title.

10.2 Manage Communications

This is the process of carrying out the communications throughout the course of the project according to the Communications Management Plan.    Hence it is in the Executing Process group.    Some examples of things that are important to communicate with stakeholders are the performance results on an ongoing basis, and any proposed changes to the scope of the project.

10.3 Control Communications

The monitoring & controlling of the communications process is important so that if there are issues related to communications based on feedback from the stakeholders, these can be addressed through changes to the Communications Management Plan.

With this knowledge area, if you remember that there are 3 processes, the keywords “Plan”, “Manage”, and “Control” should be helpful in remembering the names of the three processes and putting them in their correct processes of Planning, Executing (= Managing), and Monitoring & Controlling.

The next post will be on Chapter 11, Project Risk Management.

5th Edition PMBOK® Guide—Memorizing the Processes (Step 3: HR Knowledge Area)


 

 

1.   Introduction

After memorizing the 5 process groups (step #1) and the 10 knowledge areas (step #2), the next step in mastering the memorization of the processes is figuring out where the 47 project management processes fit in the matrix made by those process groups and knowledge areas.    The best way to do that is to first memorize the names and order of the processes by knowledge area.    In previous posts, I have covered the knowledge areas of Integration (chapter 4 of the PMBOK® Guide), Scope (Chapter 5), Time (chapter 6), Cost (chapter 7), and Quality (chapter 8).   This post will cover the processes involved in the Human Resources Management knowledge area, which is covered by chapter 9 of the PMBOK® Guide.

Here are the 47 processes of project management; the chart indicates how many are in each knowledge area and process group.

Initiating Planning Executing Monitoring & Controlling Closing
Integration 6

1

1

1

2

1

Scope 6

4

2

Time 7

6

1

Cost 4

3

1

Quality 3

1

1

1

Human Resources 4

1

3

Communications 3

1

1

1

Risk 6

5

1

Procurements 4

1

1

1

1

Stakeholder 4      1

1

1

1

 47

2

24

8

11

2

2.  Human Resources Management knowledge area

Here’s the portion of the above matrix of 47 processes that lists the processes in the Human Resources Management knowledge area, which is covered in chapter 9 of the 5th Edition of the PMBOK® Guide.

Knowledge Area Total # of Processes Initiating Planning Executing Monitoring & Controlling Closing
Human Resources

4

1  3

There are two unusual things about the HR Knowledge Area with respect to how the processes fit into the 5 process groups, that make it different from all the other knowledge areas.    First of all, there are a total of 3 processes in the Executing Process Group; all other knowledge areas that even have a process in the Executing Process Group have only 1 process in that group.    Secondly, it is the only knowledge area not to have any processes at all in the Monitoring & Controlling Process group.    The way I told our study group to memorize this last point is to make the observation that the monitoring & controlling involved in all the other processes has to be done by people (who are part of human resources), and that is why there is no monitoring & controlling process for human resources itself.    (This may not be the official PMI version of why they decided to apportion the processes in this way, but it is a simply a story that helps you memorize this fact.)

Here’s a chart which gives the names of the four processes and a brief process description.

Process

Group

Process

Number

Process
Name
Process Description
Planning 9.1 Plan Human Resource Management Process of documenting project roles, responsibilities, required skills, reporting relationships, and creating a staffing management plan.
Executing 9.2 Acquire Project Team Process of confirming the availability of resources, and obtaining the members of the team.
Executing 9.3 Develop Project Team Process of improving competencies, team member interaction, and the overall team environment.
Executing 9.4 Manage Project Team Process of tracking team member performance, providing feedback, resolving issues, and managing team changes.

9.1 Plan Human Resource Management

The first planning process for all the knowledge areas, consists of creating the framework for all of the other processes in that knowledge area.    The Human Resources knowledge area is no exception; the Plan Human Resources Management process has as its aim

  • the listing of all the roles on the project,
  • documenting what the responsibilities of the people in those project roles will be,
  • what skills the people in those roles will have to have,
  • what the reporting relationships of these various roles will be to each other, and finally
  • at what point in the project these various people will have to perform their roles (the staffing management plan)

All of this comes together in the output for this process, the Human Resources Management Plan.

9.2 Acquire Project Team

When you need people for your team, you need to a) check with the human resources department for their availability and then b) obtain the people necessary for your team as outlined in the Human Resources Management Plan.  This is why this process is in the executing process group.    The project manager does not have direct control over these people, the human resources department and management do; that is why the project manager must negotiate for these resources and influence those decision-makers into letting those people work for the project for the specified duration.

9.3 Develop Project Team

Here is the process that takes the “team members” and turns them into a team that works together.    In some cases, you will have to improve the competencies of some of the team members in the area of technical skills in order to get them “up to speed” in order to perform their roles.    But in all cases, you will have to use people skills in order to bring the team members together (Forming stage), and get them from being a group of individuals who have potential conflicts with each other (Storming stage), to the point where they are adjusting to each other (Norming stage), and focusing on the work that must be done (Performing stage).    This is the true core of being a project manager, to manage the individual team  members of your project to work together as a larger whole, the project team.

9.4 Manage Project Team

Once the team has passed to the Performing stages as described in the last process, you then need to track the performance of team members and give them feedback, always with the idea of improving their performance on the project.   You may have to resolve conflict between team members that occurs during the course of the project (as opposed to the initial conflicts during the Storming phase of developing the project team).

This sounds very much like monitoring and controlling your team members, but for some reason, the Project Management Institute puts this process in the Executing Process Group.

At least in terms of memorization, after the initial planning process, the names of the 3 processes in the Executing Process Group, 9.2 Acquire Project Team, 9.3 Develop Project Team, and 9.4 Manage Project Team should be obvious from their description.   They all end in “Project Team”, and it makes sense that you would first “Acquire”, then “Develop”, and then “Manage” that team.

3.   Conclusion

The Human Resources Management knowledge area has 4 processes, one of which is in planning and creates the Human Resources Management Plan, and the other 3 of which are in the Executing Process Group, and consist of acquiring the team members, forming them into a team and putting them to work on the project, and making adjustments to the team as the project progresses.

The next post will cover the next Knowledge Area, that of Communications Management, covered in chapter 10 of the PMBOK® Guide.

5th Edition PMBOK® Guide—Memorizing the Processes (Step 3: Quality Knowledge Area)


 

1.   Introduction

After memorizing the 5 process groups (step #1) and the 10 knowledge areas (step #2), the next step in mastering the memorization of the processes is figuring out where the 47 project management processes fit in the matrix made by those process groups and knowledge areas.    The best way to do that is to first memorize the names and order of the processes by knowledge area.

Here are the 47 processes of project management; the chart indicates how many are in each knowledge area and process group.

Initiating Planning Executing Monitoring & Controlling Closing
Integration 6

1

1

1

2

1

Scope 6

4

2

Time 7

6

1

Cost 4

3

1

Quality 3

1

1

1

Human Resources 4

1

3

Communications 3

1

1

1

Risk 6

5

1

Procurements 4

1

1

1

1

Stakeholder 4      1

1

1

1

 47

2

24

8

11

2

2.  Quality Management knowledge area

I have discussed the integration, scope, time and cost knowledge areas (covered by Chapters 4, 5, 6, and 7 of the PMBOK® Guide) in previous posts; this post will cove the Quality Management knowledge area covered by Chapter 8 of the  PMBOK® Guide.    Here’s the portion of the above matrix of 47 processes that lists the processes in the Quality Management knowledge area, which is covered in chapter 8 of the 5th Edition of the PMBOK® Guide.

Knowledge Area Total # of Processes Initiating Planning Executing Monitoring & Controlling Closing
Quality

3

1  1

1

Please note that, as opposed to the traditional “triple constraint” knowledge areas of Scope, Time and Cost which had NO processes in the Executing Process Group, the Quality Management Knowledge Area has 1 such group, in addition to the 1 process in the Planning and the 1 process in the Monitoring & Controlling Process Group.

Here’s a a chart which gives the names of the three processes and a brief process description.

Process

Group

Process

Number

Process
Name
Process Description
Planning 8.1 Plan Quality Management Identifies quality requirements and/or standards for the project and its deliverables; documents how the project will demonstrate compliance with quality requirements.
Executing  8.2 Perform Quality Assurance Audits the quality requirements and results from quality control measurements to ensure that appropriate quality standards and operational definitions are being used.
Monitoring & Controlling 8.3 Control Quality Monitors and records results of executing the quality activities to assess performance and recommend necessary changes.

8.1  Plan Quality Management

If you’re read the earliest posts, you should see a familiar pattern:   the Plan Quality Management process is the first planning process, actually the only planning process, and it is used to create the framework for the other quality management processes, and the output of the process is the Quality Management Plan.    In this case, it identifies the requirements for quality and the standards that will be used to measure and control the quality.     It also does some groundwork in listing the quality tools and techniques that the project manager will have available to him or her during the course of the project.

8.2. Perform Quality Assurance

The questions being answered here are:  are the quality standards appropriate for the project, and are they faithfully being followed during the course of the project? The process focuses on the quality of the processes themselves, and it is associated with the word audit.   

8.3 Perform Quality Control

The question being answered here is:  are the deliverables meeting the quality standards (the ones set in process 8.1 and audited in process 8.2)?  The process focuses on the quality of the deliverables, and it is associated with the word inspection.   

In the monitoring part of this process, the results of the quality control are communicated to all interested stakeholders.   If the deliverable is inspected, and the results of the inspection show that the deliverable does not meet the quality standards, the deliverable is said to have a defect.    There must be a change to bring the quality of the deliverables back into line with the standards.

There are three types of changes that can be proposed.    For those who have read the Christmas Carol by Charles Dickens, you know that the plot revolves around a miserly old man named Ebenezer Scrooge who is visited by three ghosts, the Ghosts of Christmas Past, Present, and Yet to Come.    Similarly, a project manager can be haunted by the ghosts of three types of Defects:   Defects Past, Present, and Yet to Come.    These are dealt with in the following three ways:

a) Defects Past:   for defects that have already occurred, you can deal with them by repairing the defective deliverables and re-inspecting them to see if they now conform to the quality standards.   Alternatively, these defective deliverables can be scrapped.

b) Defects Present:   for defects that are ongoing, you must deal with them by finding out the root cause, and then making a change that will eliminate, or at least mitigate, the cause of the defects.    This proposed change to the work method must then be analyzed to see what affects it may have on other constraints (for example, will it cause the work to take more time, or cost more money).

c) Defects Yet to Come:    if you look at the results of quality control and compare them to those at previous points of the project, you can see whether there is a trend that, if continued, might bring the quality out of alignment with the standard at some point in the future.    The way of dealing with this is similar to paragraph b) above, except that you have more time to solve the quality problem.    However, by dealing with the quality problem now rather than after it has caused a defect, you will be saving the company the cost of potentially having to repair or scrap defective deliverables, like in paragraph a) above.

So the quality process in general is a) choose the quality standards (process 8.1), b) assure through quality audits that those quality standards are being faithfully followed (process 8.2), and c) verify through quality inspections that the deliverables actually meet those quality standards.

3.  Conclusion

The process 8.1 Plan Quality Management has the word Plan in it, so it is easy to memorize that it comes first as a planning process; likewise the process 8.3 Perform Quality Control has the word Control in it, so it is easy that is in the Monitoring & Controlling process group.   The only tricky one for some people is Quality Assurance, which may imply “monitoring” because it is associated with word “audit.”   But the purpose of the audit is to make sure you are “executing” or carrying out the standard correctly.    Thus it belongs properly in the Executing Process Group.

Also remembering that there are three processes spread across three process groups will reinforce for you the notion that there is one process in each of the three process groups Planning, Executing, and Monitoring & Controlling.

The next post will switch to the “people” part of the project, by covering Human Resources Management, which is chapter 9 of the 5th Edition PMBOK® Guide.

5th Edition PMBOK® Guide—Memorizing the Processes (Step 3: Cost Knowledge Area)


1.   Introduction

After memorizing the 5 process groups (step #1) and the 10 knowledge areas (step #2), the next step in mastering the memorization of the processes is figuring out where the 47 project management processes fit in the matrix made by those process groups and knowledge areas.    The best way to do that is to first memorize the names and order of the processes by knowledge area.

Here are the 47 processes of project management; the chart indicates how many are in each knowledge area and process group.

Initiating Planning Executing Monitoring & Controlling Closing
Integration 6

1

1

1

2

1

Scope 6

4

2

Time 7

6

1

Cost 4

3

1

Quality 3

1

1

1

Human Resources 4

1

3

Communications 3

1

1

1

Risk 6

5

1

Procurements 4

1

1

1

1

Stakeholder 4      1

1

1

1

 47

2

24

8

11

2

2.  Cost Management knowledge area

I have discussed the integration, scope, and time knowledge areas (covered by Chapters 4, 5, and 6 of the PMBOK® Guide in previous posts; this post will cove the Cost Management knowledge area covered by Chapter 7 of the  PMBOK® Guide.    Here’s the portion of the above matrix of 47 processes that lists the processes in the Time Management knowledge area, which is covered in chapter 6 of the 5th Edition of the PMBOK® Guide.

Knowledge Area Total # of Processes Initiating Planning Executing Monitoring & Controlling Closing
Cost

4

3

1

Here’s a chart which gives description of the four processes that are included in the Cost Knowledge Area, 3 of which are in the Planning Process Group and 1 of which is in the Monitoring & Controlling Process Group.

Process Group Process Number Process Name Process Description
Planning 7.1 Plan Cost Management Establishes policies, procedures, and documentation for planning, managing, expending, and controlling project costs.
Planning 7.2 Estimate Costs Develops an approximation of the monetary resources needed to complete project activities.
Planning 7.3 Determine Budget Aggregates the estimated costs of individual activities or work packages in order to establish an authorized cost baseline.
Monitoring & Controlling 7.4 Control Costs Monitors the status of the project to update the project costs and manages changes to the cost baseline.

Let’s take a closer look at the process descriptions, taken from the PMBOK® Guide.   I think if you pay attention to the essence of what each process is, you will see how they flow from one to the other.

7.1  Plan Cost Management

Just like every other knowledge area, the first planning process is of the form “Plan X Management” where “X” is the name of the knowledge area.    In this case, the process is Plan Cost Management.    The purpose is to establish the guidelines and procedures for all of the rest  of the cost management processes.    The output of the processs is the Cost Management Plan, which is one of the knowledge area management plans that make up the overall Project Management Plan.

7.2 Estimate Costs

Costs are estimated by various methods, such as those based on

  • past projects if a similar project was done in the past, either by the organization itself or some other organization in the industry
  • top-down or bottom-up estimates, with top-down being the most general and approximate, and bottom-up being the most specific and accurate
  • averaging between pessimistic, neutral or optimistic assumptions regarding costs

You may note that the last estimate method, that of averaging between estimates based on various types of assumptions used to create them, is actually a form of risk management that is incorporated into cost management.    Although risk management is another knowledge area, the knowledge areas are thematically separate in theory, but in reality they intersect during a project, so that for example, when determining the budget like you do in the next process, you use as inputs the result of previous processes in cost management, but you also use results from other knowledge areas such as time management and risk management.

7.3 Determine Budget

Once you have the work packages (the smallest unit of deliverable on the project) broken down into units of work called activities (done in 6.2 Define Activities), these units can be estimated not just in terms of time (how many work periods or hours will it take to complete the activities) but also of cost (how much will those activities cost).    If you add these costs of individual up over the entire project, you get the project estimate.    To that you add contingency reserves that cover the cost of dealing with risks that might occur during the project; the project estimate plus the contingency reserves gives you the cost baseline.    This is what the progress of the project will be measured against during the next process in the monitoring & controlling process group.

7.4 Control Costs

In the monitoring portion of this process, you use tools such as earned value to find out whether your project is proceeding according to plan or not, specifically the cost baseline mentioned in the last process.    The output is the work performance information with respect to the cost baseline, which needs to get communicated to all parties concerned, not just on the project itself, but the various interested stakeholders (suppliers, customers, management, etc.).

What happens if the project is NOT going according to the cost baseline?    The first way to control the project is to suggest changes to the project that will make it conform once again to that cost baseline.    These change requests come in the form of corrective actions and preventive actions.    Corrective actions help make current activities conform to the cost baseline, and preventive actions help make future activities conform to the cost baseline.     These actions could include changing from higher-cost to lower-cost resources, or reducing the scope of the project.    In these two examples, other constraints on the project may be affected; switching to lower-cost resources may have an adverse affect on the quality of the product, and reducing the scope of the project may have repercussions on the stakeholder acceptance of the project.    So it is vital that any outputs of this process in the form of proposed changes to the project ts be analyzed through the change control process.

The second way to control the project is, if you realize during the course of the project that the project is so costing so much that you will never get it within the budget, then you may find that the problem was not with the project, but with the project budget being unrealistic in the first place.    Perhaps events have come up which were unexpected, or perhaps the assumptions you made in creating that budget turned out not to be true.    In any case, it is possible that the change request may not be to the project, but to the cost baseline.

The output of this controlling part of the process, then, are change requests that change either the project (to conform with the cost baseline), or to the schedule baseline itself.    In either case, these change requests get analyzed in the change control process, which is done under the Integration Knowledge Area under the process 4.5 Perform Integrated Change Control.

If the changes are implemented, then the monitoring & controlling process will be used periodically throughout the project to see if those changes did indeed work to bring the project and the cost baseline back in alignment.

3.   Conclusion

The next post will cover the next Knowledge Area, that of Quality Management (covered by Chapter 8).