4squareviews

2. Processes in the Executing Process Group

Here are the definitions of each of the 8 processes in the Executing Process Group.   Many of these are essentially carrying out the plan that was done in that knowledge area in the Planning Process Group.   The process number refers to the chapter of the PMBOK ® Guide of the knowledge area the process belongs to, followed by the number of the process within that area.   So 9.2 Acquire Project Team is the 2nd process in the HR Knowledge Area covered in Chapter 9 of the PMBOK ® Guide.   The Process Description itself is adapted from the PMBOK ® Guide.

Here’s a little more explanation of these processes.

4.3 Direct and Manage Project Work

In the plan-do-check act cycle, this is the DO part.

8.2. Perform Quality Assurance

The question being answered here is:   are the quality standards appropriate for the project?  The auditing focuses on the quality of the processes themselves and their implementation.

9.2 Acquire Project Team

The first part of executing a project is obtaining the team members from the human resources department.

9.3 Develop Project Team

Here is the process that takes the “team members” and turns them into a team that works together.

9.4 Manage Project Team

This process is where the “continuous improvement” part of the project, where you try to fine-tune the performance of the members of the team as individuals (by measuring their performance by increasing their skills), to reduce conflict between individual team members (through conflict resolution techniques), and for those conflicts that do arise, to create lessons learned to prevent similar conflicts from happening in the future.

10.2 Manage Communications

In executing the project, you will now send  information to stakeholders as planned in the communications plan.

12.2 Conduct Procurements

Here is where the contract is awarded through a bidding or proposal process to the seller that meets the criteria set out in the procurement management plan.

13.3  Manage Stakeholder Engagement

This goes beyond mere communications with stakeholders as is handled in process 10.2 Manage Communiactions; it deals with managing the engagement with stakeholders, handling issues as they arise, etc.

In all of these cases, the process is that of carrying out that which was set forth in the management plan.    Remember that the “triple constraint” knowledge areas of scope, time and cost, and the risk knowledge area, do NOT have executing processes, but all of the other knowledge areas DO have those processes.     Of those knowledge areas that DO have processes, they all have one process each EXCEPT for Human Resources, which has three processes.

This processes usually have the words “direct”, “manage”, and “conduct”, all of which are synonymous with the concept of “execution”, which is appropriate for the Executing Process Group.

The next post deals with the 11 processes in the Monitoring & Controlling Process Group.

Filed under: Uncategorized | Leave a comment »

2. Processes in the Planning Process Group

This chart with its process descriptions actually gives a sufficient explanation of the processes without my having to go into further details, because the purpose is understand the flow of one process to another.    However, I will mention some general trends which will help you memorize that flow.

3.   Trends in Planning Processes

a.  Management Plans

You should look at the processes as you go down the list of knowledge areas and understand why it is that one process comes after another.   For example, it should be clear that the FIRST planning process for each knowledge area is “Plan X Management”, with “X” standing in for the name of the knowledge area.    The output of each of these processes is the “X Management Plan”, which is one of the subsidiary plans that goes into the overall Project Management Plan.    The purpose of each of these subsidiary plans is to provide the policies, procedures and documentation for managing all of the other processes for that knowledge area.

The ONLY exception is the Integration knowledge area called “Develop Project Management Plan,” which has as its output the Project Management Plan I just mentioned.    The Project Management Plan consists of the

• 9 knowledge area subsidiary plans (for all knowledge areas other than Integration)
• 4 additional subsidiary plans (Change Management Plan, Configuration Management Plan, Process Improvement Management Plan, and Requirements Management Plan)
• 3 performance baselines (scope, schedule, cost

As far as the other processes go, they go from estimates to final values, with time duration estimates for the schedule coming before the final schedule model, and cost estimates coming before the final cost baseline.    Identification or definition comes before analysis, so that Define Activities comes before analyzing their order in Sequence Activities, and Identify Risks comes before risk analysis.    Also, qualitative analysis comes before quantitative analysis, so that qualitative risk analysis (is the probability of occurrence and/or the impact on the project low, medium, or high) comes before the quantitative risk analysis (the expected monetary value of each risk).

With these trends in mind, it should be pretty easy to memorize the order within each knowledge area, and with your already having memorize the orders of the knowledge areas, you can piece together all 24 of these processes in not too much time.    THIS IS IMPORTANT for two reasons:

a)   Many questions on the PMP and CAPM certification exams are of the “what happens next?” type.   You need to read the description of where you are NOW in the processes, and then you can look at the 4 possible answers to see what happens next.    If you are able to reproduce the order of the processes, the majority of which are in the Planning Process Group, these questions will go from being  difficult to being relatively easy.

b)  Many questions on the PMP and CAPM certification exams are those asking about the inputs and outputs of processes.   In the Planning Process Group, the outputs of one process are often the inputs of the next process.   So if you want to know the inputs of a process, you can look at the previous process and figure out what the output of that process would be.    Likewise, if you want to know the outputs of a process, you can look at the next process and figure out what the input of that process would be.    These clues often make these types of questions also go from being notoriously difficult to being if not easy, at least doable within a reasonable time frame.

The next post will cover the 8 processes in the Executing Process Group.

Filed under: Uncategorized | 3 Comments »

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

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

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

2.   Tenet #9–Destroy any type of holon, and you will destroy all of the holons above it and none of the holons below it.

The lower level of holon, while having less depth than the higher level (based on tenets #7 and #8), is nonetheless more fundamental for precisely the reason mentioned in the tenet.   If you get rid of the lower level of holon, you are in fact getting rid of the very components of the higher level.

It is very important to remember as a project manager, that despite the significance of all that you do as a manager of the project, and despite the fact that the project charter and your authority has to be sponsored by management, without the team members you would not have a project at all.   They are truly fundamental to the project’s success; that is why you must take care of the members of your team.

This more “nurturing” idea of management seems a far cry from the old “top-down” theories of management that were once espoused in business schools, the “my way or the highway” philosophy of old.    But I was reminded of this reality at a Toastmasters speech contest recently, where the Area Governor had a t-shirt on that said “Servant Leader”.    I asked him, “hey, which one are you, the servant or the leader?”   He replied, “I’m both–in order to lead my team, I have to serve its members.”   With that explanation, I got the concept.

Now, this works at the next level up, a program has more “significance” to a company than a project because it has more depth, meaning that includes the coordination of a series of interrelated projects.    However, the health of a program ultimately depends on what?   The health of the individual projects.    So a program manager has to realize that without the project managers you would not have a program at all.    They are truly fundamental to the program’s success; that is why you must take care of the project managers.

Many managers mistake being significant with being fundamental.    They are more significant to the company than the individual team member, because their work encompasses more of what the company is doing.    However, they are not more fundamental to the company, because if the project is not doing well, they can be replaced as project managers, but the company cannot get rid of all the team members and start the project over.    The new project manager will have to deal with the same team members, the same resources as the old project manager, and must coax out of those same people and resources a success that eluded the previous manager.

This tenet is, therefore, a lesson in humility and a warning against humiliation of any the members of your team for having made mistakes.    Failure is to be seen as an opportunity to learn, not to be cast in terms of blame or moral failing.    By understanding that the team member is more fundamental to the project than you are as the project manager, the more likely you will treat that team member with the respect that he or she deserves.     Once you do so, you will be surprised at how much more engaged that team member will be in the success of the project.

Filed under: Uncategorized | Leave a comment »

1.   Introduction

I am going through the Core Integral program which is an interactive media presentation on the elements of Integral Theory, the synthesizing philosophical framework developed by Ken Wilber.   One of the main ideas is that of learning to see a problem through various perspectives called quadrants, based on the following diagram.

There are two contrasting dimensions to perspective, the interior versus exterior perspective, and the individual versus collective perspective.   If you have the intersection of these two dimensions, you get a total of 4 possibilities of perspectives as seen in the diagram above.

2.   Example:   Climate Change

The Intergovernmental Panel on Climate Change or IPCC is putting out its 5th Assessment or AR5, and there have been a lot of news articles regarding this, mostly favorable to the findings report but there have also been some articles that criticize its findings.    I wanted to understand the issue of climate change better, and I realized that one way to approach it is to show how the various perspectives of Integral Theory could be put to bear on the problem.

a.   Objective (upper-right or “IT” quadrant)

You would think that this is a matter for scientists, since the questions of

• whether the climate is changing
• and if so, to what degree and at what rate it is changing
• and if so, what can we do NOW to prevent those changes

seem to hinge on the relationships between observations and scientific theories.

b.  Interobjective (lower-right or “ITS” quadrant)

Because these scientific questions deal with “global” climate change as opposed to change in any specific area of the globe, any solution to the question would have to involve the world’s governments, and so you must involve this quadrant because that is where systems are found.    Technology is also a system and any technological solution will have its origin here.     Global warming will have an economic impact, and since economics is also a system, this quadrant will come into play regarding questions of “how much will global warming cost the global economy, and how much will it cost the global economy to control it”.

c.  Intersubjective (lower-left or “WE” quadrant)

The real impetus for the contrarian view (the so-called “climate change deniers”) does not seem to be scientific, but political in nature, with the majority of the deniers being funded by conservative think tanks like the Heartland Institute that are funded by those with economic interests in resource-extraction companies, like the Koch brothers in the US, or Lord Lawson in the UK.    Politics, religion, and culture are all “value systems” (as opposed to the systems of physical or social phenomena like in the lower-left quadrant).

If you want to understand those who are supporting the climate change assessment by the IPCC, and those who are denying its conclusions, you will have to confront the politics based on who the stakeholders are, that is, those who be affected by any possible measure to control climate change.

d.  Subjective (upper-right or “I” quadrant)

Where does the “I” quadrant come in?    If you want to convince someone that there is global warming, you will have to take that person’s own personal values into account.    They may derive these from politics, from religion, or culture.   You will have to take that person’s own personal experience into account.   How much do they know of climatology?   Have they had personal experience of any extreme weather events (tornadoes, floods, hurricanes)?    You will have to change your message depending on how much they know about climatology, and you will be able to relate more easily to those who have had a personal experience of an extreme weather event, because it will connect the future of the climate with their present reality, which is the best starting point for a discussion.

In short, I find that the quadrant system developed by Ken Wilber is an excellent way of categorizing and organizing the perspectives that you must take into account when trying to approach a complex problem.    Let’s put it another way:   solving a multi-dimensional problem will take a multi-dimensional solution, and you are more likely to grasp the true outlines of such a solution if you take the various perspectives outlined in Integral Theory into account.

Filed under: Uncategorized | Leave a comment »

1.   Introduction

In the last post, I discussed the process of memorizing the names and the order of the 47 processes, which is easiest done by taking them in groups by knowledge area.   Here are the numbers of processes in each knowledge area and process group.

Once you are able to match the names of all the 47 processes with their position in the matrix via the game with index cards or post-it notes described in the last post, you then must try to come up with the names from memory.    One of the other ways to do this is to memorize the names of the processes and their position in the other direction in the matrix, vertically across the columns for each process group.

2.    Processes in the Initiating Process Group

There are only 2 process groups in the Initiating Process group.    The key word to memorize with 4.1 is the phrase “Project Charter”.    Since this the process that  gives the “green light” from management to the project and gives the project manager the authority to carry out that project with the organization’s resources, it is done even before the planning process.

The key word to memorize with 13.1 is the word “stakeholders”:   identifying them will be key to sorting out the politics of the project, if you will, both internally and externally.    You can have all the resources at your command as the project manager, but your project will fail if it is actively opposed by key stakeholders (such as customers or sponsors), the ones who would have a high degree of interest in the potential outcome of the project and a high degree of influence over its outcome as well.

The Initiating Process Group is the easiest to remember along with the Closing Process Group because there are only two processes in it.    Both processes are thematically linked to the idea of Initiating, with the project charter and identification of stakeholders being the two processes done even BEFORE detailed planning takes place.

The next post after the weekend will cover the 2nd process group, the Planning Process Group, which in contrast is the most complicated series of processes to remember.

Filed under: Uncategorized | Leave a comment »

1.  Introduction–The Ultimate Goal

Ask anyone who has studied for, sat for and passed the PMP or CAPM certification exam, and they will tell you that one of the most challenging categories of questions, besides the technical questions having to do with earned value or network diagrams, are those that ask about the inputs, tools & techniques, and outputs of the 47 different project management processes.    These require not just knowing the names of each of the processes and how they fit into the “matrix” of 10 knowledge areas and 5 process groups, but the very essence of how these processes work.    You can readily memorize the 47 process names and their location in the project management matrix, but in the 5th Edition of the PMBOK® Guide there are a total of 614 inputs, tools & techniques, and outputs for these processes (an increase of 19% from the 4th edition), and there is no realistic way of memorizing all of those.    The good news is that you will not have to actively write down, for any specific process, a list of all of those inputs, tools & techniques, and outputs.    A passive knowledge of being able to recognize on a test from a list of inputs, tools & techniques, and outputs, which ones are part of a given process is the most you will have to do.

However, even this passive knowledge is a tall order to ask of those sitting for the down, and it requires an active knowledge of what the process actually does.    That is why step 5 of the Memorizing the Processes will focus on Tools & Techniques of each process, and step 6 will focus on the Inputs & Outputs.    Knowing what the tools & techniques for each process are will help you figure out what the output of each process is, that is usually not so difficult.    What is more difficult to figure out is all of the inputs that go into a process, but once again, if you understand what the process does, then the “ingredients” or “inputs” that go into that process will be more easily understandable.

2.   Step 4–Gaming the System

One thing that helps you recognize the various Inputs, Tools & Techniques, and Outputs (sometimes collectively referred to as ITTOs) of the processes is not just what each one of them does individually, but how the processes fit together like a jigsaw puzzle.

There are three ways that processes are connected:

• horizontally, across the knowledge areas
• vertically, down the process groups
• crosswise, based on themes (such as “change control”)

The horizontal and vertical connections can be learned systematically, which is the subject of the next series of posts I refer to as Step 4:  Gaming the System.   When I say “Gaming the System,”  I mean literally playing games with cards that help you memorize these horizontal and vertical connections.    When I was a child in the US, there was children’s board game called Chutes & Ladders, probably based on the UK-based children’s board game Snakes & Ladders.    You can be going step-by-step up the board when there is suddenly a surprise connection between one space and some other space in a different location on the board.    Similarly, an output of one knowledge area, rather than being the input of the next process in the same knowledge area (the expected horizontal connection), may instead be the input to some other knowledge area in a different location on the “board” or matrix.    In the same way, an output of one process group, rather than being the input of the next process group (the expected vertical connection), may instead be the input to some previous process group.

These are the exceptions and are important to learn later.   The first thing to tackle, though, are the connections across the knowledge areas.    This will be the subject of this post.

3.   PM Process Card Games

Here’s what you should do to use cards that contain the PM processes to play games that help you learn the connections between processes.

Step 1:   Create the PM Process Matrix

The PM Process Matrix should be on a sheet of paper, 11 x 17, or some other large enough sheet that has room for the five process groups in columns going across and the 10 knowledge areas in rows going down.     If you are doing this exercise as a group, then draw the matrix on a flip chart or some other surface like a blackboard.

Besides the names of the process groups going in vertical columns, and the names of the knowledge areas going in horizontal rows, you should strive to put the “check digits” at the bottom of each column and at the left hand side of each row.   This will be a tremendous aid in figuring out if you have missed any processes, and if so, where those processes are in the matrix.

Step 2.  Create the PM Process Cards

Many PMP Exam prep textbooks, like the one put out by Rita Mulcahy’s cor the one put out by Core Performance Concepts, have in their supplementary materials pre-printed cards with the processes written on them.   However, you can use index cards or post-it notes.   The post-it notes are recommended for group work so that they can be pasted on the flip chart or blackboard, and the  index cards can be placed on the 11 x 17 paper grid.

On one side of the card, put the process name, for example “Develop Project Charter”.   On the back side of the card, write the process number and the name “4.1 Develop Project Charter.”  A list of all of these process names and their location on the PM matrix is found on page 87 of the 5th Edition of the PMBOK® Guide.

The “4.1” numerical designation before “Develop Project Charter” tells you two things:  it gives the Chapter of the PMBOK® Guide that process is found in (chapter 4).   Since Chapter 4 covers the Integration Knowledge Area, it means this process is an Integration Knowledge Area process.    The “1” after the decimal point tells you the number of the process within that knowledge area:   “1” is the first process, “2” is the second process, etc.    The number can only go as high as “7” (the number of processes in the Time Management Area.

Step 3.   Play the PM Process Game–practice with each Knowledge Areas

Take the processes of one knowledge area at a time starting with the six processes of the Integration Knowledge Area.

Shuffle the mini-deck of six cards with the process names with just the name of the process showing (on the front side of the index card or post-it note).     When you see a card, put it on the process group column in the Integration Knowledge Area row where you think it should go.    When all six cards have been placed in what you think the proper order is, check your work by turning the cards over!    When you have done this successfully without any mistakes, go to the next knowledge area.

Step 4.  Play the PM Process Game–now for all 10 Knowledge Areas

When you’re done practicing with all 10 knowledge areas, now shuffle the deck of 47 processes with just the name of the process showing (on the front side of the index card or post-it note).    If you are doing it yourself, you just put the process on the matrix in its correct position until you are done.    Then use the check digits to see if you have the correct number of processes in each row and column.   If you do, congratulations, you have made it through one pass of the PM Process Game!    If you have made a mistake, then use the check digits to figure out where you are missing some processes.    Just knowing this, you can sometimes figure out what the right arrangement should be.    If you can make it 5 times through the PM Process Game without a mistake, you have mastered the game!

Step 5.   Recreate the Matrix from Memory

On the day of the test, you will have 15 minutes (approximately) of time between the time the introductory screen comes on and the test starts.   You should be able within 10 minutes to do the following:

a)   Recreate from memory the matrix on a piece of paper, and put the 47 processes in the matrix in their proper locations

b)   Recreate from memory the most important formulas you may need to complete the problems involving calculations.

This will give you five minutes to read the instructions, take a deep breath, compose your mind and start the test.

To do the first of these, you will need to recreate the entire matrix from memory.    Therefore, without the cards, you should be able to a) draw the matrix on a blank sheet of paper, and then b) fill in that matrix with the 47 processes in their correct positions.

4.  CONCLUSION–Why go through all this?

Once you can go to this next step of recreating the 47 processes from memory, you have accomplished a major goal in preparing for the exam.    Because having the 47 processes in front you in the correct order both in terms of process group (vertically) and knowledge area (horizontally) will allow you to do two things:

1. It will actually help you solve some of the problems on the exam, because many of them give you a situation and ask you “what do you do next?”    If you can identify which processes are in the situation presented to you in the problem then the next thing you do will be the next process.    Yes, you could figure out in your mind, but if the solution presents itself to you visually in the matrix right in front of you, it will less time to figure out the solution.
2. It will help you on the inputs, tools & techniques, and outputs questions, because many times the outputs of one process become the inputs of the next process.    Identify the process, and if the question asks about inputs, look at the name of the previous process for a hint.   Likewise, if the question asks about outputs, look at the name of the following process for a hint.

It’s that simple–and that is why I highly recommend playing the card game mentioned above as a stepping stone to being able to use your own mind as–The Matrix!

The next post will discuss memorizing the processes vertically by Process Group.    This is not hard for the first (Initiating) and last (Closing) process group, because each of these have only 2 processes each.    But the Planning, Executing, and Monitoring & Controlling Group have 24, 8, and 11 and these take more work to memorize.    It is essential that you memorize the Planning Process Group of 24 processes because that is in fact the order in which the processes are done for the most post.

Filed under: Uncategorized | 3 Comments »

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), Communications (chapter 10), Risk (chapter 11), and Procurement (chapter 12).    This post will cover the processes involved in the Stakeholder Management knowledge area, which is covered by chapter 13 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.

2.  Stakeholder Management knowledge area

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

You should notice two things about the distribution of processes among the process groups for the Stakeholdert Management knowledge area.    There is one process in each process group except for the Closing process group, that means one in each of Initiating, Planning, Executing, and Monitoring & Controlling.

In addition, the fact that has a process in the Initiating group is significant; it is the only knowledge area except for the Integration Knowledge Area that has a process in that Initiating Process Group.

The following is a chart that contains a description of the four processes in the Stakeholder Knowledge Area.

Here’s a more detailed description of the processes.

13.1  Identify Stakeholders

This identifies the stakeholders, and does a preliminary analysis of their a) interest and b) influence or level of power with regards to the project.    This determines the general strategy of engagement with the stakeholders:   monitor (i.e., do nothing), keep informed, keep satisfied, or manage closely.

13.2  Plan Stakeholder Management

This goes from the general strategy of engagement to a specific strategy of taking each stakeholder’s current engagement level, which can be one of the following:   unaware, resistant, neutral, supportive, or leading, and influencing that stakeholder until they have the desired engagement level.    This information is put into the Stakeholder Management Plan.

13.3  Manage Stakeholder Engagement

This carries out during the course of the project the general and specific strategies for stakeholder management developed in 13.1 Identify Stakeholders and 13.2 Plan Stakeholder Management.

13. 4  Control Stakeholder Management

This is a Monitoring & Controlling Process group process.    The monitoring part consists of checking up on the relationships with stakeholders and their current engagement level.   If the current level is different than the desired level, then the strategy that had been used up to that point in 13.3 Manage Stakeholder Engagement is reviewed and revised if necessary (this is the controlling part of the process).

Other than the Identify Stakeholders, which has to be memorized as the other process besides 4.1 Develop Project Charter that is in the Initiating Process Group, the other three processes have the words Plan, Manage, and Control, which should make it easy to memorize the process groups they belong to as being the Planning Process Group, the Executing (= Manage) Process Group, and Monitoring & Controlling Process Group.

The next post will discuss ways to practice putting all of the 47 processes in their proper place in the matrix consisting of 5 process groups and 10 knowledge areas.

Filed under: Uncategorized | Leave a comment »

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), Communications (chapter 10), and Risk (chapter 11).    This post will cover the processes involved in the Procurement Management knowledge area, which is covered by chapter 12 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.

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

You should notice two things about the distribution of processes among the process groups for the Procurement Management knowledge area.    There is one process in each process group except for the initiating process group, that means one in each of Planning, Executing, Monitoring & Controlling, and Closing.

In addition, the fact that has a process in the Closing group is significant; it is the only knowledge area except for the Integration Knowledge Area that has a process in that Closing group.

Here’s a chart describing all of the 4 processes, one in each process group (except for the Initiating Process Group).

12.1 Plan Procurement

The Plan Procurement process is a framework for all the procurement processes to follow.    The most important decision that is made as part of this process is the make-or-buy decision, which is where an organization decides whether any procurement are indeed even necessary.    If the company can make all of the components of the product, then it may not need to buy any at all, in which case it will not be necessary to carry out any of the processes 12.2 through 12.4.

If on the other hand the company has to buy components from suppliers, however, then they must be obtained through the procurement process which is outlined in the Procurement Management Plan, the output of the 12.1 Plan Procurement process.   The technical and other criteria for the component are set forth, and potential sellers or suppliers identified (perhaps based on previous projects or through information obtained through industry associations).    A sample procurement contract is usually given as a template and the conflict resolution process is specified in case the supplier is unable to fulfill that contract during the course of the project.

12.2 Conduct Procurement

This process is where the contract is awarded through a bidding or proposal process to the seller that meets the criteria set forth in 12.1 Plan Procurement.

12.3 Administer Procurement

Once the seller has been selected in 12.2 Conduct Procurement, the “monitoring” part of this process confirms that the terms of the contract are fulfilled by the seller and that a good relationship with the seller is maintained.    The “controlling” part of this process occurs when there is some conflict with the seller, and an attempt is made to resolve the conflict through the conflict resolution process, which is specified in 12.1 Plan Project Management.

12.4 Close Procurement

This is the only project management process that is in the Closing Process Group other than 4.6 Close Project or Phase under the Integration Management knowledge area.    The work that the seller has done and the deliverables that the seller produces to help complete the project are verified as acceptable by the buyer, and the buyer then formally signs off on the completion of the procurement contract, which together with the conclusion of the financial reporting requirements brings the procurement to formal closure.

The reason why this knowledge area has a process in the Closing Process Group is because from the standpoint of the supplier, the procurement is in essence a project unto itself.   Like the overall project the buyer is undertaking, it starts out with the seed of a “statement of work” or “SOW”; in the case of the procurement, it is a “Procurement SOW”.    And like the overall project the buyer is understaking, it ends with a formal closure which requires the deliverables to be verified.   In the case of the procurement, the buyer does the validating of the final deliverable from the supplier, and in the case of the overall project, the customer or the sponsor does the validating of the final deliverable from the organization (the “buyer” in the procurement relationship).

If I were running the PMI, I would have put Stakeholder Management as chapter 11 right after Communications Management in Chapter 10, and moved the other chapters (Risk and Procurement) to be chapters 12 and 13.   Why do I think this?   Because Stakeholder Management is to a large extent based on Communications Management, and in fact is an outgrowth of that knowledge area.    However, it is conceptually related to Risk Management, as the following post discusses

https://4squareviews.com/2013/09/13/the-relationship-between-risk-management-and-stakeholder-management/

But since I am not running PMI, I accept their decision to tack Stakeholder Management on as the last chapter, chapter 13.   The processes in the Stakeholder Management knowledge area are the subject of the next post.

Filed under: Uncategorized | Leave a comment »

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.

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.

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.

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.

Filed under: Uncategorized | Leave a comment »

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:

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.

Filed under: Uncategorized | Leave a comment »