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.

Putting on a Toastmasters Area Speech Contest–5 Lessons Learned


I just finished being a Contest Master for the Fall Speech Contest being held at the Area level of Toastmasters International.  The Fall Speech Contest has four levels, club –> area –> division –> district, and the Area level is therefore the second level.

Besides being the The contest went fairly well, but I wanted to write down 5 lessons learned so that the contest next Spring will go more smoothly.

1.   Start Planning Early

If the District contest takes place by April 26, then counting back one month you have the Division contests ending on April 11, the Area contests ending on March 15, and the Club contests ending in February.    In this round of contests, I started planning for the Area contest one month ahead in February.    However, you really should start planning for judges when the Toastmasters Leadership Institutes begin in December.   Why is that?   Because the Judges Training is given along with the Club Officer Training.    You can remind those club officers that they should also get Judges Training while they are at the TLI conferences.    If it is February and you realize “we need qualified judges”, it may be too late because the club officers may have already received their club officer training and may not be willing to go to another TLI just to get Judges Training.   The more club officers you have trained as judges, the more you can then supply neighboring Area Contests with judges.    And then when it comes time for YOUR area contest, you will have a lot more cooperation in getting judges.

2.   Use the Rifle, not the Shotgun

Now I’m not talking about open carry laws in the Toastmaster Club; I’m referring to how you ask people to volunteer to be a contestant, or to perform one of the support roles.    If you ask at a club meeting and use the shotgun approach to say, “any volunteers?”, the response will be minimal.   You may rename yourself the “club dentist,” because getting volunteers for speech contests will seem like pulling teeth.

But if you go to individuals and say, “hey, you’re really good at doing these kind of speeches (or doing these kind of roles).   I was thinking that you would be a good person to have at our contest to do X.”   When you thrust somebody in a role outside of their comfort zone, especially in front of others, you are going to face passive resistance.   But when you first GROUND them by recognizing their strengths, you can then STRETCH them into the role by taking those recognized strengths and applying them to the contest.

3.  Lateral Cooperation

The Division Governor should be willing to help you out at your Area Contest, of course.   But you need to get cooperation from other Areas in the same Division.    You can approach the Division Governor but it is best to forge relationships with other Area Governors.    Why?   Because you can take the qualified judges in your area and have them be judges in the other areas, while the other areas reciprocate.    We had a problem with that in this round of contests, but what the Area Governor and I (the Assistant Area Governor) have done is we have gone and taken the first step by volunteering to help in the other contests.   That starts with getting club officers trained and willing to be judges in their contests.  Once we help out other Area Governors with their contests, they are more willing to step up to the plate and help you with yours.

4.  Vertical Cooperation

As I mentioned, the Division Governor should be willing to help out at the Area Contest, which is to be expected.   But going in the other direction, you should get cooperation from your own Area.   Use the “rifle” or targeted approach to get members to help out at a contest.    How do you get people to do that?   First, when your own club has people in the contest as contestants, ask people in your club to go as “cheerleaders” for your fellow team members.    Many who are shy about being in the contestant will want to at least help out the others who are brave enough to compete.   Once they go to a contest, they usually have a good time, and these are the people I target for the next contest to help out as timers, counters, or even helping out with refreshments, set-up or clean-up.

5.  Encouraging Words

If someone enters a contest, they need to be given praise just for having taken that step.    They may work hard on a speech, only to get 3rd place.    They will naturally be disappointed.    They may be disappointed to the point of saying, “what’s the use?”   So talk to the winners and congratulate them, but tell the others to that they are, in your eyes, winners as well for having taken the brave step of being in a contest.

As I mentioned today at the contest at the beginning of the contest, we should be in a contest not to beat the other contestants, but to beat our own weaknesses.   If you go to a gym, and you are stronger at doing a certain exercise than everybody in the gym on that day, what health benefit do you gain from that fact?   NOT A SINGLE ONE!    You only gain a health benefit by being better than you were the last time you were in the gym.   Similarly, you do not get better at speaking by being chosen as the winner in a speech contest.    You get better at speaking by entering a speech contest and doing the practice it takes to be the winner.

At the end of the contest, after all the trophies were given, I made it a point to ask for the audience to applaud for everybody, because as I said, “all are winners for having had the courage to become better speakers, and they all have accomplished that!”

These are just five points I think that, if followed in future contests, will make the Area contest even more successful than it was this time around.   

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


1.   Introduction

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

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

Let’s take the Scope Management Processes first.

Here’s the portion of the above matrix of 47 processes that lists the processes in the Integration Management knowledge area, which is chapter 4 of the PMBOK® Guide.

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

6

4

2

Here’s a description of the six processes that are included in the Scope Knowledge Area.

Process Group Process Number Process Name Process Description
Planning 5.1. Plan Scope Management Creates a Scope Management Plan that documents how the project scope will be defined, validated, and controlled.
5.2 Collect Requirements Defines and documents stakeholders’ needs to meet the project objectives.
5.3 Define Scope Developing a detailed description of the project and product.
5.4 Create WBS Subdivides project deliverables and project work into smaller, more manageable components.
Monitoring & Controlling 5.5 Verify Scope Formalizing acceptance of the project deliverables with the customer.
5.6 Control Scope Monitoring status of the project and product scope and managing changes to the scope baseline.

Let’s take a closer look at the process descriptions.    Recall that the first four processes are in the planning process group and the last two are in the monitoring & controlling process group.

5.1  Plan Scope Management

The first planning process for ALL of the knowledge areas is going to be in the form Plan X Management, where X is the name of the knowledge area.   The object of this planning process is to produce the planning document for that knowledge area, which is going to be called X Management Plan, again where X is the name of the knowledge area.    In this case, with Scope being the relevant knowledge area, the name of the first planning process is Plan Scope Management.

The main output of the process, the Scope Management Plan, is a guideline or blueprint if you will for all of the other processes, whether they are in the planning group or the monitoring & controlling process group.    The other output of the process, another subsidiary plan called the Requirements Management Plan, is what is going to be filled in during the next process, 5.2 Collect Requirements.

5.2 Collect Requirements

This is the first time the scope is broken down from the high-level requirements that are included in the project charter (the output of process 4.1 Develop Project Charter) into more detailed requirements.    This process coordinates with the knowledge area of Stakeholder Management, because the detailed requirements are going to come from the various stakeholders.

The main question answered by this process:    What do the stakeholders want from the project?

This is like asking somebody who wants to go on a trip the kind of place they want to go to.    What are their requirements for their trip?

5.3 Define Scope

The purpose of this process is to create the project scope statement, which further defines the scope from the requirements that are the output of the previous process and turns it into a list of objectives, major deliverables, and a list of assumptions and constraints that give an idea of the potential risks to the project and what is consciously excluded from the project.

Main question answered by this process:     How do you get the project done?

Using the previous analogy of somebody going on a trip, once you know their requirements for their trip, you then pick a specific destination which fits those requirements.

5.4 Create WBS

The previous process of “Define Scope” gives the final objectives or major deliverables of the project, but this process breaks things down all the way to the level of specific deliverables, in something called the Work Breakdown Structure or WBS.

The output of this process is the “scope baseline” which consists of three things:   a) the project scope statement (the output of the last process), b) the WBS (mentioned above), which indicates the work that has to be done, and c) the WBS dictionary, which gives details about the work to be done (where, who, etc.).

Main question answered by this process:   What are the specific steps you will need to do in order to get the project done?

Extending the previous analogy of somebody going on a trip, once you know the destination, your GPS system (analogous to the WBS of your project) will give you the specific directions like “go straight 2.0 miles”, “turn left here”, etc. that, if followed, will get you to your destination.

All three of the above processes are part of planning, but they go from general to specific in terms of the level of detail.   Now let’s discuss the two processes in the Monitoring & Control group.

5.5 Validate Scope

Validating the scope means taking completed project deliverables and asking the customer or sponsor to give their formal acceptance of them to make sure that they conforms to their expectations.

NOTE:   This used to be called “verify” scope in the 4th edition; but it still refers to the same process of gaining formal acceptance.    Also, the final, formal acceptance of the project is not done here, but in the 4.6 Close Project or Phase process.

5.6 Control Scope

Control scope means to monitor the status of the project and product scope to see whether the project is proceeding according to plan.   What happens if the scope is deviating from what was in the plan?  Then changes are suggested to either a) have the project conform to the original plan or, if the original plan is judged to be unrealistic to b) have the plan adjusted accordingly.

In both of these processes, the actual scope is being compared with some standard; in the case of Validate Scope it is being compared with the customer’s expectations, and in the case of Control Scope it is being compared with the scope baseline.

The next post deals with the Time Knowledge Area.

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


1.   Introduction

In the last post, I showed how you can use logic and the memorizing of some key numbers to memorize the pattern of where the 47 process groups go in the matrix formed by the 5 process groups and 10 knowledge areas.   This is the result that shows how many processes go in which of the 5 process groups and 10 knowledge areas.

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

 

Of course, this just tells you WHERE the processes go. The next step of learning the processes is learning the NAME of the processes.

2.  Integration Management knowledge area

Let’s take the Integration Management Processes first.

Here’s the portion of the above matrix of 47 processes that lists the processes in the Integration Management knowledge area, which is chapter 4 of the PMBOK® Guide.

Knowledge Area

Total # of Processes Initiating Planning Executing Monitoring & Controlling

Closing

Integration

6

1 1 1

2

1

Now, here is a chart that contains a list of the six processes, with their process numbers which have a) the chapter of the Guide where they are find (the Integration Knowledge area is chapter 4) followed after the period by the number from 1 to 6 which shows the order in which they are found.    The process name and a summary process description are also given.

ProcessGroup ProcessNumber Process
Name
Process Description
Initiating 4.1 Develop Project Charter Develops document that formally authorizes project and provides project manager with authority to apply organizational resources to project activities.
Planning 4.2 Develop Project Management Plan Defines, prepares, and coordinates all subsidiary plans and baselines (from all 9 other knowledge areas) and integrates them into a comprehensive project management plan.
Executing 4.3 Direct and Manage Project Work Leads and performs work defined in project management plan and implements approved changes to achieve the project’s objectives.

Monitoring

& Controlling

4.4

Monitor and Control Project Work Tracks, reviews, and reports project progress against performance  objectives defined in project management plan.
4.5 Perform Integrated Change Control Reviews change requests; approves changes and manages changes to deliverables, OPAs, or project management plan itself; communicates their disposition
Closing 4.6 Close Project or Phase Finalizes project across all PM process groups; formally closes project or phase

Let’s take a closer look at the process descriptions.

4.1 Develop Project Charter

The Project Charter is the formal “green light” to the project and is done as part of the initiating process. Just think of “green light” and “go.” It’s the high-level statement of what the objectives of the project are.    Since it is the formal start to the project, it is therefore easy to see that it is in the “initiating” process group.    It is only one out of 2 processes that start even before detailed level planning.

4.2 Develop Project Management Plan

The output of this process is the Project Management Plan.   It is not a single plan, but is actually the “mother of all plans”, meaning it combines a) the individual plans for each of the 10 knowledge areas, b) the performance baseline (the scope, time, and cost baselines), plus c) 4 more subsidiary plans (change management, configuration management, process improvement management, and requirements management), and integrates them all into one interlocking master plan.

Since it has the word “plan” in it, this is the clue to you that it is in the planning process group.

4.3 Direct and Manage Project Work

What’s in the plan that comes out of process 4.2 Plan Project Management gets DONE here.   Remember the plan-do-check-act cycle? This is the DO part.    That’s why it is in the “executing” process group.

4.4 Monitor and Control Project Work

This is the “check” part of the “plan-do-check-act” cycle.   It is easy to memorize that this is in the “monitoring & controlling” process group, because the words “monitor” and “control” are part of its title.

4.5 Perform Integrated Change Control

In the last process 4.4 Monitor and Control Project Work, if you monitor the project work and you see there is a need for a correction, then you must control the project to get “back on track” by making a change request.    This process 4.5 Perform Integrated Change Control  is where the change request is evaluated by analyzing what impact the requested change (usually in the “scope” of the project) will have on the other constraints of the project (such as “time”, “cost”, or “quality”).   Then the decision to accept or reject the requested change is made according to the Change Management Plan.

There are two possible types of changes, a) one that changes what the project work is in order to accommodate the schedule and/or budget, or b) if that schedule and/or budget is now seen to be unrealistic, you may have to change those in order to accommodate the new reality of the project work.    If a change to the project work is accepted, you go and “integrate” that change by looping back through the 4.3 Direct and Manage Project Work process.    If a change to the project schedule and/or budget is accepted, you change the appropriate parts of the Project Management Plan.

This process also has the word “control” in it, so it is easy to see why it is the Monitoring & Controlling process group.   You can see why it follows the only other process to be in that group, 4.4 Monitor and Control Project Work, because you can’t make a change in the project unless you first monitor it to see whether it needs changing in the first place.

4.6 Close Project or Phase

If the project does proceed to the point where the deliverables of the project are completed as specified by the plan developed in process 4.2 Develop Project Management Plan, then you get formal closure of the project or phase from the customer and/or sponsor of the project.    This process shares the word “formal” in common with the first process 4.1.   Since it has the word “close” in the process name, it is easy to see why it is in the closing process group.

If you look at the definitions of the processes and see how they are related, then it is easier to memorize the process names and their order.     Just remember that it is the only knowledge area to have processes in each of the 5 process groups.    Only the Monitoring & Controlling process group gets 2 of the processes; all of the others have 1 process each.    That is why there are a total of 6 processes in this knowledge area.

Tomorrow I go through the Scope Management Knowledge Area processes.

5th Edition PMBOK Guide–Memorizing the Processes Step 3: The PM Matrix



The first two steps assist you in memorizing with the use of logic the 5 process groups and 10 knowledge areas. Now you are ready for step 3 … The Matrix!

What this means is actually memorizing the positions of the 47 processes of project management among both a) the process groups and b) the knowledge areas.

Step 1. Let’s draw a chart or a matrix with the process groups written along the columns at the top, and the knowledge areas written along the rows to the left.

Initiating Planning Executing Monitoring & Controlling Closing
Integration
Scope
Time
Cost
Quality
Human Resources
Communications
Risk
Procurements
Stakeholder

In filling out the schematic, an X means that it is filled with one of the 47 processes. If the area is white, this means that there are no process groups in the intersection of that process group and the knowledge area.

Step 2.

Initiating Planning Executing Monitoring & Controlling Closing
Integration

 X

 X X  X

 X

Scope
Time
Cost
Quality
Human Resources
Communications
Risk
Procurements
Stakeholders

Going across, integration is the knowledge area which binds all of the other knowledge areas together so it has processes across in all five process groups. That is why the gray goes all across the integration knowledge area row.

Step 3.

Initiating Planning Executing Monitoring & Controlling Closing
Integration

 X

X      X               X

 X

Scope     X
Time     X
Cost     X
Quality     X
Human Resources     X
Communications     X
Risk     X
Procurements     X
Stakeholder     X

Going down, planning is the process group which covers every knowledge area, because the scope management plan includes the management plan of every knowledge area. That is why the gray goes all the way down the planning process group column.

This gives you the a) row (integration knowledge area) and b) column (planning process group) that cut across the entire chart. Consider it the major spine of the matrix. From here, it is easiest to memorize the pattern going downwards.

Step 4.

Initiating Planning Executing Monitoring & Controlling Closing
Integration     X    X      X                 X  X
Scope    X                 X
Time    X                 X
Cost    X                 X
Quality    X                 X
Human Resources    X
Communications    X                 X
Risk    X                 X
Procurements    X                 X
Stakeholder    X                 X

The next largest group going downwards is in the monitoring & controlling process group, which is the process group that does the “check” and “act” portions of the iterative plan-do-check-act loop. It covers every knowledge area EXCEPT human resources; the way we remembered this in our group is that someone has to be DOING the monitoring and controlling, and that person is assigned through—human resources. So adding this column we get the above result.

Step 5.

Initiating Planning Executing Monitoring & Controlling Closing
Integration     X     X     X                  X  X
Scope     X                  X
Time     X                  X
Cost     X                  X
Quality     X     X                  X
Human Resources     X     X
Communications     X     X                  X
Risk     X                  X
Procurements     X     X                  X
Stakeholder     X     X                  X

Next we take the “executing” column. Here we skip, after integration, the “scope-time-cost” trio of the traditional “iron triangle” of constraints, and we also skip “risk”, which we remembered in our group by thinking “why would you want to execute something risky?” That gives you the almost-final schematic.

Step 6.

Initiating Planning Executing Monitoring & Controlling Closing
Integration     X     X      X                 X  X
Scope     X                 X
Time     X                 X
Cost     X                 X
Quality     X      X                 X
Human Resources     X      X
Communications     X      X                 X
Risk     X                 X
Procurements     X      X                 X  X
Stakeholder     X     X      X                 X

In the initiating and closing process groups, the two “bookends” of our set of 5 process groups, there are only 2 knowledge areas involved. Of course “integration” is one of them, which we know by the rule stated in step 1.

In the case of initiating, the other knowledge group involved other than “integration” is “stakeholders”, because you have to identify the stakeholders before you start doing detailed planning; you need to communicate with the stakeholders to see if the project can even get the “green light” to go forward.

In the case of closing, you would expect to see a “formality” to the procedure, and this is especially true with contracts, which are formal, legal documents. Contracts are involved in a project if there are procurements or supplies that you get from an outside company. So besides integration, closing involves the “procurements” knowledge area.

That’s the complete pattern! Congratulations. Now we go on to the next steps, which are figuring out HOW MANY groups go into which box that has an X. If it’s a white box, of course, the answer is ZERO.

Step 7.

Initiating Planning Executing Monitoring & Controlling Closing
Integration 6
Scope 6
Time 7
Cost 4
Quality 3
Human Resources 4
Communications 3
Risk 6
Procurements 4
Stakeholder 4
 47

2

24

8

11

2

Draw an extra row to the left of the matrix and an extra column at the bottom.

Here’s how to memorize the numbers going across at the bottom.

a. First put a 2 in the first (leftmost) and fifth (rightmost) column.

b. For the number in the second column, take the 2 in the first column, and multiply it times the sum of the first 2 numbers in the rows, 6 + 6 = 12, to get 2 x 12 = 24.

c. For the number in the third column, take the sum of the last 2 numbers in the rows, to get 4 + 4 = 8.

d. For the number in the fourth column, this is simply a matter of taking the total 47, and subtracting the other columns and getting the remainder, 47 – (2 + 24 + 8 + 2) = 47 – 36 = 11.

Check your numbers by seeing that they add up to 47.

Here’s how to memorize the numbers going across at the left.

The first three numbers are like a telephone area code, 667, with the first and second digits the same, and the third one equaling 7, the last number of the total number of processes, 47.

The fourth through seventh numbers are 4, 3, 4, 3, which is a sequence that adds up 7, the third number, repeated twice.

The eighth number is 6, 2 times the seventh number.

The remaining number of processes not accounted for, if you take 47 processes minus the number of processes listed in the first through eighth numbers, is 8 processes.  If you divide these in half, you get 4 processes in each of the ninth and 10 numbers.

The whole purpose of these check digits are so that, when you are doing the brain dump and you write down the processes, you can check whether you’ve put them in the right column (i.e., under the right process group) and in the right row (i.e., next to the right knowledge area).

Step 8.

Just remember the place of three digits for the number of processes, and the rest of the logic puzzle is simple to complete.

a. Remember that under Monitoring & Controlling process group, the first two knowledge areas have 2 processes n them; all the others in that row have only 1 process.

b. Remember that under the Planning process group, the knowledge areas that deals with handling PEOPLE, human resources, has 1 process.

Initiating Planning Executing Monitoring & Controlling Closing
Integration 6      X      X       X

2

    X
Scope 6      X

2

Time 7      X                 1
Cost 4      X                 1
Quality 3      X      X                 1
Human Resources 4

1

     X
Communications 3      X      X                 1
Risk 6      X                 1
Procurements 4      X      X                 1     X
Stakeholder 4      X      X      X                 1
47

2

24

8

11

2

Using just those 4 numbers, you can use the check digits to the left of each row and at the bottom of each column to logically conclude that the number of process groups in each cell is the following:

Step 8.

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

If you need a step-by-step set of instructions how to figure that little logic puzzle, send me a comment and I’ll spell it out in detail.

Once you have done this logic puzzle, you can see for yourself that the number of processes for each process group show certain regular patterns, and knowing the check digits on the bottom and the left can help you when you are memorizing the names of the processes.    What will happen is that you will memorize, let’s say, 90% of the names of the processes, but you’ll be missing about 4 or 5 of them.    If you know the pattern listed above, you will remember exactly WHERE on the matrix the missing processes should go, which often times is half the battle of remembering what the process names are.

In the following post, I will start the next step which is memorizing the names of the processes, knowledge area by knowledge area.

5th Edition PMBOK® Guide–Memorizing the Processes (Step 1 and 2)


Now that I have completed a review of every single chapter of the PMBOK® Guide, my next project is to write some posts on memorizing the 47 project management processes, including which process group and knowledge area they belong to, how they flow from one to the other, and the inputs, tools & techniques, and outputs that belong to each process.   That is a a big undertaking, but it is essential if you want to understand the interaction between processes, and as a practical matter, if you want to pass the PMP or CAPM certification exam.

The first two steps you need to in order to memorize the 47 processes of project management in the 5th Edition of  the PMBOK® Guide is to be aware of which process group and knowledge area they belong to.

Step 1: Memorizing the Process Groups

The process groups are:

  1. Initiating
  2. Planning
  3. Executing
  4. Monitoring & Controlling
  5. Closing

In class we learned cute mnemonic devices such as “In Projects, Every Monkey Counts Coconuts” to memorize the order, but in our study group, we wanted to go beyond such short-term memory tricks in order to gain a real understanding of WHY these are in the order they are in.

Of course, the Plan-Do-Check-Act cycle people are familiar with can be transferred to understanding the order of process groups 2, 3, and 4, like so:

Then process groups 1 and 5 are the “book ends” to this iterative cycle, and the sequence is now complete.

Step 2: Memorizing the Knowledge Areas

There are `0 knowledge areas, and these correspond to chapters 4 through 13 in the PMBOK® Guide. These are:

Chapter 4.     Project Integration Management

Chapter 5.     Project Scope Management

Chapter 6.    Project Time Management

Chapter 7.     Project Cost Management

Chapter 8.     Project Quality Management

Chapter 9.     Project Human Resources Management

Chapter 10.    Project Communications Management

Chapter 11.    Project Risk Management

Chapter 12.    Project Procurement Management

Chapter 13.    Stakeholder Management

The first one, integration, goes first because it integrates all of the other management areas from scope through procurement that come in later chapters.

The next four are actually part of the “iron triangle of constraints”, the original form of the concept of constraints as formulated by Dr. Martin Barnes in 1969.

If you think of the “scope” as one of the first things you describe in a “scope statement” and then detail in the “scope management plan”, then that makes sense that it is next (after integration).

Then time, cost, and quality are the natural successors to this according to the triangle if you go clockwise around the diagram above.   (Dr. Martin Barnes had “output” as a key constraint, which to him was a combination of “scope” and “quality”.)

So, next after scope, time, cost, and quality, you have to have somebody to do the work, and then a means for them to talk to one another. So that gives you the next two, Human Resources Management and Communications Management. And why do you want to communicate?   Well, one thing you want to communicate is if something could go wrong on the project.   That something is called a “risk”, so that’s why Risk Management is the next one in the list.

You have to have all the components to put together on your project, so procuring all those components gives you the next area of Procurement Management.

The last chapter, Stakeholder Management, was added in the 5th Edition of the PMBOK® Guide, so that is why it ended up as Chapter 13.   But if I were re-organizing the Guide, I would put Stakeholder Management as the chapter after Communications Management and before Risk Management.    Why?   Because Stakeholder Management used to be part of Communications Management, but PMI felt that it is important not just to passively communicate with the stakeholders, but to actively engage them throughout the course of the project.

And Stakeholder Management is related to Risk Management as well, because stakeholders can positively or negatively affect a project in the same way that risks can positively or negatively affect a project.   In one case you are dealing with people, and in the other case you are dealing with events, but BOTH have to be managed effectively in order to ensure the success of the project.

If you stick to a logical framework that puts the 10 chapters together in a narrative like this, you will find yourself being able to memorize the knowledge areas without too much trouble in a way that makes logical sense rather than relying on the caprices of short-term memory.

Tomorrow, we put these 5 process groups and 10 knowledge areas together, and we draw:  THE MATRIX!