6th Edition PMBOK® Guide–Process 11.2 Identify Risks: Tools and Techniques


Identification of risks is something which requires the project manager to cast the net far and wide in order to find sources that will give information on potential risks to the project.   These range from the usual “generic” tools and techniques of expert judgment and meetings, to those more specific to this risk management knowledge area, especially in the area of data analysis.

11.2.2.1 Expert Judgment

Experts should be consulted who have expertise in individual project risks (especially those who were involved previously in similar projects) and those stakeholders with a grasp of risk management who can weigh in on the overall project risks based on their expertise in the field.

11.2.2.2  Data Gathering

There are many ways of gathering data regarding risk:  through written documents (checklists), through interviews with individual stakeholders, and group meetings with project team members and stakeholders in order to brainstorm regarding potential sources of risk.

  • Brainstorming–ideas are generated under the guidance of a facilitator either in a free-form fashion or by using more structured techniques.   A particular useful starting point for these discussions is the Risk Breakdown Structure, which categorizes risk by its potential source.
  • Checklists–this is using lists of potential risks that were developed based on previous similar projects.   Of course, even if a previous project was similar, care must be taken to account for the differences by going over all risks on the checklist to make sure they actually apply in the current project.
  • Interviews–conversations with stakeholders and subject matter experts in the field of risk management can be used to get contributions to the list of potential risks on the project.

11.2.2.3  Data Analysis

  • Root cause analysis–just as root cause analysis can be used to discover the underlying causes that lead to an actual problem (a defect), it can also be used to identify the causes of a potential problem.   You start with the potential problem, such as cost overruns and schedule delays, and go back to find out those factors which might lead to this problem.
  • Assumption and constraint analysis–a project is conceived with a set of assumptions and within a series of constraints (schedule, cost, quality, scope, etc.).  The validity of these assumptions and constraints are analyzed to determine which pose a potential risk to the project.
  • SWOT analysis–if you take positive and negative factors both internal to and external to the project organization, you will get the strengths/weaknesses (internal), and opportunities/threats (external) to the project, which is wear the acronym SWOT comes from.
  • Document analysis–project documents, particularly the project charter, are analyzed to get high-level risks on the current project, and project files from previous similar projects are also analyzed to get the individual risks from those projects.

11.2.2.4  Interpersonal and Team Skills

Especially when using the data gathering technique of brainstorming, it requires special skills to be a facilitator of one those sessions because you have to encourage an open mode of discussion where ideas will not be shot down when given by any member of the discussion group, thus encouraging creativity in the process.

11.2.2.5  Prompt Lists

This is a predetermined list of risk categories.   A checklist is a list of actual risks from previous projects; the prompt list just gives the risk categories, and is a useful tool to be used in conjunction with the brainstorming technique mentioned in the paragraph 11.2.2.2 above.

11.2.2.6  Meetings

Like putting together the WBS, putting together a list of potential risks requires brainstorming which is best done in the setting of a group meeting.

The next post will cover the outputs of this process.

Advertisements

6th Edition PMBOK® Guide–Process 11.2 Identify Risks: Inputs


After the first planning process which creates the Risk Management Plan, which shows how to do risk management on the project, this is the first process that starts of considering individual risks on the project.

Risks are found among all the other constraints on the project, so the inputs will come from the knowledge areas for scope, schedule, cost, quality, and resources.   In particular, you will want to look at the management plans for these knowledge areas, the three performance baselines (scope, schedule, and cost), and project documents from these knowledge areas.

11.2.1  Identify Risks:  Inputs

11.2.1.1  Project Management Plan

The components of the overall project management plan that are inputs to this process include:

  • Requirements management plan–the requirements management plan may indicate which project objectives that are particularly at risk
  • Schedule management plan–the schedule management plan may identify areas that are subject to uncertainty or ambiguity with respect to the schedule.   Note:   activities on the critical path will automatically be of higher risk to the project, as any delay in their execution will result in a delay in the final deadline of the project.
  • Cost management plan–the cost management plan may identify areas that are subject to uncertainty or ambiguity with respect to the budget.
  • Quality management plan–the quality management plan may identify areas that are subject to uncertainty or ambiguity, or where key assumptions with regards to quality have been made that might give rise to risk.
  • Resource management plan–the resource management plan may identify areas that are subject to uncertainty or ambiguity, or where key assumptions with regards to critical resources have been made that might give rise to risk.
  • Risk management plan–includes the following elements relevant to this process:
    • Lists risk-related roles and responsibilities on the project
    • Indicates how risk management activities are included in the budget and schedule
    • Describes categories of risk
  • Scope baseline–indicates deliverables in the scope statement which might give rise to risk.   The WBS can be used as a framework for identifying individual risks.
  • Schedule baseline–May be used to identify milestones and deliverable due dates that are subject to uncertainty or ambiguity, or where key assumptions with regards to the schedule have been made that might give rise to risk.
  • Cost baseline–May be used to identify costs or funding requirements that are subject to uncertainty or ambiguity, or where key assumptions with regards to costs have been made that might give rise to risk.

11.2.1.2  Project Documents

  • Assumption log–assumptions and constraints recorded in the assumption log may give rise to individual project risks and may also influence the level of overall project risk.
  • Cost estimation–cost estimates provide quantitative assessments of project costs, ideally expressed as a range, indicating the degree of risk, where a structured review of the documents may indicate that the current estimate is insufficient and poses a risk to the project.
  • Duration estimation–duration estimates provide quantitative assessments of project durations, ideally expressed as a range, indicating the degree of risk, where a structured review of the documents may indicate that the current estimate is insufficient and poses a risk to the project.
  • Issue log–issues recorded in the issue log may give rise to individual project risks and may also influence the level of overall project risk.
  • Lessons learned register–this is where lessons learned during the process of risk identification will be recorded and reviewed in later processes of the project to determine whether similar risks might recur during the remainder of the project.
  • Requirements documentation–the project requirements should be analyzed during this process to identify those that could be at risk.
  • Resource requirements–resource requirements provide quantitative assessments of project resource requirements, ideally expressed as a range, indicating the degree of risk, where a structured review of the documents may indicate that the current estimate is insufficient and poses a risk to the project.
  • Stakeholder register–Indicates which individuals or groups might participate in identifying risks to the project.   It also details those individuals who are available to act as risk owners.

11.2.1.3  Agreements

If the project requires the external procurement of resources, the agreements may have information such as milestone dates, delivery dates, contract type, acceptance criteria, and awards and penalties that can present threats or opportunities.

11.2.1.4  Procurement Documentation

If the project requires the external procurement of resources, the initial procurement documentation should be reviewed, because procuring goods and services from outside the organization may increase or decrease overall project risk and introduce additional individual project risks (for example, if the procurement of a critical component has a delay in the delivery date).

11.2.1.5  Enterprise Environmental Factors

  • Published material, including commercial risk databases or checklists
  • Benchmarking results
  • Industry studies of similar projects

11.2.1.6  Organizational Process Assets

  • Project files, including actual data and checklists, from previous similar projects
  • Risk statement formats
  • Organizational and project process controls for risk

The next post will cover the tools and techniques of this process.

 

6th Edition PMBOK® Guide–Process 11.1 Plan Risk Management: Outputs


This post covers the outputs of the process 11.1 Plan Risk Management.   Actually, there is only output and that is the Risk Management Plan.   Here are the elements that should go into such a plan:

  • Risk strategy–the organization’s general approach to managing risk on projects
  • Methodology–specific approaches, tools (like the probability and impact matrix) and data sources that will be used to perform risk management on the project.
  • Rules and responsibilities–who is the lead of the risk management team and who are the team members?   Who will support the activities within the organization?  What are the specific responsibilities of each member of the team?
  • Funding–this clarifies the protocols for application of contingency and management reserves.   Remember, contingency reserves are for those risks that are on the risk register (the “known unknowns”) vs. those risks that are not (the “unknown unknowns.”
  • Schedule–defines when and how often risk management processes will be performed throughout the project life cycle, and establishes those risk management activities that will be included into the project schedule.
  • Risk categories–a risk breakdown structure or RBS is a representation of potential sources of risk on a project.   Creating an RBS helps the project team consider the full range of sources from which individual project risks may arise.
  • Stakeholder risk appetite–this should be expressed in terms of measurable risk thresholds around each project objective in order to determine the acceptable level of overall project risk exposure.
  • Definitions of risk probability and impact–used in process 11.3 Perform Qualitative Risk Analysis, the probability and impact matrix divides these concepts into qualitative thresholds like “low”, “medium” and “high”.   The definition of these thresholds is important to establish at the beginning of the project.
  • Probability and impact matrix–not only the definitions of the individual thresholds, but how these thresholds will interact must be determined ahead of time.   Also, the overall strategies of dealing with these categories should be defined.   Will the company accept those risks in the “low” category, mitigate those in the “medium” category, and avoid those in the “high” category, for example?
  • Reporting formats–this shows how the outcomes of the risk management process 11.6 Implement Risk Responses and 11.7 Monitor Risks will be reported to stakeholders.
  • Tracking–shows how risk activities will be tracked using the risk register and how risk management activities will be audited.

The next process starts the specific risk management planning process of identifying risks.   The inputs to that process are in the following post.

6th Edition PMBOK® Guide–Process 11.1 Plan Risk Management: Tools and Techniques


The process of creating the Risk Management Plan is like all the similar processes for other knowledge areas.   Consequently, there are some tools and techniques which are “generic”, that is, common to all of these processes that create a management plan that is a component of the overall Project Management Plan.    One tool and technique, Data Analysis, uses stakeholder analysis and is specific to this particular process.

11.1.2.1  Expert Judgment

In creating the risk management plan, it’s pretty clear that you will want to consult with SMEs (subject matter experts) who have expertise in the area of risk management.   This may include the following:

  • Experts in risk management in general, especially those who are familiar with the organization’s approach to risk management
  • Those who have handled risk management on other similar projects and who can therefore advise on the types of risk likely to be encountered on the current project

11.1.2.2   Data Analysis

Stakeholder analysis can be used to determine the risk tolerance of key stakeholders on the project.

11.1.2.3 Meetings

Project team members, members of the organization who are responsible for risk management, and key stakeholders are those whom you want to invite to meetings to discuss the risk management plan.   The meetings will define the risk management activities that will be done in all of the other six processes in this knowledge area.

The next post will be the outputs of this process, the main one being the Risk Management Plan.

6th Edition PMBOK® Guide–Process 11.1 Plan Risk Management: Inputs


Although risk management is among the most complex of the knowledge areas when it comes to the planning process group, the first process is the same as all the others.   It is Plan Risk Management, which has as its output the Risk Management Plan.   This post goes over the inputs to this process.

11.1.1  Plan Risk Management:  Inputs

11.1.1.1  Project Charter

The project charter contains a high-level project description and project boundaries, meaning not just what is within the scope of the project but also what is excluded from the scope.   High-level risks that the project sponsor is aware of and is concerned about can be put in the project charter as well.   That’s why it’s the first course for a project manager to find out about the risks associated with the project.   Sometimes there is a connection between the high-level scope description, including the exclusions, and the high-level description of the risks.   It may be possible that something may considered “out of bounds” for the project for the very reason that it represents taking on a higher risk than the sponsor it comfortable with.

11.1.1.2  Project Management Plan

All of the components of the project management plan, particularly the subsidiary management plans for all the other knowledge areas, and the additional ones having to do with requirements (dealing with scope management), and change/configuration management (dealing with integration management), are all sources of risk and so any risk management plan needs to be consistent with these other components.

11.1.1.3  Project Documents

The stakeholder register is probably the most important input for this process.   You will want to discuss their attitude towards overall risk, as well as getting their opinion on the identification of individual risks on the project.

11.1.1.4  Enterprise Environmental Factors

Overall risk thresholds set by the organization or by key stakeholders will influence how much risk you intend to take on during the course of the project.

11.1.1.5  Organizational Process Assets

  • Organizational risk policy
  • Risk statement formats, templates for the risk management plan, risk categories organized into a risk breakdown structure, and common definitions of risk concepts and terms
  • Authority levels of decision making (this will affect your risk responses)
  • Roles and responsibilities within the organization, especially as it pertains to risk management
  • Lessons learned repository from previous similar projects

The next post will cover the tools and techniques of this process.

6th Edition PMBOK® Guide–Chapter 11 Risk Management: Key Concepts


Before I go through the 7 project management processes associated with the Risk Management knowledge area, I thought I would cover some concepts, many of which are covered in the introductory section to this knowledge area which starts on page 397 of the PMBOK® Guide but some of which are not and are based on my reading of the material.

  1. “Risk” definition–the actual definition of risk in PMI 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 risk in “real life” is usually an event that has a potential negative effect, but the risk definition in PMI is wider in that it includes positive effects as well, or what we would normally refer to as an “opportunity” as opposed to the normal meaning of the word which refers to “threats.”   I would not say, for example, that “there’s a risk of my having a good time at the office party” (unless I were being ironic or sarcastic).  But in PMI parlance, this use of the word risk to cover positive opportunities is okay.
  2. Risks and stakeholders–a stakeholder is a “person … that may affect the outcome of a project.”   Note the similarity between the definition of a stakeholder and that of a risk, of an event which may affect the outcome of a project.    The difference?   One is human and one is not.   That’s why we refer to stakeholder engagement but risk management.    You can engage stakeholders and reason with them (or most of them, at any rate), and perhaps manage their expectations.   You can’t, however, argue with the weather and cajole it into doing what you want.   You can prepare for the event of bad weather if it occurs by avoiding it or mitigating it by taking along an umbrella (or using the expanded definition of risk, by taking advantage of good weather).    But you need to take into account both risks and stakeholders, because both can influence your project.
  3. Overall vs. individual risk–individual risks have to do with specific events, but overall risk has to do with uncertainly on the project as a whole.   A company has a certain risk tolerance as part of its organizational culture, and this tolerances refers not to individual risks but to risks in general.   A start-up company is going to be more risk tolerant than an established organization, for example, because the very process of setting up such a company is laden with risks to begin with.   On the other hand, companies that are industry leaders may find that they have to be more risk tolerant in order to maintain their lead position (to take advantage of opportunities which may expand their market).
  4. Known vs. unknown risks–Donald Rumsfeld, the Secretary of Defense under George Bush, gave the risk management world a colorful way of phrasing the difference between known vs. unknown risks:  he called known risks the “known unknowns” and contrasted them with the “unknown unknowns.”   Known risks are “known unknowns” because you know or anticipate that they may happen, but you  don’t know whether they will happen or not.   “Unknown unknowns” are those risks which you don’t anticipate.   This is not just a theoretical concept:   there are very real differences in the way they are handled.   Known risks are put in the risk register, and you create risk responses for them which are funded out of contingency reserves.   Unknown risks are not put in the risk register, of course, for the very reason that they are unanticipated.   If they do occur, since you don’t have a plan for a risk response, you have to come up with an out-on-spot solution called a “workaround” which is funded out of management reserves.
  5. Risk and probability–Do you have a risk of dying?   The answer is no because there is no risk involved:  it is a certain event.    The mortality rates that actuarial statistics measure involve the question of how old you will be when you die, which is a different matter because that involves an uncertainty or probability.    One of the things that makes risks manageable is the “law of large numbers”, which is a principle of probability according to which the frequencies of events with the same likelihood of occurrence even out, given enough trials or instances.   So the risks that often occur are the ones that you can predict a probability of occurring with a certain level of confidence.   The unknown risks are those that are unpredictable because they are fortunately rarer.
  6. Risks vs. issues–a risk is a potential event, which if it occurs, no longer becomes a potential problem, but an actual problem called an issue.   Once a risk occurs and becomes an issue, it is dealt with on the issue log, rather than on the risk register.
  7. Risk management flow–here’s the flow of processes for the risk management knowledge area.
    1. Plan–Create a plan for how you will manage risks on your project (gives guidelines on how to do all the other processes)
    2. Identify–Think of all the risks you can that may occur on a project.
    3. Perform Qualitative Risk Analysis–Classify the risks identified in step 2 according to a subjective scheme (low, medium, high) and come up with a strategy of how to deal with them based on the classification.   Low risks you may want to just accept; medium risks you will want to mitigate or insure against, and high risks you may want to do what you can to avoid them.
    4. Perform Quantitative Risk Analysis–Take the risks identified in step 3 that you plan to mitigate or insure against, and come up with an estimate of the cost risk involved.
    5. Plan Risk Responses–Take the risks identified in step 3 that you plan to mitigate and come up with a plan for how to mitigate the probability of their occurring, or the impact on the project if they do happen to occur.   Come up with reserves that will fund these risk responses based on the cost analysis done in step 4.
    6. Implement Risk Responses–in the course of a project, respond to risks as they occur based on the plan developed in step 5.
    7. Monitor Risks–if risks do not occur, then modify the risk register to reflect this; if new risks are identified, add to the risk register developed in step 2.

Next I will discuss the inputs, tools and techniques and outputs for the seven processes of risk management outlined above…

6th Edition PMBOK® Guide–Process 10.3 Monitor Communications: Outputs


As I mentioned in the previous two posts on the a) inputs and b) tools and techniques of this process, the process of Monitor Communications really consists of two parts:

  • Monitoring communications to compare the actual work done on communications (by looking at the Work Performance Data–one of the inputs of the process) with what is set out in the Communications Management Plan (another input of the process):   the results of this comparison are considered to be Work Performance Information (see paragraph 10.3.3.1 below)
  • Controlling communications so that if a variance between the actual communications and the planned communications is discovered, the source of the variance is determined and a Change Request is made to resolve it (see paragraph 10.3.3.2 below).   The change proposed may be in the communications themselves or in the communications plan (see paragraph 10.3.3.3 below), with possible changes to the project documents (see paragraph 10.3.3.4 below).

10.3.3  Monitor Communications:  Outputs

10.3.3.1 Work Performance Information

The whole point of this process is to compare how the communications on the project are actually performed (the Work Performance Data input to this process) and compare it with the results that were planned in the Communications Management Plan (another input to the process).   This comparison is the Work Performance Information, which should be analyzed by the project team to get their feedback and that of stakeholders regarding the effectiveness of the communications.   Any proposed changes should take be made as formal Change Requests (see next paragraphs).

10.3.3.2  Change Requests

These outputs then become inputs of the process 4.6 Perform Integrated Change Control.

The change may be to communications to put them more in line with what’s in the Communications Management Plan, or it may be to the plan itself if the original plan turned out to be either unrealistic or if the stakeholders have changed their requirements with regards to those communications.  (They may request more frequent information about the project as they become more aware of its impact, for example.)

10.3.3.3 Project Management Plan Updates

As mentioned above, the process may result in changes to the project management plan, in particular those components that have to do with communications:

  • Communications Management Plan–any updated are included to the plan to make communications more effective
  • Stakeholder engagement Plan–if the situation of stakeholders change and they want additional information about the project, these changes are reflected in the stakeholder engagement plan

10.3.3.4 Project Documents Updates

  • Issue log–issues related to communication will be updated on this log
  • Lessons learned register–if issues related to communication are resolved, the resolution and the corrective actions chosen will be updated in the lessons learned register so that communications can be made more effective for the rest of the project.
  • Stakeholder register–if stakeholders have any changed requirements with regards to communications, these changes are updated in the stakeholder register.

And that, my friends, is the last post for the Communications knowledge area.   Next is one of the biggest and more important knowledge areas covering Risk Management.   I will start the next post with the inputs to process 11.1 Plan Risk Management.