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	Slogan	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	Identify.	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	Prioritize.	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	Examples
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
Organization	Changes to project objectives Lack of priorities Lack of project management "buy-in" and support Inadequate project funding Misallocation and mismanagement of resources
Stakeholders	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
WBS	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
Requirements	Unrealistic or aggressive performance standards Poorly defined requirements Incomplete requirements
Product design	Incomplete product description Unrecognized design errors
Team	Lack of skills Lack of commitment Personal issues
Technology	Missing technical data Use of unproven technology
Network diagram	Missing task dependencies
Assumptions	Not completely defined
Constraints	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	Description	Notes/Examples
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.
Simulation	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	Description	Notes/Examples
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	Thorough	Rapid
Good	.4	.1
Fair	.5	.2
Poor	.1	.7

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	Value	Thorough	Outcome Value	Rapid	Outcome Value
Good	$2M	.4	$800K	.1	$200K
Fair	$500K	.5	$250K	.2	$50K
Poor	$200K	.1	$20K	.7	$140K

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

			Thorough		Rapid
Market Reaction	Value	%	Outcome Value	%	Outcome Value
Good	$2M	.4	$800K	.1	$200K
Fair	$500K	.5	$250K	.2	$50K
Poor	$200K	.1	$20K	.7	$140K
EVM			$1.03M		$110K

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	Description	Examples/Notes
Avoidance	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.
Acceptance	"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.
Mitigation	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.
Transference	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.