5th Edition PMBOK® Guide–Final Milestone Achieved!


This  year I decided on a major project to go through the 5th Edition of the PMBOK® Guide and it has taken me an entire year’s worth of posts to go through the entire 616-page document according to the following plan:

  • first, I went through the PMBOK® Guide at a macro level, discussing each of the 13 chapters covering general project management topics and then the 10 knowledge areas
  • second, I went through the PMBOK® Guide at a more detailed level covering each of the 47 project management processes spread across the 10 knowledge areas and 5 process groups, and
  • finally, I went through at the micro level by covering each and every single one of the 614 inputs and outputs, tools & techniques belonging to the project management processes.

Yesterday, I completed the last of the cataloging of the inputs and outputs for the last knowledge area of Stakeholder Management.

1.   5 Benefits from the Project

I think this project has been worthwhile from several standpoints, 5 of which I list below:

  1. It has increased my awareness of the different knowledge areas and process groups, especially the ones that seem to intersect even more frequently with a lot of the other knowledge areas (like Integration and Risk).
  2. It has cemented my understanding of the contents of the processes–why are they there, and why are they in the order that they are in?
  3. It has helped my understanding of the ecology of the processes, or how they fit together–by charting all of the ITTOS (inputs, tools & techniques, and outputs) I now have a better understanding of how the processes fit together.    Normally, the processes fit both horizontally across the process groups and vertically within the knowledge areas, but every once and a while there is an output that leaps across the matrix to another process, like change requests that get generated by several monitoring & controlling processes that then get sent over to process 4.5 Perform Integrated Change Control.   These exceptional pathways between processes are important to note, because they always occur with processes that are crucial to project management success.
  4. It has allowed me to understand the PMP exam questions more quickly and more thoroughly.   The simple PMP questions are those which ask you to memorize, the medium level ask you not only to memorize, but to interpret, and the hard level of questions ask you not just to memorize and interpret, but also to analyze a situation that might occur on a typical project in light of that knowledge.    On an PMP exam, your main constraint is TIME, and the faster you can process the easy and medium questions, the more time you will have to spend on the hard questions that ask you to analyze situations.
  5. By essentially turning me from a project management novice when I began this blog in April 2012, the year and a half focus on project management, and in particular on the new 5th Edition PMBOK® Guide, has given me the confidence to market myself as a subject matter expert on the material in the PMBOK® Guide.   That has led directly to a job I am doing now for a company that supplies knowledge tests to companies who are screening applicants, including tests on an applicant’s knowledge of the material in the PMBOK® Guide.   I can take a proposed question and analyze the proposed answers not just for their correctness, but for any potential ambiguity that may cause a test taker to choose the incorrect answer.   I used my blog as part of my “intellectual collateral”, if you will, in order to get the job.

2.   An Unexpected Benefit–Reader Comments

Of course, there are other things I have learned in the course of writing the blog and going through the questions and/or comments from readers.   With now over 100,000 hits from people in over 170 countries around the world, I have been impressed with how universal the language of project management is!     I also am humbled by those who took the time out to notify me of mistakes I made here and there.   Because I spend an hour or more EVERY DAY preparing often very lengthy blog posts, I don’t really have the time to go over the more than 600 posts that I have accumulated in the past year and a half.    But because of readers that are willing to help point out those mistakes, the quality of my blog has increased!

3.  Getting Back to Basics

The most gratifying comments are those from people who say that it has either helped them understand a particular topic they had trouble understanding, or that it has helped them prepare for the PMP exam.    The reason why I undertook this blog in the first place was because I was heading up a study group for the PMP exam when I took the PMP/CAPM exam prep class put on by PMI-OC (Orange County).    Because not everybody could make it to the study group, I put out study notes so that those who missed that week’s study group session could catch up to what we covered.    I did it so that I could understand the material myself, but also so that others who are approaching the material for the first time could understand it as well.

4.   Next Project

My next project is to go through the textbook Project Planning, Scheduling & Control (5th ed.), by James P. Lewis, Ph.D.    By writing about it so that others can understand the material, I am further embedding the material in my own understanding.

So after a few days of posting about a couple of webinars I attended this morning, I will start covering my next project!

5th Edition PMBOK® Guide–Step 6: Memorizing Inputs & Outputs (Stakeholder Management Part 2)


In this next series of posts on memorizing the processes, we move on to the final step 6, which is memorizing the INPUTS & OUTPUTS associated with each of the 47 processes.   In order to breakdown the memorization into more bite-size chunks, I am breaking down the processes in the 10 knowledge areas into 2 or 3 posts each.

This post covers chapter 13 of the PMBOK® Guide, which covers the Stakeholder Knowledge Area. This knowledge area contains 4 processes, one in the Initiating Process Group, one in the Planning Process Group, one in the Executing Process Group, and one in the Monitoring & Controlling Group.    The Stakeholder Knowledge Area is the only knowledge area other than the Integration Knowledge Area to have a process in the Initiating Process Group.

I am splitting the discussion of the Inputs & Outputs into two different posts, each covering two processes.   This post will cover the last two of the four Stakeholder Management processes, Process 13.3 Manage Stakeholder Engagement and 13.4 Control Stakeholder Engagement.

2.  Review of processes 13.3 and 13.4 together with their ITTOs (Inputs, Tools & Techniques, Outputs)

13.3 Manage Stakeholder Engagement is the process of communicating and working with stakeholders to meet their needs and expectations, to address issues as they occur, and foster appropriate stakeholder engagement in project activities throughout the project life cycle.

13.4 Control Stakeholder Engagement is the process of monitoring overall project stakeholder relationships and adjusting strategies and plans for engaging stakeholders.

As usual, in the list of inputs, I use abbreviations for the generic inputs of Enterprise Environmental Factors (EEFs) and Organizational Process Assets (OPAs).

Process Name Tools & Techniques Inputs Outputs
13.3 Manage Stakeholder Engagement 1. Communication methods2. Interpersonal skills

3. Management skills

1. Stakeholder management plan2. Communications management plan

3. Change log

4. OPAs

1. Issue log2. Change requests

3. Project management plan updates

4. Project documents updates

5. OPAs updates

13.2 Control Stakeholder Engagement 1. Information management systems2. Expert judgment

3. Meetings

1. Project management plan2. Issue log

3. Work performance data

4. Project documents

1. Work performance information2. Change requests

3. Project management plan updates

4. Project documents updates

5. OPAs updates

3.  Outputs of Process 13.3 Manage Stakeholder Engagement and 13.4 Control Stakeholder Engagement

a. Issue log (13.3 Manage Stakeholder Engagement)

Managing stakeholder engagement may result in the development of an issue log, which is updated as new issues are identified and current issues are resolved.

b. Change requests (13.3 Manage Stakeholder Engagement and 13.4 Control Stakeholder Engagement)

Managing or controlling stakeholder engagement may result in a change request to the product or the project, including corrective actions or preventive actions.

c. Work performance information (13.4 Control Stakeholder Engagement)

Work performance information is performance data which has been collected from various controlling processes, analyzed in context, and then integrated into a form that is usable by the stakeholders.    Such work performance information may include:

  • Status of deliverables
  • Implementation status for change requests
  • Forecasted estimates to complete

d. Project management plan updates (13.3 Manage Stakeholder Engagement and 13.4 Control Stakeholder Engagement)

Although the PMBOK® Guide lists “Project management plan” as possibly being updated by the process 13.3 Manage Stakeholder Engagement, the specific subsidiary knowledge plan that would be updated is, of course, the Stakeholder Management Plan.   This plan is updated when new or changed stakeholders requirements are identified, or as a result of addressing concerns and resolving issues.

As a result of the process 13.4 Control Stakeholder Engagement, any of the subsidiary plans of the Project Management Plan may end up being updated.

e. Project documents updates (13.3 Manage Stakeholder Engagement and 13.4 Control Stakeholder Engagement)

The particular project document that would be updated as a result of 13.3 Manage Stakeholder Engagement or 13.4 Control Stakeholder Engagement is the stakeholder register.    The stakeholder register would be updated when:

  • Information on stakeholders change
  • New stakeholders are identified
  • Registered stakeholders are no longer involved in or impact by the project

The issue log would be updated when new issues are identified and current reserves are resolved.

f. OPAs updates (13.3 Manage Stakeholder Engagement and 13.4 Control Stakeholder Engagement)

The OPAs that are updated as a result of managing and/or controlling stakeholder engagement are:

  • Stakeholder notifications–information may be provided to stakeholders about resolved issues, approved changes, and general project status
  • Project reports–formal and informal project reports describe project status and include:   lessons learned, issue logs, project closure reports
  • Project presentations–information provided by the project team to any or all project stakeholders
  • Project records–correspondence, memos, meeting minutes
  • Feedback from stakeholders–information received from stakeholders concerning project operations can be distributed and used to modify or improve future performance of the project.
  • Lessons learned documentation–may include:   root cause analysis of issues faced, reasoning behind the corrective action chosen

4. Inputs of Process 13.3 Manage Stakeholder Engagement and 13.4 Control Stakeholder Engagement

a. Stakeholder management plan (13.3 Manage Stakeholder Engagement)

The stakeholder management plan contributes the following to the 13.3 Manage Stakeholder Engagement process:

  • Provides guidance on how the various stakeholders can best be involved in the project
  • Describes the methods and technologies used in stakeholder communication
  • Used to determine the level of interactions of various stakeholders
  • Helps define a strategy for identifying and managing stakeholders throughout the project life cycle

b. Communications management plan (13.3 Manage Stakeholder Engagement)

The communications management plan assists the process of stakeholder management by providing guidance and information on how to use communications to manage stakeholder expectations.    The elements of the plan used in this process include:

  • Stakeholder communication requirements
  • Language, format, content, and level of detail to be communicated
  • Reason for distribution of communication
  • Person or persons who will receive communication
  • Escalation process

c. Project management plan (13.4 Control Stakeholder Engagement)

The following subsidiary plans of the project management plan may be inputs to controlling stakeholder engagement:

  • Scope management plan–shows how work will be executed to accomplish the project objectives
  • Human resources management plan–roles and responsibilities, reporting relationships, and staffing management plan
  • Change management plan–documents how changes will be monitored and controlled
  • Communication management plan–needs and techniques for communication among stakeholders

d. Change log (13.3 Manage Stakeholder Engagement)

This documents the changes that occur on a project, which are communicated to the appropriate stakeholders.

e. Issue log (13.4 Control Stakeholder Engagement)

This is an output of process 13.3 Manage Stakeholder Engagement, and is updated as new issues are identified and current issues are resolved.

f. Work performance data (13.4 Control Stakeholder Engagement)

These are the primary observations and measurements identified during actions performed to carry out the project work, and may include the following:

  • Reported percentage of work completed
  • Technical performance measures
  • Start and finish dates of schedule activities
  • Number of change requests
  • Number of defects
  • Actual costs
  • Actual durations

g. Project documents (13.4 Control Stakeholder Engagement)

The various project documents that are inputs to controlling stakeholder engagement may include:

  • Project schedule
  • Stakeholder register
  • Issue log
  • Change log
  • Project communications

h. OPAs (13.3 Manage Stakeholder Engagement)

The OPAs that are inputs to 13.3 Manage Stakeholder Engagement are

  • Organizational communication requirements
  • Issue management procedures
  • Change control procedures
  • Historical information about previous projects

This concludes the review of the inputs and outputs of the Stakeholder Management knowledge area.

5th Edition PMBOK® Guide–Step 6: Memorizing Inputs & Outputs (Stakeholder Management Part 1)


In this next series of posts on memorizing the processes, we move on to the final step 6, which is memorizing the INPUTS & OUTPUTS associated with each of the 47 processes.   In order to breakdown the memorization into more bite-size chunks, I am breaking down the processes in the 10 knowledge areas into 2 or 3 posts each.

This post covers chapter 13 of the PMBOK® Guide, which covers the Stakeholder Knowledge Area. This knowledge area contains 4 processes, one in the Initiating Process Group, one in the Planning Process Group, one in the Executing Process Group, and one in the Monitoring & Controlling Group.    The Stakeholder Knowledge Area is the only knowledge area other than the Integration Knowledge Area to have a process in the Initiating Process Group.

I am splitting the discussion of the Inputs & Outputs into two different posts, each covering two processes.   This post will cover the first two of the four Stakeholder Management processes, Process 13.1 Identity Stakeholders and 13.2 Plan Stakeholder Management.

2.  Review of processes 13.1 and 13.2 together with their ITTOs (Inputs, Tools & Techniques, Outputs)

13.1 Identify Stakeholders is the process of identifying those people, groups, or organizations that could impact or be impacted by a decision, activity, or outcome of the project; and analyzing information about their interest in and potential impact on project success.

13.2 Plan Stakeholder Management is the process of developing appropriate management strategies to effectively manage stakeholders throughout the project life cycle.

As usual, in the list of inputs, I use abbreviations for the generic inputs of Enterprise Environmental Factors (EEFs) and Organizational Process Assets (OPAs).

Process Name Tools & Techniques Inputs Outputs
13.1 Identify Stakeholders 1.  Stakeholder analysis

2. Expert judgment

3. Meetings

1. Project charter

2. Procurement documents

3. EEFs

4. OPAs

1. Stakeholder register
13.2 Plan Stakeholder Management 1. Expert judgment

2. Meetings

3. Analytical techniques

1. Project management plan

2. Stakeholder register

3. EEFs

4. OPAs

1. Stakeholder management plan

2. Project documents updates

3.  Outputs of Process 13.1 Identify Stakeholders and 13.2 Plan Stakeholder Management

a. Stakeholder register (13.1 Identify Stakeholders)

This is the main output of the process 13.1 Identify Stakeholders and it contains the following information:

  • Identification information (name, organizational position, role in the project, contact information)
  • Stakeholder classification (internal/external, supporter/neutral/resistant engagement level)
  • Assessment information (major requirements, main expectations, potential influence in the project)

b. Stakeholder management plan (13.2 Plan Stakeholder Management)

This is the main output of the process 13.2 Plan Stakeholder Management, and it contains elements that are related to other knowledge areas.    I have listed these elements below and arranged them by knowledge area to which they relate.

Category Element Description
1. Integration Method for updating stakeholder management plan, including review of the validity of underlying assumptions
2. Scope Impact of any changes in scope on stakeholders
3. Time Frequency of distribution of information to stakeholders
4. Communication Communication requirements for stakeholders
5. Information to be distributed to stakeholders:  language, format, content, level of detail
6. Reason for distribution of information to stakeholders and expected impact on engagement level
7.. Stakeholder Current and desired engagement level of stakeholders
8. Interrelationships, potential overlap between stakeholders

c. Project documents updates (13.2 Plan Stakeholder Management)

The two project documents that may be updated as part of process 13.2 Plan Stakeholder Management include

  • Project schedule
  • Stakeholder register

4.  Inputs of Process 13.1 Identify Stakeholders and 13.2 Plan Stakeholder Management

a.  Project charter (13.1 Identify Stakeholders)

This can provide information about internal and external parties related with the project and affected by the project.

b. Procurement documents (13.1 Identify Stakeholders)

If the project is the result of a procurement activity, then the parties in that contract are key project stakeholders.   Suppliers should also be considered as part of the project stakeholder list.

c. Project management plan (13.2 Plan Stakeholder Management)

The parts of the project management plan that may be inputs to 13.2 Plan Stakeholder Management are:

  • Scope Management Plan–description of how work will be executed to accomplish the project objectives
  • Human Resources Management Plan–description of how human resources requirements will be met
  • Change Management Plan–documents how changes will be monitored and controlled
  • Communication Management Plan–need for communication among stakeholders

d. Stakeholder register (13.2 Plan Stakeholder Management)

This is an output of process 13.2 Identify Stakeholders, and is an input to the following process, 13.2 Plan Stakeholder Management.

e. EEFs (13.1 Identify Stakeholders and 13.2 Plan Stakeholder Management)

The EEFs that could be inputs to the process 13.1 Identify Stakeholders and 13.2 Plan Stakeholder Management include the following:

  • Organizational culture and structure
  • Governmental and industry standards
  • Global, regional or local trends

f.  OPAs (13.1 Identify Stakeholders and 13.2 Plan Stakeholder Management)

The OPAs that could be inputs to the process 13.1 Identify Stakeholders and 13.2 Plan Stakeholder Management include the following:

  • Stakeholder register templates
  • Lessons learned from previous projects
  • Stakeholder registers from previous projects

 

Essential Integral, Lesson Four: Levels (Two)


1.  Introduction

The concept  of levels deals with the levels of individual development, along with activities that seek to cultivate an awareness of developmental complexity and the ability to apply levels in communication.

The topic is complicated enough that it requires two lessons to cover the entire subject.

TO BE CONTINUED

3 Essential Questions to Ask Yourself When Writing A Speech


At the District 30 (Chicagoland) Toastmaster Leadership Institute for Winter 2013-2014, the 2004 World Champion of Public Speaking, Randy J. Harvey, PhD., J.D., was invited to be the keynote speaker for the event.

In his presentation, he outlined the three essential questions you need to ask yourself when you are considering writing a speech.    This post is a summary of that presentation.

1.   Who are you?

Everything you do is an outward manifestation of your inward philosophy of life.    You may not have formulated it in concrete terms, or even know what those terms are, but it is the foundation of your actions.    You need to ask yourself “what do I believe?”  “What are the essential characteristics that would describe me?”

The reason why you need to ask this question is because those people who are aware of their philosophy of life, and do speeches based on that knowledge, are those that come across as more authentic to an audience because they are not just parroting something they have read, they are talking about something which comes out of their LIFE.

2.  What are you about?

A belief is something that can change, but a core value is something which is relatively constant in one’s life, and is something even more fundamental to who you are than a belief.     If you were to place a narrow board across two of the highest buildings in Chicago on an icy, windy day, would you be willing to cross that for a $1 million?    Probably not, because you would be risking your life, and your life is worth more than that.

But if you saw your child in danger on the other building, you might indeed be willing to make that sacrifice.    That is because the love of your child is a core value that is so important that you would be willing to make the ultimate sacrifice of your own life if it meant saving that child’s life.

3.  Where did you learn that?

There are both people and events which have clarified for us those beliefs and core values which were discussed in the previous two paragraphs.    If you relive an event which taught you a moral value, or describe a person that taught you that moral value, then you are recreating the wellspring of your moral existence.

If you ask yourself these three questions, you will be able to find your own voice that is authentic, meaning that it is primarily created out of your own experiences, and not derived from the thoughts or ideas of others.    When you speak from this voice, you will find yourself speaking at a level of authenticity that you need to become a world-class speaker, whether you enter the International Speech Contest or not.

Dr. Harvey’s talk reminded me of the time when I lost my first speech contest.   I tried really hard but only got as far as the Area Contest, but didn’t go on to the Division Contest.    Part of me was disappointed, although I put on a brave, smiling face to all the others in the room.    One of the judges came up to me after the end of the contest and said, “I just wanted to encourage you to compete again in the future, because you’ve got ‘the fire’.”    “What do you mean, ‘the fire’?”  The judge went on to explain that what she meant was that I spoke from a sincere conviction, and that came across in the passion of my speech.    She said, “Toastmasters can teach you technique, but they can’t teach you to have conviction.   You’ve got to find that out for yourself, and it looks like you’ve already found that.    Come back next year, and you’ll see how far you’ve progressed.”

On the way home, I started to think, “well maybe I should join the next contest.    I wonder what I can talk about?”  And then I caught myself coming home from one contest and thinking already about what I was going to do in the next contest, and I laughed.   “I’m hooked!”    But it took someone to recognize that conviction, that “voice” inside the unpolished speaker, and I am so grateful she spoke up and decided to encourage me.    That conviction is what Dr. Harvey was talking about uncovering in his speech, and I’m so glad I went to have these important lessons reinforced.

I now have a club to go back to and inspire for the Spring Speech Contest!

5th Edition PMBOK® Guide–Step 6: Memorizing Inputs & Outputs (Procurement Management Part 2)


In this next series of posts on memorizing the processes, we move on to the final step 6, which is memorizing the INPUTS & OUTPUTS associated with each of the 47 processes.   In order to breakdown the memorization into more bite-size chunks, I am breaking down the processes in the 10 knowledge areas into 2 or 3 posts each.

This post covers chapter 12 of the PMBOK® Guide, which covers the Procurement Knowledge Area. This knowledge area contains 4 processes, one in the Planning Process Group, one in the Executing Process Group, one in the Monitoring & Controlling Group, and one in the Closing Process Group.    The Procurement Knowledge Area is the only knowledge area other than the Integration Knowledge Area to have a process in the Closing Process Group.

I am splitting the discussion of the Inputs & Outputs into two different posts, each covering two processes.   This post will cover the last two of the four procurement processes, Process 12.3 Control Procurements and 12.4 Close Procurements.

2.  Review of processes 12.3 and 12.4 together with their ITTOs (Inputs, Tools & Techniques, Outputs)

12.3 Control Procurements is the process of managing procurement relationships, monitoring contract performance, and making changes and corrections as appropriate.

12.4 Close Procurements is the process of completing each project procurement.

As usual, in the list of inputs, I use abbreviations for the generic inputs of Enterprise Environmental Factors (EEFs) and Organizational Process Assets (OPAs).

Process Name Tools & Techniques Inputs Outputs
12.3 Control Procurements 1. Contract change control system

2. Procurement performance reviews

3. Inspections and audits

4. Performance reporting

5. Payment systems

6. Claims administration

7. Records management system

1. Project management plan

2. Procurement documents

3. Agreements

4. Approved change requests

5. Work performance reports

6. Work performance data

 

1. Work performance information

2. Change requests

3. Project management plan updates

4. Project documents updates

5. OPAs updates

12.4 Close Procurements 1. Procurement audits

2. Procurement negotiations

3. Records management system

1. Project management plan

2. Procurement documents

1. Closed procurements

2. OPAs updates

3.  Outputs of Process 12.3 Control Procurements and 12.4 Close Procurements

a. Work performance information (12.3 Control Procurements)

As a result of the process 12.3 Control Procurements, work performance information provides a basis for identification of current or potential problems, which may assist in the event that there is a dispute with the vendor.

Contract compliance reports provide procuring organizations a mechanism to track specific deliverables expected and received from vendors.

b. Change requests (12.3 Control Procurements)

Change requests may result from the 12.3 Control Procurements process, and may includes changes to any of the subsidiary plans of the Project Management Plan.   These requests are processed for review and approval in the process 4.5 Perform Integrated Change Control.

c. Project management plan updates (12.3 Control Procurements)

The elements of the project management plan that may be updated as a result of 12.3 Control Procurements are:

  • Procurement management plan–updated to reflect any approved change requests that affect procurement management, including impacts to costs or schedules
  • Schedule baseline–if there are slippages that impact overall project performance, the schedule baseline may need to be updated
  • Cost baseline–if there are changes that impact overall project costs, the cost baseline may need to be updated

d. Project documents updates (12.3 Control Procurements)

The procurement documentation that may be updated as a result of 12.3 Control Procurements includes the following:

  • Procurement contract–with all supporting schedule, approved change requests, and requested but unapproved change requests
  • Technical documentation developed by the seller
  • Work performance information–including deliverables, seller performance reports and warranties
  • Financial documents–including invoices and payment records
  • Results of contract-related inspections

e. OPAs updates (12.3 Control Procurements and 12.4 Close Procurements)

The OPAs that may be updated as a result of the process 12.3 Control Procurements:

  • Correspondence–contract terms and conditions often require written documentation of certain aspects of buyer/seller communications
  • Payment schedules and requests–should be made in accordance with the procurement contract terms and conditions
  • Seller performance evaluation documentation–this is prepared by the buyer; it documents the seller’s ability to continue to perform work on the current contract

The OPAs that may be updated as a result of the process 12.4 Close Procurements are:

  • Procurement file–a complete set of indexed contract documentation, including the closed contract
  • Deliverable acceptance–documentation of formal acceptance of seller-provided deliverables
  • Lessons learned documentation–what has been experienced, process improvement recommendations

f. Closed procurements (12.3 Control Procurements)

The buyer provides the seller with formal written notice that the contract has been completed.  The requirements for formal procurement closure are usually defined in the terms and conditions of the procurement contract and are included in the Procurement Management Plan.

4.  Inputs of Process 12.3 Control Procurements and 12.4 Close Procurements

a. Project management plan (12.3 Control Procurements and 12.4 Close Procurements)

Okay, the PMBOK® Guide says the overall Project Management Plan is an input, but in reality, the particular subsidiary management plan of the overall Project Management Plan that is relevant to the process 12.3 is, of course, the Procurement Management Plan (the output of process 12.1 Plan Procurement Management).    As I mentioned in the previous post, the Procurement Management Plan, like the Risk Management Plan, has elements that are related to all of the other knowledge areas.   Here are the elements of the Procurement Management Plan, which are arranged by the knowledge area that they relate to:

Related Knowledge Area  Plan Element
1. Integration Project constraints and assumptions that could affect planned procurements
2. Scope Direction to sellers on developing and maintaining work breakdown structure (WBS)
3. Format for procurement statement of work (SOW) to be put in contract
4. Time Coordination of procurement with project scheduling
5. Handling long lead times to purchase certain items from sellers and coordinating extra time needed with project schedule
6. Linking make-or-buy decision with Estimate Activity Resources and Develop Schedule processes
7. Setting scheduled dates for delivery and acceptance of contract deliverables
8. Cost Whether independent estimates will be used as evaluation criteria
9. Quality Performance criteria for acceptance of deliverables
10. Human Resources Roles and responsibilities for project management team coordination with the organization’s procurement or purchasing department
11. Communications Coordination of procurement with performance reporting
12.. Risk Risk management issues related to procurement
13. Requirements for performance bonds or insurance contracts to mitigate project risk
14. Procurements Types of contracts to be used (fixed price, cost-reimbursable, or time & material)
15. Identifying pre-qualified sellers
16. Procurement metrics to be used in evaluating sellers and managing contracts
17. Management of multiple suppliers
18. Stakeholder Include sellers as one of stakeholder groups to be managed
19. EEFs Industry or professional organization information resources regarding potential sellers
20. OPAs Standardized procurement documents

b. Procurement documents (12.3 Manage Procurements and 12.4 Close Procurements)

The following documents support the administration of procurement processes:

  • Procurement contract awards
  • Procurement Statement of Work (SOW)

The following documents support the closure of procurement processes:

  • Information on contract performance related to schedule, scope, quality and cost
  • Contract change documentation
  • Payment records
  • Inspection results

This information is used for lessons learned.

c. Agreements (12.3 Control Procurements)

Agreements are the understandings between parties, including the understandings of the duties of each party.

d. Approved change requests (12.3 Control Procurements)

In the case of procurements, the approved change requests include modifications to the terms and conditions of the procurement contract, including the following:

  • Procurement SOW
  • Pricing
  • Descriptions of the products, services, or results to be provided

All procurement-related changes are formally documented in writing and approved by the process 4.5 Perform Integrated Change Control before being implemented in the process 12.3 Control Procurements.

e. Work performance reports (12.3 Control Procurements)

The documentation related to procurement performance includes the following:

  • Technical documentation–technical documentation developed by the seller in accordance with the terms of the contract
  • Work performance information–the seller’s performance reports indicate which deliverables have been completed and which have not

f. Work performance data (12.3 Control Procurements)

Work performance data relevant to the process 12.3 Control Procurements includes the following:

  • the extent to which quality standards are being satisfied
  • the costs that have been incurred or committed
  • identification of the seller invoices that have been paid

This can be used as lessons learned and as a basis for evaluating contractors for future projects.

5.  Conclusion

This concludes the review of the inputs and outputs for the last two processes of Procurement Management.   Next week, I will finish off this project by reviewing the inputs and outputs for the last knowledge area in the PMBOK® Guide, Stakeholder Management.

5th Edition PMBOK® Guide–Step 6: Memorizing Inputs & Outputs (Procurement Management Part 1)


In this next series of posts on memorizing the processes, we move on to the final step 6, which is memorizing the INPUTS & OUTPUTS associated with each of the 47 processes.   In order to breakdown the memorization into more bite-size chunks, I am breaking down the processes in the 10 knowledge areas into 2 or 3 posts each.

This post covers chapter 12 of the PMBOK® Guide, which covers the Procurement Knowledge Area. This knowledge area contains 4 processes, one in the Planning Process Group, one in the Executing Process Group, one in the Monitoring & Controlling Group, and one in the Closing Process Group.    The Procurement Knowledge Area is the only knowledge area other than the Integration Knowledge Area to have a process in the Closing Process Group.

I am splitting the discussion of the Inputs & Outputs into two different posts, each covering two processes.   This post will cover Process 12.1 Plan Procurement and Process 12.2 Conduct Procurements.

2.  Review of processes 12.1 and 12.2 together with their ITTOs (Inputs, Tools & Techniques, Outputs)

The purpose of process 12.1 Plan Procurement is to create the Procurement Management Plan, which gives the framework needed to document project procurement decisions, to specify the approach to procurement, and to identify potential sellers.

The purpose of process 12.2 Conduct Procurement is to obtain seller responses to the request for proposal (RFP) or another form of procurement request, to select a seller based on established criteria, and to award the procurement contract to that seller.

As usual, in the list of inputs, I use abbreviations for the generic inputs of Enterprise Environmental Factors (EEFs) and Organizational Process Assets (OPAs).

Process Name Tools & Techniques Inputs Outputs
12.1 Plan Procurement 1. Make-or-buy analysis

2. Expert judgment

3. Market research

4. Meetings

1. Project management plan

2. Requirements documentation

3. Risk register

4. Activity resource requirements

5. Project schedule

6. Activity cost estimates

7. Stakeholder register

8. EEFs

9. OPAs

1. Procurement management plan

2. Procurement statement of work

3. Procurement documents

4. Source selection criteria

5. Make-or-buy decisions

6. Change requests

7. Project documents updates

12.2 Conduct Procurement
1. Bidder conference

2. Proposal evaluation techniques

3. Independent estimates

4. Expert judgment

5. Advertising

6. Analytical techniques

7. Procurement negotiations

1. Procurement management plan

2. Procurement documents

3. Source selection criteria

4. Seller proposals

5. Project documents

6. Make-or-buy decisions

7. Procurement statement of work

8. OPAs

1. Selected sellers

2. Agreements

3. Resource calendars

4. Change requests

5. Project management plan updates

6. Project documents updates

3.  Outputs of process 12.1 Plan Procurement and 12.2 Conduct Procurement

a. Procurement management plan (12.1 Plan Procurement)

The Procurement Management Plan, like the Risk Management Plan, has elements that touch upon practically all of the other knowledge areas.   I have taken the list of elements of the Procurement Management Plan listed in the PMBOK® Guide and arranged them by related knowledge area in order to put some structure to this rather large list of elements.

Related Knowledge Area  Plan Element
1. Integration Project constraints and assumptions that could affect planned procurements
2. Scope Direction to sellers on developing and maintaining work breakdown structure (WBS)
3. Format for procurement statement of work (SOW) to be put in contract
4. Time Coordination of procurement with project scheduling
5. Handling long lead times to purchase certain items from sellers and coordinating extra time needed with project schedule
6. Linking make-or-buy decision with Estimate Activity Resources and Develop Schedule processes
7. Setting scheduled dates for delivery and acceptance of contract deliverables
8. Cost Whether independent estimates will be used as evaluation criteria
9. Quality Performance criteria for acceptance of deliverables
10. Human Resources Roles and responsibilities for project management team coordination with the organization’s procurement or purchasing department
11. Communications Coordination of procurement with performance reporting
12.. Risk Risk management issues related to procurement
13. Requirements for performance bonds or insurance contracts to mitigate project risk
14. Procurements Types of contracts to be used (fixed price, cost-reimbursable, or time & material)
15. Identifying pre-qualified sellers
16. Procurement metrics to be used in evaluating sellers and managing contracts
17. Management of multiple suppliers
18. Stakeholder Include sellers as one of stakeholder groups to be managed
19. EEFs Industry or professional organization information resources regarding potential sellers
20. OPAs Standardized procurement documents

b. Procurement statement of work (12.1 Plan Procurement)

The Procurement Statement of Work (or Procurement SOW) is a critical component of the procurement process.   It can be considered to be the “seed” of the procurement, and it provides suppliers with a clearly stated set of goals, requirements, and outcomes from which they can provide a quantifiable response.    For the elements of the Procurement statement of work, see paragraph p. below under Inputs.

c. Procurement documents (12.1 Plan Procurement)

There are different documents which are used to formally request procurements, among which are the following types:

  • Request for Information (RFI)
  • Invitation for Bid (IFB)
  • Request for Proposal (RFP)
  • Request for Quotation (RFQ)
  • Tender Notice
  • Invitation for Negotiation
  • Invitation for Seller’s Initial Response

Specific procurement terminology used may vary by industry and location of the procurement.

d. Source selection criteria  (12.1 Plan Procurement)

Used to rate or score seller proposals.   Selection criteria may be as narrow as simply the purchase price and the cost of delivery if the procurement item is “off-the-shelf”, or readily available from a number of acceptable sellers.   For more complex products, the following may be used as source selection criteria:

  • Understanding of need (does the seller’s proposal address the Procurement SOW?)
  • Overall or life-cycle cost (including purchase cost and operating cost)
  • Technical capability (does the seller have the technical skills and knowledge required?)
  • Risk (how much risk is embedded in the SOW?; how much risk will be assigned to the seller?; how does the seller mitigate risk?)
  • Management approach (does the seller have management processes and procedures to ensure a successful project?)
  • Technical approach (does the seller’s technical methodologies meet the procurement document requirements?)
  • Warranty (what does the seller propose to warrant in the final product, and for what period?)
  • Financial capacity (does the seller have the necessary financial resources?)
  • Production capacity and interest (does the seller have the capacity and interest to meet potential future requirements for production?)
  • Business type and size (does the seller’s enterprise meet a specific category of business set forth as a condition of the agreement award such as a small business?)
  • Past performance of sellers (what has been the past experience with selected sellers?)
  • References (can the seller provide references from prior customers?)
  • Intellectual property rights (does the sellers assert IP rights in the work processes or services they will use or in the products they produce for the project?)
  • Proprietary rights (does the sellers assert proprietary rights in the work processes or services they will use or in the products they produce for the project?)

e. Make-or-buy decisions (12.1 Plan Procurement)

This output is the result of the technique of make-or-buy analysis that is used as part of process 12.1 Plan Procurement.

f. Change requests (12.1 Plan Procurement and 12.2 Conduct Procurement)

A decision to procure rather than to produce certain goods, services, or results to be used on the project requires a change request.    As with all other change requests, it then becomes an input to process 4.5 Perform Integrated Change Control, where the change request is reviewed and either accepted or rejected.

g. Project documents updates (12.1 Plan Procurement and 12.2 Conduct Procurement)

The particular project documents that may be updated as part of the process  12.1 Plan Procurement or 12.2 Conduct Procurement are:

  • Requirements documentation
  • Requirements traceability matrix
  • Risk register
  • Stakeholder register

h. Selected sellers (12.2 Conduct Procurement)

The list of selected sellers is one of the main outputs of the 12.2 Conduct Procurement process.    Selected sellers have been judged to be in a competitive range based on the evaluation of their proposals or bids.

i. Agreements (12.2 Conduct Procurement)

A procurement agreement can be called any of the following:

  • an understanding
  • a contract
  • a subcontract
  • a purchase order

It contains the terms and conditions for the procurement.    The project management team must make sure that all agreements not only meet the specific needs of the project, but that they also adhere to the organization’s procurement policies.

j. Resource calendars (12.2 Conduct Procurement)

Includes the quantity and availability of contracted resources, as well as the dates on which each specific resource will be actively used on the project.

k. Project management plan updates (12.2 Conduct Procurement)

The following elements of the Project Management Plan may be updated as part of the 12.1 Conduct Procurement process.

  • Performance baselines (cost, scope, and schedule baselines)
  • Communications management plan
  • Procurement management plan

4.  Inputs of process 12.1 Plan Procurement and 12.2 Conduct Procurement

a. Project management plan (12.1 Plan Procurement)

Although the PMBOK® Guide lists the Project Management Plan as an input, to be more accurate, the most relevant portion of that overall plan to the 12.1 Plan Procurement process is the scope baseline, which consists of

  • Project scope statement–contains product or scope description (or alternately a service description or result description), the list of deliverables, acceptance criteria, technical issues that could impact cost estimating, and project constraints (such as required delivery dates, available skilled resources, and organizational policies)
  • WBS (contains the components of work that may be resourced externally)
  • WBS Dictionary (provides an identification of the deliverables and a description of the work in each WBS component)

b. Requirements documentation (12.1 Plan Procurement)

The requirements documentation may include

  • Product requirements that are considered during planning for procurements
  • Contractual and legal requirements (related to concerns about health, safety, security, performance, environmental, insurance, intellectual property rights, equal employment opportunity, licenses, permits)

c. Risk register (12.1 Plan Procurement)

Provides the list of risks, along with the results of risk analysis and risk response planning.

d. Activity resource requirements (12.1 Plan Procurement)

Contains information on specific needs such as people, equipment, or location.

e. Project schedule (12.1 Plan Procurement)

Contains information on required timelines or mandated delivery dates.

f. Activity cost estimates (12.1 Plan Procurement)

Used to evaluate the reasonableness of the bids or proposals received from potential sellers.

g. Stakeholder register (12.1 Plan Procurement)

Provides details on the project participants and their interests and impacts on the project.

h. EEFs (12.1 Plan Procurement)

The EEFs that are inputs to process 12.1 Plan Procurement include the following:

  • Marketplace conditions
  • Products, services or results that are available in the marketplace
  • Suppliers, including past performance  or reputation
  • Typical terms and conditions for products, services or results for the specific industry
  • Unique local requirements

i. OPAs (12.1 Plan Procurement and 12.2 Conduct Procurement)

The OPAs that are inputs to process 12.1 Plan Procurement include the following:

  • Formal procurement policies, procedures, and guidelines–most organizations have units dedicated to procurement, but when such procurement support is not available, the project team needs to supply the resources and the expertise to perform such procurement activities.
  • Management systems–considered in developing the procurement management plan and selecting the contractual relationships to be had.
  • An established multi-tier supplier system of prequalified sellers based on prior experience on previous projects

j. Procurement management plan (12.2 Conduct Procurement)

This input is the main output of process 12.1 Plan Procurement Management.   See paragraph a. above under Outputs for a complete listing of the elements of the Procurement Management Plan.

k. Procurement documents (12.2 Conduct Procurement)

Provides an audit trail for contracts and other agreements.

l. Source selection criteria (12.2 Conduct Procurement)

These can include information on the following aspects of the supplier:

  • Required capabilities
  • Capacity
  • Delivery dates
  • Product cost
  • Life-cycle cost
  • Technical expertise
  • Approach to the contract (Fixed-Price, Cost-Reimbursable, or Time & Material)

m. Seller proposals (12.2 Conduct Procurement)

Prepared in response to a procurement document package, the seller proposals form the basic information that will be used by an evaluation body to select one or more successful bidders (sellers).

n. Project documents (12.2 Conduct Procurement)

The risk register may include risk-related contract decisions.

o. Make-or-buy decisions (12.2 Conduct Procurement)

Factors that may influence make-or-buy decisions are:

  • Core capabilities of the organization
  • Value delivered by vendors meeting the need
  • Risks associated with meeting the need in a cost-effective manner
  • Capability internally compared with the vendor community

p. Procurement statement of work (12.2 Conduct Procurement)

The procurement statement of work may include the following elements:

  • Specifications
  • Quantity desired
  • Quality level
  • Performance data
  • Period of performance
  • Work location

The next post will cover the last two processes of the Procurement Management Knowledge Area, process 12.3 Control Procurements and 12.4 Close Procurements.

5th Edition PMBOK® Guide–Step 6: Memorizing Inputs & Outputs (Risk Management Part 3)


In this next series of posts on memorizing the processes, we move on to the final step 6, which is memorizing the INPUTS & OUTPUTS associated with each of the 47 processes.   In order to breakdown the memorization into more bite-size chunks, I am breaking down the processes in the 10 knowledge areas into 2 or 3 posts each.

This post covers chapter 11 of the PMBOK® Guide, which covers the Risk Knowledge Area. This knowledge area contains 6 processes, the first five of which are in the Planning Process Group, and the last of which is in the Monitoring & Controlling Group.

I am splitting the discussion of the Inputs & Outputs into three different posts, each covering two processes.   This post will cover Process 11.5 Plan Risk Responses and Process 11.6 Control Risks.

2.  Review of processes 11.5 and 11.6 together with their ITTOs (Inputs, Tools & Techniques, Outputs)

Process Name Tools & Techniques Inputs Outputs
11.5 Plan Risk Responses 1. Strategies for negative risks or threats

2. Strategies for positive risks or opportunities

3. Contingent response strategies

4. Expert judgment

1. Risk management plan

2. Risk register

 

1. Project management plan updates

2. Project documents updates

11.6 Control Risks 1. Risk reassessment

2. Risk audits

3. Variance and trend analysis

4. Technical performance measurement

5. Reserve analysis

6. Meetings

1. Project management plan

2. Risk register

3. Work performance data

4. Work performance reports

1. Work performance information

2. Change requests

3. Project management plan updates

4. Project documents updates

5. OPAs updates

3.  Output of processes 11.5 Plan Risk Responses and 11.6 Control Risks

a. Project management plan updates (11.5 Plan Risk Responses and 11.6 Control Risks)

In the same way that many knowledge areas contribute inputs to the risk management processes, the outputs of the risk management processes in turn affect many of these same knowledge areas.   For example, the following subsidiary plans of the overall Project Management Plan may be updated as a result of the 11.5 Plan Risk Responses process:

  • Schedule management plan–updated to reflect changes in process and practice driven by risk responses
  • Cost management plan–updated to reflect changes in process and practice driven by risk responses
  • Quality management plan–updated to reflect changes in process and practice driven by risk responses
  • Procurement management plan–updated to reflect changes in strategy (such as alterations in the make-or-buy decision or contract types)
  • Human resource management plan–updated to reflect changes in project organizational structure and resource applications driven by risk responses
  • Scope, schedule, and cost baseline–updated to reflect changes due to new, modified or omitted work generated by risk responses

b. Project documents updates (11.5 Plan Risk Responses and 11.6 Control Risks)

The following elements of the risk register may be updated as a result of the process 11.5 Plan Risk Responses:

  • Risk owners and assigned responsibilities
  • Agreed-upon response strategies
  • Specific actions to implement the chosen response strategy
  • Trigger conditions, symptoms, and warning signs of a risk occurrence
  • Budget and schedule activities required to implement the chosen responses
  • Contingency plans and triggers that call for their execution
  • Fallback plans for use as a reaction to a risk that has occurred and the primary response proves to be inadequate
  • Residual risks that are expected to remain after planned responses have been taken, as well as those that have been deliberately accepted
  • Secondary risks that arise as a direct outcome of implementing a risk response
  • Contingency reserves that are calculated based on the quantitative risk analysis of the project and the organization’s risk thresholds

Other project documents that may be updated as a result of process 11.5 Plan Risk Responses include:

  • Assumptions logs–assumptions could change as new information becomes available through the application of risk responses
  • Technical documentation–technical approaches and physical deliverables may change as new information becomes available through the application of risk responses
  • Change requests–planning for possible risk responses can often result in recommendations for changes to the resources, activities, cost estimates, etc.

As far as the process 11.6 Control Risk is concerned, the potential updates to the risk register may include:

  • Outcomes of risk reassessments, risk audits, and periodic risk reviews–these may include identification of new risks; updates to probability,  impact, priority, responses plans, and ownership of risks; and finally the closing of risks that are no longer applicable and the release of the applicable reserves
  • Actual outcomes of the project’s risks and of the risk responses–this can help project managers to plan for risks on other current projects in the organization, as well as future projects

c. Work performance information (11.6 Control Risks)

As an output of 11.6 Control Risks, work performance information is a mechanism to communicate and to support project decision making.

d. Change requests (11.6 Control Risks)

The implementation of contingency plans or workarounds can sometimes result in a change request, which may consist of

  • Recommended corrective actions
  • Recommended preventive actions

e. OPAs updates (11.6 Control Risks)

The OPAs that may be updated as a result of 11.6 Control Risks are:

  • Templates for the risk management plan (including the probability/impact matrix and risk register)
  • Risk Breakdown Structure
  • Lessons learned from project risk management activities

 

4.  Input of processes 11.5 Plan Risk Responses and 11.6 Control Risks

a. Risk management plan (11.5 Plan Risk Responses)

The important components of the Risk Management Plan that are inputs to this process are:

  • Risk activity-related roles and responsibilities
  • Risk analysis definitions
  • Timing of risk reviews
  • Risk thresholds (low, moderate, high risks)–helps identify those risks for which specific responses are needed

b. Project management plan (11.6 Control Risks)

The PMBOK® Guide lists the Project Management Plan as an input of process 11.6 Control Risks, but if you look at the entry closely, it specifies that the portion of the Project Management Plan that is relevant to the process is the Risk Management Plan, in particular those portions which give guidance for risk monitoring and controlling.

c.  Risk register (11.5 Plan Risk Responses and 11.6 Control Risks)

The following elements of the risk register are inputs of process 11.5 Plan Risk Responses and 11.6 Control Risks:

  • Lists of identified risks
  • Root causes of risks
  • Risk responses (potential responses are inputs to 11.5, agreed-upon responses are inputs to 11.6)
  • Risk owners
  • Risk symptoms and warning signs
  • Relative rating or priority list of project risks
  • Risks requiring responses in the near term
  • Risks for additional analysis and response
  • Trends in quantitative analysis results
  • Watch list (list of low-priority risks)
  • Contingency reserves (developed in process 11.5, these are inputs to 11.6)

d. Work performance data (11.6 Control Risks)

The work performance data that are particular relevant to the process 11.6 Control Risks are:

  • Deliverable status
  • Schedule progress
  • Costs incurred

e. Work performance reports (11.6 Control Risks)

The work performance information that is included in work performance reports, which are inputs to 11.6 Control Risks, could be impactful in controlling performance-related risks.

  • Variance analysis
  • Earned value data
  • Forecasting data

This concludes the ITTOs for the last two processes of risk management.   Tomorrow I will take up chapter 12, which covers the knowledge area of Procurement Management.

 

5th Edition PMBOK® Guide–Step 6: Memorizing Inputs & Outputs (Risk Management Part 2)


In this next series of posts on memorizing the processes, we move on to the final step 6, which is memorizing the INPUTS & OUTPUTS associated with each of the 47 processes.   In order to breakdown the memorization into more bite-size chunks, I am breaking down the processes in the 10 knowledge areas into 2 or 3 posts each.

This post covers chapter 11 of the PMBOK® Guide, which covers the Risk Knowledge Area. This knowledge area contains 6 processes, the first five of which are in the Planning Process Group, and the last of which is in the Monitoring & Controlling Group.

I am splitting the discussion of the Inputs & Outputs into three different posts, each covering two processes.   This post will cover Process 11.3 Perform Qualitative Risk Analysis and Process 11.4 Perform Quantitative Risk Analysis.

2.  Review of processes 11.3 and 11.4 together with their ITTOs (Inputs, Tools & Techniques, Outputs)

Process Name Tools & Techniques Inputs Outputs
11.3 Perform Qualitative Risk Analysis 1. Risk probability and impact assessment2. Probability and impact matrix

3. Risk data quality assessment

4. Risk categorization

5. Risk urgency assessment

6. Expert judgment

1. Risk management plan2. Scope baseline

3. Risk register

4. EEFs

5. OPAs

1, Project documents updates
11.4 Perform Quantitative Risk Analysis 1. Data gathering and representation techniques2. Quantitative risk analysis and modeling techniques

3. Expert judgment

1. Risk management plan2. Cost management plan

3. Schedule management plan

4. Risk register

5. EEFs

6. OPAs

1. Project documents updates

As is true of all risk  management processes, the outputs are very easy to remember because there’s only one, whereas the inputs are more numerous and come from various knowledge areas.

3.  Output of processes 11.3 Qualitative Risk Analysis and 11.4 Quantitative Risk Analysis

a.  Project documents updates (11.3 Qualitative Risk Analysis and 11.4 Quantitative Risk Analysis)

The project documents updated as part of the 11.3 Qualitative Risk Analysis process are:

  • Risk register–updated with probability and impacts for each risk, risk ranking or scores, risk urgency information or risk categorization, and a watch list for low-probability risks or risks requiring further analysis
  • Assumptions log–updated if assumptions change based on new information that becomes available during qualitative risk analysis (assumptions may also be included in the project scope statement rather than a separate assumptions log)

4.  Input of processes 11.3 Qualitative Risk Analysis and 11.4 Quantitative Risk Analysis

a. Risk management plan (11.3 Qualitative Risk Analysis and 11.4 Quantitative Risk Analysis)

The Risk Management Plan developed in the 11.1 Plan Risk Management process contains many elements relevant to the two processes 11.3 Qualitative Risk Analysis and 11.4 Quantitative Risk Analysis.

Category Plan Element Definition of Element
1. OPAs Methodology Tools and data sources from the organization to be used in risk management.
2. Time Timing How and when risk management activities will be conducted; protocol for application of contingency and management reserves.
3. Cost Budgeting Funds needed for risk management activities
4. Quality Tracking How risk activities will be recorded in order to audit and improve risk management processes.
5. HR Roles and Responsibilities Defines, for each type of activity in the risk management plan, the following:

  • Lead (accountable)
  • Team members (responsible)
  • Support (consult)
6. Communication Reporting formats Defines how the outcomes of the risk management process will be documented, analyzed, and communicated.
7. Risk Risk categories Grouping potential sources of risk on the project, often in the form of a Risk Breakdown Structure (RBS).
8. Probability and impact definitions Different levels of risk probability and impact are defined (low, medium, high, etc.)
9. Probability and impact matrix Grid for mapping the probability of each risk and its potential impact on the project.
10. Stakeholders Stakeholder risk tolerances Stakeholder risk tolerances may be revised during the course of this process.

b. Cost management plan (11.4 Quantitative Risk Analysis)

Provides guidelines on establishing and managing risk reserves (both contingency reserves and management reserves).

c. Schedule management plan (11.4 Quantitative Risk Analysis)

Provides guidelines on establishing and managing risk reserves (both contingency reserves and management reserves).

d. Scope baseline (11.3 Qualitative Risk Analysis)

The risk of projects, especially highly complex projects or those using state-of-the-art technology, can be evaluated by examining the scope baseline, in particular the project scope statement and the WBS (work breakdown structure).

e. Risk register (11.3 Qualitative Risk Analysis and 11.4 Quantitative Risk Analysis)

Contains information used to assess and prioritize risks for the process 11.3 Qualitative Risk Analysis, and is also used as a reference point for performing quantitative risk analysis in process 11.4

f. EEFs (11.3 Qualitative Risk Analysis and 11.4 Quantitative Risk Analysis)

The EEFs used as inputs for the 11.3 Qualitative Risk Analysis process and 11.4 Quantitative Risk Analysis include:

  • Industry studies of similar projects by risk specialists
  • Risk databases from industry or proprietary sources

g. OPAs (11.3 Qualitative Risk Analysis and 11.4 Quantitative Risk Analysis)

The OPAs used as inputs for the 11.3 Qualitative Risk Analysis process include

  • Information on previous, similar projects

The next post will cover the last two of the risk management processes, 11.5 Plan Risk Responses and 11.6 Control Risks.

5th Edition PMBOK® Guide–Step 6: Memorizing Inputs & Outputs (Risk Management Part 1)


In this next series of posts on memorizing the processes, we move on to the final step 6, which is memorizing the INPUTS & OUTPUTS associated with each of the 47 processes.   In order to breakdown the memorization into more bite-size chunks, I am breaking down the processes in the 10 knowledge areas into 2 or 3 posts each.

This post covers chapter 11 of the PMBOK® Guide, which covers the Risk Knowledge Area. This knowledge area contains 6 processes, the first five of which are in the Planning Process Group, and the last of which is in the Monitoring & Controlling Group.

I am splitting the discussion of the Inputs & Outputs into three different posts, each covering two processes.   This post will cover Process 11.1 Plan Risk Management and 11.2 Identify Risks.

2.  Review of processes 11.1 and 11.2 together with their ITTOs (Inputs, Tools & Techniques, Outputs)

Process Name Tools & Techniques Inputs Outputs
11.1 Plan Risk Management 1. Analytical techniques2. Expert judgment

3. Meetings

1. Project management plan2. Project charter

3. Stakeholder register

4. EEFs

5. OPAs

1. Risk Management Plan
11.2 Identify Risks 1. Documentation reviews2. Information gathering techniques

3. Checklist analysis

4. Assumptions analysis

5. Diagramming techniques

6. SWOT analysis

7. Expert judgment

1. Risk Management Plan2. Cost Management Plan

3. Schedule Management Plan

4. Quality Management Plan

5. Human Resources Management Plan

6. Scope baseline

7. Activity cost estimates

8. Activity duration estimates

9. Stakeholder register

10. Project documents

11. Procurement documents

12. EEFs

13. OPAs

1. Risk register

In general, the inputs are more numerous and more complicated to remember than the outputs.    This was never more true than in the case of Risk Management processes, especially with these first two processes.    Each process has only one output, but there are 13 inputs to 11.2 Identify Risks, which is an indication of how complex and wide-ranging the information is that goes into the process.

3.  Outputs of processes 11.1 Plan Risk Management and 11.2 Identify Risks

a. Risk Management Plan (11.1 Plan Risk Management)

The main, in fact the only, output of Plan Risk Management is the Risk Management Plan, which consists of the following elements, arranged by category:

Category Plan Element Definition of Element
1. OPAs Methodology Tools and data sources from the organization to be used in risk management.
2. Time Timing How and when risk management activities will be conducted; protocol for application of contingency and management reserves.
3. Cost Budgeting Funds needed for risk management activities
4. Quality Tracking How risk activities will be recorded in order to audit and improve risk management processes.
5. HR Roles and Responsibilities Defines, for each type of activity in the risk management plan, the following:

  • Lead (accountable)
  • Team members (responsible)
  • Support (consult)
6. Communication Reporting formats Defines how the outcomes of the risk management process will be documented, analyzed, and communicated.
7. Risk Risk categories Grouping potential sources of risk on the project, often in the form of a Risk Breakdown Structure (RBS).
8. Probability and impact definitions Different levels of risk probability and impact are defined (low, medium, high, etc.)
9. Probability and impact matrix Grid for mapping the probability of each risk and its potential impact on the project.
10. Stakeholders Stakeholder risk tolerances Stakeholder risk tolerances may be revised during the course of this process.

As you can see, there are many elements of the risk management plan that are related to other knowledge areas.   That is one of the reasons why the inputs come from many of those same knowledge areas.

b. Risk register (11.2 Identify Risks)

The risk register is an output of ALL the processes of risk management.    It starts out as an output of process 11.2 Identify Risks, but information regarding each risk is added in the course of each subsequent planning process.

At this point, after 11.2 Identify Risks, the main elements of the Risk Register are:

  • List of identified risks–sometimes put in a format of “cause-event-effect”, where if a certain cause exists, an event may occur leading to an effect.
  • List of potential responses–although process 11.5 Plan Risk Responses comes later, IF any potential responses to the identified risks are identified even this early i the planning process, they are put in the risk register

4.  Inputs of processes 11.1 Plan Risk Management and 11.2 Identify Risks

a. Project management plan (11.1 Plan Risk Management)

The most important components of the project management plan to be considered an input to this process are the performance baselines of scope, time, and cost.

b. Project charter (11.1 Plan Risk Management)

The project charter may include high-level risks, high-level project descriptions, and high-level requirements.

c. Stakeholder register (11.1 Plan Risk Management)

Provides an overview of the roles of the various stakeholders, which may provides information on how they could be affected by various risks to the project.

d. Risk Management Plan (11.2 Identify Risks)

The elements of the risk management plan that are inputs to the 11.2 Identify Risks process are:

  • Assignments of roles and responsibilities (with regard to risk-related activities)
  • Provision for risk management activities in the budget and schedule
  • Categories of risk (sometimes expressed as a risk breakdown structure)

e. Cost Management Plan (11.2 Identify Risks)

This contains processes and controls that can be used to identify risks across the project.

f. Schedule Management Plan (11.2 Identify Risks)

Provides insight project time/schedule objectives and expectations which may be impacted by risks.

g. Quality Management Plan (11.2 Identify Risks)

Provide a baseline of quality measures and metrics for use in identifying risks.

h. Human Resources Management Plan (11.2 Identify Risks)

Provides guidance on how project human resources should be defined, staffed, managed, and eventually released from the project.   These, together with roles and responsibilities, project organization charts, and the staffing management plan, form a key input in identifying risk processes.

i. Scope baseline (11.2 Identify Risks)

The project scope statement, one of the three components of the scope baseline, contains a list of project assumptions.  Uncertainty in these project assumptions should be evaluated as potential causes of project risk.

The WBS, another component of the scope baseline, is a critical input to identifying risks as it helps one understand the potential risks at a micro and macro and micro level, with risks identified at the level of work package, control account, or summary level.

j. Activity cost estimates (11.2 Identify Risks)

They provide a quantitative assessment of the likely cost to complete scheduled activities and are ideally expressed as a range, with the width of the range indicating the degree of risk.

k. Activity duration estimates (11.2 Identify Risks)

They provide time allowances for the activities or the project as a whole, and like the activity cost estimates mentioned in paragraph j above, expressed as a range, with the width of the range indicating the degree of risk.

l. Stakeholder register (11.2 Identify Risks)

Useful for identifying those stakeholders whom one should approach to solicit inputs to identify risks.

m. Project documents (11.2 Identify Risks)

The following project documents may provide the project team with information on decisions related to risk:

  • Project charter
  • Project schedule and schedule network diagrams
  • Issue log
  • Quality checklist

n. Procurement documents (11.2 Identify Risks)

Procurement documents become a key input to identifying risks associated with the procurements.

o. EEFs (11.1 Plan Risk Management and 11.2 Identify Risks)

The EEFs that are inputs to 11.1 Plan Risk Management include

  • Risk attitudes
  • Risk thresholds
  • Risk tolerances

These provide information that describes the degree of risk that an organization will be able to withstand.

The EEFs that are inputs to 11.2 Identify Risks include

  • Published information, including commercial database and academic studies of risk
  • Published checklists
  • Benchmarking and industry studies
  • Risk attitudes

p. OPAs (11.1 Plan Risk Management and 11.2 Identify Risks)

The OPAs that are inputs to 11.1 Plan Risk Management include

  • Risk categories
  • Risk statement formats
  • Risk templates
  • Roles and responsibilities
  • Authority levels of decision making
  • Lessons learned from previous projects

The OPAs that are inputs to 11.2 Identify Risks include

  • Project files, including actual data on risks from previous projects
  • Organizational and project process controls
  • Risk statement formats or templates
  • Lessons learned from previous projects

You can see by the very long list of inputs that risk management is intimately related to all other knowledge areas.   The uncertainty regarding cost and schedule estimates, for example, is directly related to the degree of risk, which can be examined in terms of its cause by looking at the underlying assumptions behind those estimates.

The process 11.2 Identify Risks is one of the most complicated processes of all the 47 project management processes, and one way to understand this complexity to realize how many different knowledge areas provide inputs to it.   Once you understand this complexity, however, it will give you a new appreciation as to why anticipating problems on a project and preventing them should have a higher priority than simply dealing with problems as they occur.