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.

Advertisement

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).

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


1.   Introduction

In the last post, I discussed the processes in the Scope Knowledge Area, which is covered in Chapter 5 of the 5th Edition PMBOK® Guide.   In this post, I will discuss the processes in the Time Knowledge Area, which is covered in Chapter 6.

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.  Time Management knowledge area

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
Time

7

6

1

Here’s a description of the seven processes that are included in the Time Knowledge Area.    The process descriptions are taken from the the PMBOK® Guide.

Process Group Process Number Process Name Process Description
Planning 6.1. Plan Schedule Management Establishes policies and procedures and documentation related to the project schedule.
6.2 Define Activities Identifies and document specific actions (activities) to be performed the product deliverables.
6.3 Sequence Activities Identifies and documents relationships among project activities.
6.4 Estimate Activity Resources Estimates the amount of resources (material, people, equipment, or supplies) required to perform the project activities.
6.5 Estimate Activity Durations Estimates the number of work periods needed to complete project activities.
6.6 Develop Schedule Analyzes project activity sequences, durations, resource requirements and schedule constraints to create the project schedule model.
Monitoring & Controlling 6.7 Control Schedule Monitors the status of project activities to update the progress of the project with respect to the schedule baseline, and to manage any changes needed to achieve the plan.

Let’s take a closer look at the process descriptions.   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.

6.1  Plan Schedule Management

As mentioned in the last post, for all of the knowledge areas, the first planning process is going to create the management plan associated with that area.    In this case, the process will create the Schedule Management Plan, which outlines all of the guidelines and processes for doing all of the other processes, not just the planning processes but the process that is in the monitoring & controlling process group as well (6.7 Control Schedule).    One of the important elements of that management plan will be the schedule baseline, which will be the ultimate product of the last of the planning processes, 6.6 Develop Schedule.   But to get to that last planning process, you need to go through four other planning processes.

That is why, out of all of the knowledge areas, the Time or Schedule Management knowledge area has the most processes of all (7).

6.2 Define Activities

The last planning process for the previous knowledge area, that of Scope Management, is 5.4 Create WBS, which is the process of breaking down the project work down, from deliverables to work packages, the individual units of the work breakdown structure.    Work packages are nouns, which tell you what you are supposed to produce (the end product).

This process Define Activities takes those nouns, the work packages, and lists the activities you will need to do in order to accomplish those work packages.    Activities are verbs, which tell you what you are supposed to do (the process).

6.3 Sequence Activities

Okay, you have a list of activities.   In what order to you do them?   Are there are activities that specifically need to be done BEFORE others.   Do you have to do them all one after another (series relationship), or can you some of them simultaneously (parallel relationship), assuming you have the resources to do so.   By the time you are done, you know WHAT needs to be done (the output of 6.2 Define Activities) and in WHAT ORDER (the output of 6.3 Sequence Activities.

6.4 Estimate Activity Resources

How long will the project take to complete the activities in the order you have determined?   Before you can answer that question, you need the answer to two more questions, the first of which is answered by this process:   what resources do you have available to complete the activities.     The answer to this question is the output of this process 6.4 Estimate Activity Resources.

6.5 Estimate Activity Durations

The second question you need to answer before getting to the ultimate question of “how long will the project take” is answered by this process:   given the resources you determined in process 6.4 Estimate Activity Resources, how long will each activity take in terms of work periods (usually in terms of 8-hour work days, but this can vary).

6.6 Develop Schedule

If you combine all of the outputs for the previous planning processes, you get the activity resources (6.4) applied to the sequence of activities (6.2 and 6.3) to get the activity durations (6.5).     This gives you the rough “first draft” of the schedule.  Now there are schedule constraints that may need to be applied.     Let’s say your first draft of the sum of all activity durations says the project will take 12 months.    But management says it absolutely has to get done in 8 months.    Then you may need to do an iteration or repetition of the planning processes to see if the project can get done in that time frame.   You can either try to sequence the activities differently, for example, by trying to do more processes at once, or you can add more resources in order to get the same activities done in less time.    Both of these approaches may be necessary.

The schedule is referred to by the Project Management Institute by the term the schedule model, because how long the schedule will take will be affected by various assumptions.    In order to get to a schedule within the constraints imposed by management, you may have to change those assumptions to see how the schedule changes in response.    That is essentially what I outlined at the end of the paragraph above.    You may have to ask yourself, “what will happen if do these activities in a different sequence?” or “what will happen if I get extra people to work on the project?”   Just be aware that in order to accomplish these changes in order to change the schedule, other constraints such as risk or cost may be affected.   For example, to do activities at the same time rather than one after the other may increases the risk of making a mistake because of the increased need to coordinate more activities within a certain timeframe.   Likewise, adding more resources in order to reduce the time it takes to complete certain activities will necessarily involve higher costs.

Once you have a schedule that fits the schedule constraints, this then becomes the schedule baseline of the project, and it is the output of this last planning process.    This is what the progress of the project will be measured against in the monitoring & controlling process that comes next.

6.7 Control Schedule

Now switching to the Monitoring & Controlling process group, Control Schedule tells you whether you are proceeding according to the schedule baseline.    This is the monitoring part of the process, and the output is the work performance information with respect to the schedule 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 schedule baseline.    The first way to control the project is to suggest changes to the project that will make it conform once again to that schedule baseline.    These change requests come in the form of corrective actions and preventive actions.    Corrective actions help make current activities conform to the schedule baseline, and preventive actions help make future activities conform to the schedule baseline.

The second way to control the project is, if you realize during the course of the project that the project is so far behind that you will never catch up to the schedule baseline, then you may find that the problem was not with the project, but with the project schedule being unrealistic in the first place.    Perhaps events have come up which were unexpected, or perhaps the assumptions you made in creating that schedule 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 project schedule.

The output of this controlling part of the process, then, are change requests that change either the project (to conform with the schedule baseline), or to the schedule baseline itself.    In either case, these change requests get analyzed in 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 schedule baseline back in alignment.

3.   Conclusion

The Time or Schedule Management knowledge area is the most complicated in terms of planning, but if you understand what the planning processes do, then memorizing their order is not too difficult.    You have to define the activities before you sequence them, and you have to figure out how much resources you have to apply to the activities before you figure out how long it will take to complete those activities.

The last planning process, for the three knowledge areas that comprise the traditional “triple constraints”, that is scope, time and cost, have as their output the baseline for that knowledge area.   In the case of Schedule Management, the output of the last planning process is the schedule baseline, which is then used as the “measuring stick” for the progress of the project.    The last process, in the monitoring & controlling process group, measures the progress against that baseline and, if the progress is off somehow from that baseline, changes are suggested in order to bring them back into alignment.

So write down on index cards the name of the process (for example, Define Activities), and then on the other side put the process number and the name (for example, 6.2 Define Activities).    In this way, when you see a process name, you will be able to guess what knowledge area is comes in and which order (the “6” tells you that it comes from chapter 6, which covers the Schedule Management knowledge area, and the “2” tells you that it is the process #2 from that knowledge area.

Eventually, you should be able to list “from memory” all of the names of the 7 processes from the Schedule Management knowledge area and put them in their proper order.    Take it one knowledge area at a time, a couple days per each knowledge area, and you will be able to memorize all of the 47 processes within about a month.

The next post deals with the Cost Management knowledge Area.   This knowledge area, along with Scope Management and Time Management, is one of the three traditional “triple constraints” of project management.

Integral Theory and Project Management–tenet #7


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 #7.

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

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.

2.  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”.   

Let’s give an example from Project Management to sort out this terminology, and then I will deal with its significance.    If you are on a project, the number of team members determines the “span” of the project.    The bigger the project, in conventional terms, the more team members that will be required to do the work.    Now, the more complex the project, the more likely it is that the project will have great “depth” in the form of the number of layers of project organization involved.

Let’s take an aerospace company as an example.    The process of designing a new airplane is a very complex process.    The design of each airplane will actually be a program, which consists of several projects, each of which will be one portion of that aircraft:   the engines, the fuselage, the wings, the cockpit, etc., that then have to be coordinated at the program level to make sure that the portions of the aircraft fit together once designed, prototyped, tested and then manufactured.    Now the project of designing a portion of the airplane, let’s say the engine, will consist of components that are not manufactured by the aerospace company, but by a supplier.    Let’s say that a certain component of that engine will be produced by a supplier.    To the supplier, the same stages of design, prototype, test and manufacture will take place on the component level and will be, from the supplier’s standpoint, a project in and of itself.    To the aerospace company, that component will be a sub-project that needs to be monitored during the process of procurement.

An aerospace company will no doubt have other aircraft, perhaps some for military use and some for commercial use.   They may have, among the ones for military use, different types of aircraft, some fixed-wing, some helicopters, etc.    Because the designs for these various types and usages differ, the thing that binds each of the programs that produce them is the portfolio, which links them together under the common strategic goal of making money for that company.

So wrapping up this example, there are the following levels of organization involving the project:

  1. Sub-project
  2. Project
  3. Program
  4. Portfolio

These vertical levels are the “depth” of the project; as you might guess, the more “depth” to a project, the more complexity the project will have, because coordination must take place vertically downwards (the sub-project), and then vertically upwards (the program and portfolio).    The complexity comes from what was discussed earlier, the fact that, as you go up a level of a holarchy, a concentric form or organization, there is usually some qualitative difference of complexity that is added.   Adding to the span of a project, that is, the number of team members that comprise the project, usually just involves a quantitative difference of the complexity, particularly when it comes to communication between the team members.

From a project management standpoint, you have to be aware that the need for internal coordination of the project is necessary, of course, for the project to succeed, but it is not enough.    If you do not sufficiently coordinate the sub-projects by the suppliers to produce components for your project, your project may fail.    If you do not release the resources when they are no longer needed, that will hurt the program, and thus indirectly hurt your project.    Finally, if you do not pay attention to the strategic goal of the organization when it comes to whatever metric for financial success they set, for example, a certain return on investment (ROI), then your project may have its “plug pulled” by upper management.   

So it is necessary to come to terms with  the number of levels or the “depth” of complexity of the project and not just the amount of resources required to complete the project or the “span” of the project.    Both dimensions must be kept in mind in order to have your project succeed.   In other words, to paraphrase the book title by Fr. Thomas Merton, “NO PROJECT IS AN ISLAND.”

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


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.

To be honest, based on the title of his book, I thought the presentation was going to be on the environmental impact of the Alberta Tar Sands project, both in terms of the local pollution caused by the mining, and in terms of the possible impact on global warming if once the final oil products are consumed by an energy-hungry world.    What emerged in the documentary was a more integral look at the various risks, societal, economic, and political, in addition to the environmental risks that I had expected to hear about.   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?   This post is a summary of the 10 points made by Andrew Nikiforuk in his documentary, which attempts to answer this question.

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.”

Here is a survey of 10 risks that need to be considered when discussing the full impact of the Alberta Tar Sands project.

1.  Bigness (and brittleness)

This project is one of the largest and more complex engineering projects in history.    The resource, which is the world’s 2nd largest reserve of hydrocarbons, can be found underneath an expanse of forest the size of Florida.    The earth removed to get at the resource since the 1970s would fill 7 Panama Canals.   Many of the individual mining projects that make up the entire project are themselves the size of small-to-medium size cities.    The entire surface area of the project covers 1.6 million hectares, the equivalent of 20 cities the size of Calgary, 40 cities the size of Denver, or 17 cities the size of Berlin, and it will produce 6 billion barrels of toxic waste (1 barrel of bitamen extracted produces 1.5 barrels of mining waste).    According to the RiskMetrics Group, it would cost $20 billion just to separate the water in the toxic waste from the sand and the clay.

70% of the oil in the United States now comes from Canada, with the majority of that oil coming from the tar sands in Alberta.    It comes from Canada through an enormous pipeline complex, which is being proposed for expansion, from Alberta through British Columbia to the West, and down through to Texas in the United States.

The brittleness of big things is startling–there was a pipeline break on the  Kalamazoo River in July 2010 that released a million gallons.    This oil  spill cost Enbridge, the company that operated the pipeline, half a billion dollars to clean up.    This one leak caused the price of oil to go up $10, and caused the shutdown of between 6 and 8 refineries in the Midwest, and $340 million lost revenue to Alberta.

Nassim Nicholas Taleb was a derivatives trader and “quant” trader before starting a full-time career as a scholar of applied probability and risk.    His theme is that “big things fail,” and he was one of those who predicted the failure of the banking industry in 2008.    He says that “Mother Nature is robust.   Large modern corporations are fragile.   No government can fortify something that’s inherently fragile.   Leopold Kohr, an economist, wrote in the 1970s and 1980s that “There seems to be one cause of social misery:  bigness … whenever something is wrong, it is too big.”

2.   Energy Security

340,000 people in Canada have moved from Eastern Canada westward to Alberta in order to work in the Alberta Tar Sands project.    Yet where is the oil consumed in Canada itself coming from?   It is coming from Algeria, Iraq, and Saudi Arabia.   Canada in fact is more dependent on foreign oil now than the United States (which is 70% dependent on oil imports).     One of the problems with energy exports to the United States comes from the NAFTA trade agreement.    The heavy crude oil cannot be moved south through the pipeline unless the it is diluted with some sort of oil-based diluent or condensate.    The supply of diluent from North America has run out, so now 210,000 barrels a day have to be imported from the Middle East and Venezuela.    Bitumen is a product made in North America, but when it is diluted with condensate from outside of North America, U.S. Customs makes the argument that it is no longer a North American product, and may face higher import duties for that very reason.

3.  Oil Price Shock Vulnerability

Bitumen is one of the world’s most expensive hydrocarbons.   It requires a world price of between $60-80 per barrel of oil in order for the production to be profitable.    Whenever the oil price drops to $30/barrel, the production in the oil sands in North America is going to drop first because it is the most economically marginal oil product.    This happened in 2008, when tens of thousands of Canadians were laid off from the tar sands project, and $150 billion worth of projects were cancelled.    Most of the economic recessions in the past few decades were due to oil price shocks.    The more the Canadian economy is tied to oil production, the more vulnerable it will be to future oil price shocks.

According to a study by the C. D. Howe Institute called Energy Prices and Alberta Government Revenue Volatility, the government of Alberta’s revenue stream has been and continues to be the most volatile out of any jurisdiction in Canada.    They said, “volatile revenues usually leads to volatile government expenditures … and the inefficient provision of government services.”

4.   The “Dutch Disease”

The “Dutch Disease” is an expression that the Economist magainze gave to the results of  to the discovery or natural gas by Holland in the 1970s.    They exported it, and it not only drove the exchange rate of the guilder way up, but the manufacturing and agricultural sectors found it very hard to compete with the petrochemical sector, and they ended up languishing.    Likewise in Canada, the manufacturing and agricultural sectors have experienced a decline.    For example, in the manufacturing sector, 340,000 jobs have been lost in the past 6-8 years.    Not all of that loss is due to the tar sands project, but a good portion of it is.    Investments in the manufacturing sector are declining as well.    The Canadian Real Estate Association or CREA concluded in 2009 that “54 percent of the manufacturing employment loss due to exchange rate develop between 2002 and 2007 are related to a Dutch disease phenomenon.”    Andrew Nikiforuk sees the “hollowing out” of the economy as a process that will only continue unless there is a policy response to counteract it.

Canada has traditionally taken its natural resources, such as fish (like codfish), wood (like white pine), and exported it “raw” without any processing or additional value added.     More than half of the bitumen exported to the United States is raw or unprocessed.   Americans are the ones who turn it into diesel fuel or jet fuel and make most of the profits.    The export of 400,000 barrels of raw bitumen to the United States without further processing is therefore the equivalent of exporting 18,000 jobs to the United States.

5.  Petro Politics

Terry Karl, the political scientist from Stanford University who has studied petrochemical states, said “Petro-states rely on an unsustainable development trajectory fueled by an exhaustible resource–and the very returns produced by this resource form an implacable barrier to change.”    The only democracies in the Middle East, Lebanon and Israel, have no oil; the rest are petrochemical states.   A lot of people in the West see the lack of democracy in the Middle East as stemming from a problem with the culture (Samuel Huntington’s Clash of Civilizations, for example), but Mr. Nikiforuk thinks that the reason lies in the simple fact that the governments have been subverted and distorted by oil revenue, which in turn has been utilized by authoritarian regimes to extend their period of rule.

There are left-wing petro states (Venezuela) and right-wing petro states (Alberta); but the government structure in both places has many parallels.   25% of the revenue of Alberta comes from oil, the same figure as for Libya and Norway.   What do petro states do?    They

  • Lower taxes
  • Overspend revenue
  • Concentrate power
  • Extend long rule

The Alberta premier who ruled for 14 years was referred to by the nickname of “King Ralph.”   Sarah Palin, the governor of Alaska and Vice Presidential Candidate for the 2008 election, was very much in the mold of the ruler of a petro state.    In Mexico, the oil revenue was used by the PRI to extend its rule for 70 years; Muammar al-Qaddafi ruled Libya for 42 years, and the Alberta Progressive Conservative Party ruled for 40 years.    One party rule on the basis of access to oil wealth.

I will continue with part 2 of this post covering risks 6 through 10 one week from today.