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!

Integral Theory and Project Management—tenet #6


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

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

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.

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

This tenet is a little abstract, but putting it in the context of project management will illustrate it so that it is more intuitive.  As a project manager, you have members of your project team.  You are the higher level of holon, and the team members are the lower level.  What you can accomplish is limited absolutely by the abilities of team members and the resources available to them.  So it is vital as a project manager that you make sure that the team members have the resources they need, and then that they have the abilities to use those resources to get their jobs done.  If the resources run out, then no matter how talented your team members are, they won’t be able to accomplish their jobs on the project.  If they have the resources, and yet don’t have sufficient training to be able to utilize them, they won’t be able to accomplish their jobs on the project.  They have to these minimums in order to proceed.  This is an illustration of the first part of the tenet that the lower sets the possibilities of the higher.  It tells you what is necessary for your project team to succeed.

Now let’s say that they have the minimum requirements to do their job.  They have the possibility of getting it done now.  But how well they do it, and with what attitude they do it, is affected by the leadership of the project manager.  As the project manager, your leadership supplies more than what is necessary, but also what is sufficient for them succeed.  In The 21 Irrefutable Laws of Leadership by John Maxwell, the very first law is “The Law of the Lid”, which says Leadership ability is the lid that determines a person’s level of effectiveness.  You can give them the tools of the job so that they can do it, but you can help bring out their best, in other words, have them be more effective, by the example of your own effective leadership.

This tenet is important in that it shows that what a project manager can accomplish is limited by those on the project team, but the project manager can boost what the project team actually accomplishes through leadership.

The next post will cover tenet #7.

Science and Religion—5 Models of Interaction: a talk at Common Ground


On Wednesday, September 11th, Jim Kenney, one of the co-founders of Common Ground, a group devoted to interfaith dialogue, went to one of the “satellite campuses” of Common Ground in Flossmoor IL to put on a two-hour version of a talk on the various models by which the interaction between science and religion have been characterized.  This post is a summary of this talk.

1.  Science and Religion as Enemies

In this model, called conflict theory, science and religion are locked in mortal combat, and there can only be one winner and one loser.   In game theory, a conflict in which there is only the possibility of a winner and loser is called a zero-sum game.  A non-zero-sum game would be one that admits the possibility of both sides coming out winning.  Robert Wright has written a book on the history of the ethical evolution of mankind called Nonzero:  The Logic of Human Destiny, in which he posits the claim that the history of ethics is a gradual shift from zero-sum games to non-zero sum games.

In 1875, the President of the French Academy of Sciences predicted that the success of science in answering all of the remaining questions would be total by 1925, and that success would be concomitant with the eclipse of religion to the point where it would totally disappear by that same date.

That prediction was so wildly optimistic as to be laughable now, but note that the total success of science automatically implied to the scientists at the time the total annihilation of religion.

2.  Science and Religion as Strangers

Stephen J. Gould, the contentious but brilliant evolutionary biologist, conceived of the idea that science and religion were nonoverlapping magisteria, where a magisterium is understood to be an “area of expertise or authority.”  Science has one area of expertise, and religion has another.  And never the twain shall meet, according to this model.

3.  Science and Religion as Neighbors

When a stranger comes to live next to you, he or she is gradually considered a neighbor.  And like neighbors, they became acquaintances with whom you may have some things in common.  In the case of religion and science, according to physicists Charles Coulson and Harold Schilling, the methods of science and religion have much in common.  They both require critical reflection, and have a threefold structure of

  • Experience
  • Theoretical Interpretation
  • Practical Application

They also evolve not by the mere collecting of facts, but by advances of creative imagination, which Thomas Kuhn in his book The Structure of Scientific Revolutions called “paradigm shifts.”

However, there can be misunderstandings between neighbors, and one of the misunderstandings between religion and science is the confusion of mythos and logos, or between narrative and logic.  A polemical atheist like Richard Dawkins thinks that religion is to be decried when it can’t handle facts which contradict a certain narrative as set forth in some so-called sacred text.

Another difference between science and religion is that science is descriptive in describing what is and religion is prescriptive in describing what should be.  When religion tries to describe what is, or when science tries to dictate what should be, then there is increased possibility of misunderstanding.

4.  Science and Religion as Allies

There may be differences between allies, but the fact that they both face a common enemy should cause them to focus on their similarities rather than their differences, and to see the areas where they can most fruitfully cooperate.

The enemy of science and religion would be common problems faced by all humanity, the most prominent of which is the threat of the effects of climate change.

The International Society for Religion and Science or ISSR in the UK (www.issr.org.uk), formed in 2002, and the Center for the Study of Science and Religion at Columbia University, are two examples of recent efforts to bring together leading figures in both science and religion to foster mutual understanding and collaboration.  One good example of that collaboration is The Universe Story, written by the cosmologist Brian Swimme and the theologian Father Thomas Berry.  By being able to combine the facts of cosmic evolution with a compelling narrative, the two of them can give a picture of humanity’s place in the evolution of the cosmos which is only enhanced by the respectful interaction between religion and science.

5.  Science and Religion as Relatives

The reason why science and religion have differences and yet evolve along certain similar lines is because they are related.  How they are related is illuminated by Ken Wilber’s Integral Theory, in which reality can be looked at across two separate dimensions:

  • Interior experiences vs. exterior observations
  • Individual perspectives vs. collective perspectives

These combine to form four quadrants or perspectives as follows:

  • Upper-left quadrant—“I” perspective, intentional
  • Upper-left quadrant—“it” perspective, behavioral
  • Lower-left quadrant—“we” perspective, cultural
  • Lower-right quadrant—“they” perspective, social

In this perspective, science belongs to the “it” perspective, an individual’s spirituality belongs to the “I” perspective, religion belongs to the “we” perspective, and the culture belongs to the “they” perspective.  These perspectives are different and that is why religion and science are different approaches, because they belong to different quadrants which look at the same reality in fundamentally different ways.

However, despite the fundamental difference, just like relatives, they share some fundamental similarities or ontological DNA through the fact that their evolution obeys the same laws.  And that is why there can be communication between them.

The meta-perspective brought by Integral Theory makes sense of the 4 other models that have been referred to, and that is why Jim Kenney respectfully referred to Ken Wilber as the “most important living philosopher whom you’ve probably never heard of.”

If you are interested in hearing more about this topic, Jim Kenney is giving a three-part workshop to be held from 9:30-11:30 AM on September 25, October 2, and October 9 at the “main campus” of Common Ground in Deerfield, IL at 815 Rosemary Terrace, Deerfield, IL  60015.  For more information go the following link:

http://www.cg.org/Calendar/Workshops/Wednesday-Mornings/Science-and-Religion%E2%80%94Strangers,-Antagonists,-or-Al.aspx

 

The Relationship between Risk Management and Stakeholder Management


1.   Introduction

I have the pleasure of working with Mark Wilson from the Dale Carnegie Institute in Chicago, who is preparing for a presentation to be given by the PMI-Chicagoland chapter’s Professional Development Day event on November 1st.    As we were discussing his proposal for a presentation, we were talking about the general analysis of stakeholders into four main categories based on the combination of two variables, a) their interest in the project, and b) their power or influence on the project.    This analysis is done as part of the first stakeholder management process 13.1 Identify Stakeholders after all the stakeholders have been identified.    Here are the four possibilities that emerge from this analysis:

This is a very gross simplification of these four strategies, but you can get the general picture from the diagram above.   When Mark looked at that, he said the diagram reminded him of the diagram which analyzes the four main risk response strategies, something that is done in the process 11.3 Perform Qualitative Risk Analysis.

There the analysis is done based on, again, the intersection of two variables, but there the variables are a) probability of an event occurring, and b) the impact of the event when it occurs.    Now that event can have a positive (+) or a negative (-) impact, in which case the strategies are diametrically opposite.   For example, if the probability is high and the impact is high, you want to avoid it if it’s going to have a negative impact, but you want to exploit it if it’s going to have a positive impact.

Here’s a matrix which outlines the four strategies based on these two variables.

Probability Impact Strategy (-) Strategy (+)
High High Avoid Exploit
Low High Transfer Share
High Low Mitigate Enhance
Low Low Accept Accept

This observation of Mark Wilson’s, that the structure of the analysis of risk response strategies and stakeholder engagement strategies are similar, made me think, is there any deeper structural connection between risk management and stakeholder management?     That is the subject of this post.

2.  Similarities in objectives

One of the ways to see the structural links between risk management and stakeholder management is to look at the definitions based on the PMBOK Guide.    The definition of risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.   The definition of a stakeholder is an individual, group, or organization who may [positively or negatively] affect, or be affected by, the outcome of a project.    I confess that I added the phrase “positively or negatively” to make it clear that the definitions are parallel.   In the case of risk, therefore, an event may affect the project either positively or negatively; in the case of a stakeholder, a person may affect the project either positively or negatively.

But if you are concerned about the outcome of your project, you need to be concerned about BOTH of these possible impacts on your project.    Now people are not things or events, and you need to approach them differently.   For example, you cannot “avoid” or “transfer” a stakeholder that has a potentially negative impact on your project in the same way you could handle a risk that has a potentially negative impact on your project.    But you could draw parallels with some of the other risk response strategies and stakeholder engagement strategies, like that of mitigating negative risks/stakeholders or enhancing positive risks/stakeholders.

3.  Similarities in management approach

The project management institute, in the last edition of the PMBOK Guide, seems to trying to change the paradigm of project managers from dealing with risks that are occurring now through corrective actions to dealing with risks that may occur in the future through preventive actions.    In a similar way, it seems like in the new 5th Edition of the PMBOK Guide, PMI is trying to shift the paradigm of stakeholder engagement from corrective actions to preventive actions by a) creating stakeholder management as its own knowledge area (it used to be subsumed under communications management) and b) moving stakeholder management to top priority, along with the creation of the project charter, as part of the initiating process before detailed planning on the project even starts to take place.

4.  Similarities in patterns of analysis

The analysis of risk in the risk management knowledge area goes from the macro level (11.3 Perform Qualitative Risk Analysis), where the risks are analyzed in terms of  general categories of risk responses, to the micro level (11.4 Perform Quantitative Risk Analysis), where each individual risk is analyzed, and a response generated (11.6 Plan Risk Responses).    In a similar way, in the stakeholder management area, the analysis of stakeholders and their levels of engagement go from the macro level (13.1 Identify Stakeholders), where the general category of stakeholder engagement response is analyzed, to the micro level (13.2 Plan Stakeholder Management), where the current and desired engagement level of each individual stakeholder is analyzed, and a strategy generated (put in the Stakeholder Management Plan).

5.   Differences between Risk Management and Stakeholder Management

For all the similarities between risk management and stakeholder management, in objectives, approach, and patterns of analysis, the big difference between them is that stakeholder management deals with people rather than events that could impact a project.    Because of this, stakeholder management requires interpersonal skills of communication and influencing people that risk management does not.    That, in fact, is why I am excited to have someone from the Dale Carnegie Institute, which excels in the training of just those types of interpersonal skills (among others), talk about Stakeholder Management because I’m sure he will bring a lot of useful tools to the table, so to speak.

Because we are dealing with people rather than events, there is the opportunity with stakeholder management that you don’t have in risk management; you can influence them so that you can turn a negative stakeholder into a positive stakeholder, whereas you have much less ability to influence events.    You can prepare for a rainy day, but you can’t make it shine rather than rain.    However, if some stakeholder is figuratively “raining on your parade”, there are ways to bring that stakeholder around.    The unpredictability of human behavior is the daunting aspect of stakeholder management, but that very pliability of human behavior is also its most challenging aspect, one that a project manager must learn to master if he or she is to guarantee the success of a project.

5th Edition PMBOK Guide–Chapter 13: Process 13.4 Control Stakeholder Management


1.  Introduction

The fourth out of four procurement-related project management processes is in the Monitoring & Controlling Process group, and is the process which monitors the current engagement level of stakeholders and takes action if that level is not in line with the desired level of engagement at that point in the project.

2.  Inputs

These come from the stakeholder management plan, which has in previous processes identified stakeholders and analyzed them with regards to strategies on a macro level, based on their impact and interest level, and then on a micro level with regards to their individual level of engagement (unaware, resistant, neutral, supportive, or leading).

The issue log is used to record any new issues that come up or to note the resolution of any current issues.    Work performance data is used as an input, where it is analyzed in the course of this process.

The change log and of course the stakeholder register are inputs to this process as well.

13.3 MANAGE STAKEHOLDER MANAGEMENT
INPUTS
1. Stakeholder Management Plan
  • Life cycle for the project (project phases)
  • How work will be executed to accomplish project objectives
  • Human resources requirements:  roles and responsibilities, reporting relationships, staffing management
  • Change management plan
  • Communication management plan
  • Stakeholder management plan–gives current and desired level of stakeholder engagement
2. Issue log
  • New issues are identified
  • Current issues are resolved
3. Work Performance Data
  • Percentage of work completed
  • Technical performance measures
  • Number of change requests
  • Number of defects
  • Budgeted costs vs. actual costs
  • Scheduled activity durations vs. actual durations
4. Project Documents
  • Project schedule
  • Stakeholder register
  • Change log
TOOLS & TECHNIQUES
1. Information Management Systems Helps capture, store, and distribute information to stakeholders on project cost, schedule progress, and performance
2. Expert Judgment Engagement levels of stakeholders are monitored and adjusted by conferring with

  • Senior management
  • Key stakeholders
  • Project managers on other projects in same area
  • SMEs in business or project area
  • Industry groups and consultants
3. Meetings
  • Status review meetings are used to analyze information about stakeholder engagement
OUTPUTS
1. Work performance information Performance data that are collected, analyzed, and integrated.
2. Change requests Analysis of project performance and interactions with stakeholders may generate change requests.
3. Project management plan updates
  • Any of the subsidiary management plans for the various knowledge areas, including stakeholder management, could be changed.
4. Project documents updates
  • Stakeholder register—identification of new stakeholders, change in engagement level of existing stakeholders
  • Issue log–as new issues identified or current issues resolved.
5. OPAs updates
  • Stakeholder notifications
  • Project reports, presentations, records
  • Feedback from stakeholders
  • Lessons learned documentation

3.  Tools & Techniques

The main tool used is the information management system, such as Microsoft Project or Primavera.   Expert judgment and meetings are used to a) analyze the performance data and integrate it to produce useable performance information (how is the project doing as compared to where it should be at this point?), and b) analyze the impact that this will have on various stakeholders.

4.  Outputs

The performance information created in the process is then transmitted to the stakeholders as per the stakeholder and communication management plan.    Change requests might result, not as the result of a change in the project scope, as in the previous process, but due to the change in performance on the project itself.

If in the course of the project, the stakeholders have new requirements or needs, or if those needs change, the stakeholder management plan should be changed to reflect this.    But ANY of the knowledge areas may be affected by the performance information and the stakeholders reaction to it.

The issue log may be updated, as well as the stakeholder register to reflect changing levels of current stakeholder engagement, or changes in the desired level of stakeholder engagement, which may change during the various phases of the project.

This concludes the review of the last of the processes for the stakeholder management area

5th Edition PMBOK® Guide—Chapter 13: Process 13.3 Manage Stakeholder Engagement


1.  Introduction

The third out of four procurement-related project management processes is in the Executing Process group, and is the process which communicates and engages with stakeholders throughout the project in order to meet their needs, address issues, and support stakeholder engagement.  By reducing resistance from stakeholders and gaining their support, a project manager can increase the chances for success on a project.

2.  Inputs

These come from the stakeholder management plan, which has in previous processes identified stakeholders and analyzed them with regards to strategies on a macro level, based on their impact and interest level, and then on a micro level with regards to their individual level of engagement (unaware, resistant, neutral, supportive, or leading).

Change requests that are approved are one of the things that trigger communication to and engagement with stakeholders to monitor the impact of those changes.

Any organizational procedures dealing with the management of issues and change control are also inputs, along with historical information gleaned from previous, similar projects.

13.3 MANAGE STAKEHOLDER MANAGEMENT
INPUTS
1. Stakeholder Management Plan
  • Describes methods and technologies used for communication with stakeholders
  • Determines current level and desired level of stakeholder engagement
  • Describes strategy for managing stakeholders throughout the project life cycle.
2. Communications Management Plan
  • Stakeholder communication requirements
  • Information to be communicated, and reason for distribution
  • Escalation process
3. Change log Documents changes that occur on a project, and their impact on the project’s time, cost and risk.
4. OPAs
  • Organizational communication requirements
  • Issue management procedures
  • Change control procedures
  • Historical information on similar projects
TOOLS & TECHNIQUES
1. Communication Methods Methods of communication specified for each stakeholder are utilized as set forth in Communications Management Plan.
2. Interpersonal Skills Engagement levels of stakeholders are managed by

  • Building trust
  • Resolving conflict
  • Active listening
  • Overcoming resistance to change
3. Management Skills Coordination and harmonization the group toward accomplishment of project objectives through:

  • Facilitation of consensus
  • Influencing people to support project
  • Negotiation of agreements to satisfy project needs
  • Modification of organizational behavior to accept project outcomes
OUTPUTS
1. Issue log Identifies issues and records their resolution.
2. Change requests Change requests to the product or the project may require interaction with the impacted stakeholders.
3. Project management plan updates
  • Stakeholder management plan—new or changed stakeholder requirements
  • Communication management plan—new or changed communication requirements
4. Project documents updates
  • Stakeholder register—identification of new stakeholders, change in engagement level of existing stakeholders
5. OPAs updates
  • Stakeholder notifications
  • Project reports, presentations, records
  • Feedback from stakeholders
  • Lessons learned documentation

3.  Tools & Techniques

The communication methods laid out in the stakeholder and communication management plans are carried out, both interpersonal and management skills are used to manage the stakeholders level of engagement in the project.

4.  Outputs

The issue log identifies issues and records their resolution.  If changes are requested, the stakeholders who may be impacted by those proposed changes need to be communicated with to gauge their reaction.

If in the course of the project, the stakeholders have new requirements or needs, or if those needs change, the stakeholder management plan should be changed to reflect this.  Also, if the requirements for communicating with the stakeholders change, these must be reflected in the communication management plan.

Any changes in the engagement of specific stakeholders need to be included in updates to the stakeholder register, and the company should keep the experience with stakeholders on the current project in mind for inclusion in lessons learned documentation, which may help stakeholder management on future projects.

The next post will cover the last stakeholder management process, 13.4 Control Stakeholder Engagement.