Risk Management Principles and the PMI Philosophy

To best understand how risk management affects project planning and to better prepare yourself for exam questions on risk management, you need to understand some key risk management principles and the PMI risk management philosophy. Specifically, you should know the following:

  • The key PMI risk management principles

  • The common gaps with implementing risk management

  • The different types and the common sources of project risk

  • Key risk management tools

  • Data precision and other uncommon risk terms

  • How to use decision tree analysis to determine the best alternative

  • The types of risk response strategies


If you only read one chapter in the PMBOK, read the "Project Risk Management" chapter.

This area often has more differences between "real-life" experiences and the PMI methodology, and the exam questions concerning risk management are generally based on the PMBOK material.

Key PMI Risk Management Principles

The PMI risk management philosophy is an approach that remains consistent with PMI's core beliefs that project management is proactive and that the project manager should be and remain in control of the project at all times. PMI supports the belief that effective risk management can reduce project risks by up to 90%. Not only will effective risk management reduce project risks, but it will also lead to much better project decision making and to a higher degree of project success.

The key principles to remember about the PMI risk management approach include the following:

  • The level, type, and visibility of risk management should be consistent with the level of risk and the importance the project has to the organization.

  • The organization must be committed to risk management for the entire project lifecycle.

  • Any factor or risk that could impact the project should be identified, quantified, and assessed for possible impacts to the project.

  • For each identified risk, both the probability that it will occur and its possible impact to any project objective are determined

  • The identification of risks is an iterative process. Risk identification is repeatedly performed throughout the project, not just at the beginning.

  • The identification of risks is a continual process throughout the project.

  • Quantitative analysis is generally reserved for high-probability, high-impact risks.

  • Risk management will change the project plan during the Planning, Executing, and Controlling phases.

  • The risk response plan is updated whenever a risk occurs.

  • A risk can be good (opportunities) or bad (threats).

  • Five of the six risk management processes are in the Planning process group.

  • Risk management planning and risk response planning are two distinct activities.


Project risks can be reduced by up to 90% if they are properly managed.


A risk can be good or bad. Good risks are opportunities, and bad risks are threats.

The Common Gaps with Implementing Risk Management

The PMI risk management process is generally much more involved and disciplined than what most project managers use in "real-world" situations.

One of the best ways to learn the steps in the PMI risk management process is to review the common differences noted by many project managers, as detailed in Table 5.10.

Table 5.10. Summary of Common Risk Management Gaps

Risk Management Process


Common Gaps

11.1: Risk Management Planning

Plan the activity.

No risk management plan.

Risk management plan equals risk response plan.

Separate budget not allocated for risk management.

11.2: Risk Identification


Performed only once and not proactively managed.

Process is incomplete.

Missing a review of key deliverables.

Missing entire types/categories of risk.

Only assessing critical path activities.

The process does not use multiple tools/methods.

Confusing issues with risks.

11.3: Risk Qualitative Analysis


The organization has not established standard practices/tools.

The probability of occurrence is not calculated for each risk.

The impact of each risk is not determined.

Risks are not prioritized.

Data precision is not determined.

11.4: Risk Quantitative Analysis

Measure implications.

Not performed at all.

Usage is not limited to high-priority risks.

No experience with Monte Carlo simulation.

11.5: Risk Response Planning

Create a plan of attack.

Response strategies are not documented.

No risk response plan.

Response strategies are not appropriate for risk severity.

The project plan is not updated to implement and monitor responses.

11.6: Risk Monitoring and Control

Keep it going.

The risk response plan is not maintained.

Risk identification is not continued.

The project plan is not updated to implement and monitor responses.

Responses are not reevaluated.

The Common Sources of Project Risk

An activity that can help prepare you for the risk management exam questions is to pretend you have been asked to perform a risk assessment on a troubled project. Where would you start? What would you look for? In Table 5.11 we list some of the common sources of project risk to help you get in the proper mind set.

Table 5.11. Common Sources of Risk

Risk Source


Project management

Improperly defined project deliverables

Incomplete planning

Improper procedures

Poor leadership

Poor communications

Not clearly assigning tasks

Lack of contingency plans

Inadequate risk management


Changes to project objectives

Lack of priorities

Lack of project management "buy-in" and support

Inadequate project funding

Misallocation and mismanagement of resources


All key stakeholders not identified

Missing "buy-in" from a key stakeholder

Stakeholder needs not completely identified

Project charter

Not approved by a single person

Nature of objectives

Scope statement

Incomplete scope definition

Inconsistent scope definition


Not reviewed and approved by stakeholders

Missing tasks

Lack of team understanding

Missing project management activities

External dependencies not identified and understood

Project schedule

Incomplete schedule

Unrealistic schedule

Resources not balanced

Resources over-allocated

Missing dependencies

No contingency allowances (reserves)

Not reviewed and approved by stakeholders

Cost baseline

Poorly developed cost estimates


Unrealistic or aggressive performance standards

Poorly defined requirements

Incomplete requirements

Product design

Incomplete product description

Unrecognized design errors


Lack of skills

Lack of commitment

Personal issues


Missing technical data

Use of unproven technology

Network diagram

Missing task dependencies


Not completely defined


Not completely defined

External dependencies

Changing weather conditions

Changes in legal and regulatory environment

Approvals from governmental agencies

Key Risk Management Tools

One aspect of the risk management process described in the PMBOK that many people find difficult to grasp initially is the reference to unfamiliar tools and techniques. Table 5.12 summarizes many of these tools and techniques to assist your learning and review process.

Table 5.12. Summary of Risk Management Tools

Risk Tool



Risk impact matrix

Used to establish the impact score to assign to the risk.

Measures the level of impact against standard project objective areas.

Refer to Figure 11-2 in the PMBOK.

Generally developed at the organizational level to improve the consistency of risk rankings.

Probability/impact matrix

Used to establish general High, Medium, and Low classifications for a risk factor.

Cross-references the probability score with the impact score.

Refer to Figure 11-3 in the PMBOK.

Generally developed at the organizational level to improve the consistency of risk rankings.

Overall risk ranking

A project-level score used to compare the relative risk of one project with another.

Output of Qualitative Risk Analysis

Decision tree analysis

Uses a decision tree to determine the best alternative path.

Based on risk probabilities and cost/reward of each path step.

Refer to Figure 11-6 in the PMBOK.


Captures risk probabilities at the detailed task level to determine potential impacts at the overall project level.

Refer to Figure 11-7 in the PMBOK.

Monte Carlo is the most common simulation technique.

Data Precision and Other Uncommon Risk Terms

Another aspect of the PMI risk management process that many people find difficult to understand is the reference to uncommon terms or the use of terms in an unfamiliar context. Table 5.13 summarizes and explains many of these terms to assist in your learning and review process.

Table 5.13. Uncommon Risk Management Terms

Risk Mgmt Term



Data precision

Describes the extent to which the risk is known and understood

Accounts for the amount of available data, the reliability of that data, and the source of the data

Residual risks

Risks that remain after the risk response has been implemented


Secondary risks

New risks that occur as a direct result of an implemented risk response

Should be managed like any other project risk

Risk trigger

An indication that a risk has occurred or is about to occur

Warning signs and risk symptoms

Sensitivity analysis

A technique used to determine which risks could have the greatest impact on the project

Focuses on the uncertainty level of the individual risk factor when all others are held constant

How to Use Decision Tree Analysis

Decision tree analysis, also known as risk tree analysis or probability tree analysis, is a technique that graphically represents the costs associated with decision alternatives and potential risks. For the exam, you will need to be able to do three things to answer decision tree analysis questions correctly:

  • Draw a decision tree to represent the situation described.

  • Calculate any missing outcome values or probabilities.

  • Figure the expected monetary value (EMV) of each decision path.

The best way to quickly review this technique and to prepare for these types of exam questions is to walk through a typical decision tree scenario. Let's take a look at such a creature.

A Sample "Decision Tree" Problem

You are managing a strategic software development project, and are attempting to "sell" to the executive sponsor the benefit of adding 3 months onto the project timeline for thorough design and testing processes. You decide to use a decision tree to illustrate your case.

The values to the organization of good, fair, and poor market reactions to the new software application are $2M, $500K, and $200K, respectively.

You determine the following probabilities of the market reactions based on the use of both thorough and rapid software engineering practices:

Market Reaction












Here are the questions you'll need to answer:

  • What is the expected monetary value of using thorough software engineering practices?

  • What is the expected monetary value of using rapid software engineering practices?

  • If the cost of an additional 3 months is $100K, which decision should be made?

To begin, let's draw the decision tree. The tree should have a path for each decision alternative, and the total probabilities of each uncertain outcome should equal 100%. Figure 5.2 shows what the decision tree for this problem should look like.

Figure 5.2. Decision tree example.


Now, let's calculate the value of each outcome:

Market Reaction



Outcome Value


Outcome Value



















Next, we can calculate the expected monetary value of each decision alternative:





Market Reaction



Outcome Value


Outcome Value
























So, let's take a look at the original questions:

  • What is the expected monetary value of using thorough software engineering practices?

    Answer: $1.03M

  • What is the expected monetary value of using rapid software engineering practices?

    Answer: $110K

  • If the cost of an additional 3 months is $100K, which decision should be made?

    Answer: The use of thorough software engineering practices. ($1.03M minus $100K equals $903K, which is greater than $110K.)


You will see at least one decision tree risk analysis question on the exam.

You should be able to determine the expected monetary value (EMV) of each alternative path.

Types of Risk Response Strategies

Unless you have utilized a risk management methodology or have taken a risk management course, you may not have realized there are four recognized risk response strategies. Most people tend to think "mitigation" strategy when they think of how to manage a risk factor. For the exam, you will need to completely understand the four risk response strategies described in the PMBOK and be able to identify examples of each response type. Table 5.14 summarizes each response strategy and provides examples of each.


You should be able to identify examples of the four types of risk response strategies.

Table 5.14. Summary of Risk Response Strategies

Risk Response




Avoiding the risk.

Changing the project plan to eliminate the risk.

Changing the project plan to protect a project objective from the impact.

Reducing the scope to remove high-risk tasks.

Adding resources or time.

Adopting a proven approach rather than a new one.

Removing a "problem" resource.


"Accepting" the consequences of the risk.

The project plan is not changed to deal with the risk.

A better response strategy cannot be identified.

Active acceptance.

Contingency allowance (reserves).

Contingency plan.

Fallback plan.

Passive acceptance.

No action.

Notifying management that there could be a major cost increase if this risk occurs.


Taking action to reduce the likelihood the risk will occur.

Taking action to reduce the impact of the risk.

Reducing the probability is always more effective than minimizing the consequences.

Adopting less complex approaches.

Planning on more testing.

Adding resources or time to the schedule.

Assigning a team member to visit the seller's facilities frequently to learn about potential delivery problems as early as possible.

Providing a less-experienced team member with additional training.

Training the team on conflict-resolution techniques.

Deciding to prototype a high-risk solution element.


Transferring ownership of the risk factor.

Shifting the consequence of a risk and the ownership of the response to a third party.

Does not eliminate the risk.

Outsourcing difficult work to a more experienced company.

Fixed price contract.

Contracts, insurance, warranties, guarantees, and so on.

Used most often for financial risk exposure.

PMP Exam Cram 2. Project Management Professional
PMP Exam Cram 2. Project Management Professional
Year: 2003
Pages: 169

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net