3 Factors in Risk Management: Probability, Impact, and Velocity

Risk Score

Qualitative and Quantitative Analyses in Project Risk Management both take into account Probability (P) and Impact (I). A Risk Score is the product of the two.
Qualitative Analyses use subjective estimates of probability and impact as a screening process that categorizes risks for management, monitoring, or ignoring. Risks placed in the management category go on to Quantitative Analysis and Risk Response Planning.

What about Urgency?

A third value should be considered: Velocity (V), which is the inverse of the time-to-impact.
Seldom can we deal with all risks at once. The value of considering Velocity lies in prioritizing further effort so you have enough time to respond to urgent risks. We would not consider Velocity when assigning risks to the three categories because we want to deal with the important things, not the urgent things. (Consider Pareto's 80/20 rule.)
If Probability times Impact describes an area, then to be consistent, we would add Velocity as a third dimension. That is,
Priority Score = Priority x Impact x Velocity

Another View of the Priority Score

Priority times Impact has another label, which is Expected Monetary Value (EMV). EMV is often used by itself for guiding decisions. If we express the Priority Score as
Priority Score = EMV x Velocity
then we give EMV a weight equal to the weight of Velocity.
The reason we would not consider the Velocity by itself goes back to the principle about the cost of rework. The later you deal with a problem, the more it costs because you have to repeat and fix work that came before. The previous effort becomes wasted, costs rise, schedule lags, and you have to use extra resources to get back on schedule.
Similarly, the longer you wait to deal with a risk, the more rework you have to do. Therefore, we need to factor both Velocity and EMV into prioritizing work: Velocity to deal with urgent risks, and EMV to control costs.

A New Step: Priority Analysis (when needed)

I recommend inserting a new step into Risk Management when there are risks with high velocity and you have to prioritize which risks to deal with first:

1. Qualitative Analysis with Risk Score = estimated Priority x estimated Impact
2. Priority Analysis with Priority Score = EMV x Velocity = Priority x Impact x Velocity
3. Quantitative Analysis with Risk Score plus other factors such as Velocity and Cost Effectiveness

I bring up Cost Effectiveness because you want to ensure that you don't spend $150 to prevent a risk whose EMV is only $100.

Reference

Hall, Harry, PMP, PMI-RMP. 30 Quick Risk Evaluation Tips. PM South. http://www.pmsouth.com/2015/07/18/30-tips/. Accessed 21 July 2015.

What to Call Risk and Opportunity Management

Many writings lump risk management and opportunity management together under the label, Risk Management.  Risks and opportunities are left-pointing and right-pointing rays on the same line.

Many equate risk with probability, so they drop opportunity from the label. They think of risk as an abbreviation for risk and opportunity. Others worry, then, that opportunity will be forgotten -- as it usually is!

When one speaks of risk [and opportunity], one speaks of the probability that something will happen. That is,

Risk = Probability x Impact, where Impact is a loss

and

Opportunity = Probability x Impact, where Impact is a gain

If risks and opportunities are rays pointing left and right, then opportunities are negative risks. If you deal with them in the same matrix, pay extra attention to your negative signs.

Risk and opportunity management can result in influencing the probability, influencing the impact, or other strategies such as accepting a potential loss or waiting to deal with situations when and if they become an issues.

(Remember that a situation is a risk if the probability lies between zero and one.  A situation is an issue if the probability is one.)

Uncertainty Management

Could we simply call it Uncertainty Management?  Uncertainty would only deal with influencing the probability that something will occur. The face-value of the term fails to imply the other strategies for dealing with risks or opportunities. The name of this knowledge area should reflect the highest-level concepts, not a component concept.

Opportunities and Threats

Another pairing of terms comes from SWOT analysis - Strengths, Weaknesses, Opportunities, and Threats. SWOT analysis is one technique for identifying risks and opportunities.

Opportunities and threats, as a pair, emphasizes the influences or situations that affect or can be affected by a person or project. (In fact, threat implies that the risk event comes from outside, whereas risks can be either internal or external.)  SWOT analysis emphasizes identification of risks. It makes up only a fraction of the whole set of risk and opportunity management processes.

A Common Risk:  Failing to Deal with Opportunities

Many people forget to manage opportunities with the same vigor that they apply to managing risks.  Exploiting opportunities can mitigate the potential impact of risks. The reasoning goes, Risk A may set us back a week, but Opportunity B may save us a week.

PMs have other reasons to exploit opportunities.   Exploited opportunities cut costs, relieve schedule pressure, and improve quality. In short, they maximize profit.

Failure to exploit opportunities wastes resources, causes product lines to stagnate, erodes market share, and results in lost jobs (perhaps your job!) when the company withers.

The failure to exploit opportunities is itself a fundamental risk.

Therefore, referring to the practice as Risk and Opportunity Management calls attention to the oft-forgotten second half of the discipline. 

Remember that semantics is about communicating, not about winning arguments.  If somebody refers to risk management, you know what they mean.  Adjust.

Copyright 2011, 2013, Richard Wheeler -- Permission granted for non-profit or personal use with a link to this post.

IT Metrics and Productivity Institute (ITMPI) Premium membership gives members free access to 400 PDU-accredited webinar recordings and waives the PDU processing fees. The library is growing at about 100 webinars per year. Check it out: http://mbsy.co/dPHm?s=e

Differences between Risks and Issues in Projects, Part 1

Differences between Risks and Issues in Projects, Part 1

Issues

Updated 1 June 2014

People define issue in many ways, but in project management, issue has a special meaning.

In everyday English, one synonym for issue is topic. An issue is a situation that merits discussion. For example, the issue, what caused the last ice age or is man's contribution to climate change significant compared to factors such as volcanic ash and the variability of our star.

Everyday issues include past, present, and future situations. Discussions about issues may or may not lead to actions. Often, when we say that something is an issue, we imply that people disagree about it.

In project management, an issue is a situation that merits consideration because it affects the project. For example, the vendor left our parts to rust on the dock and will not ship them until they get paid, but our policy prohibits paying for the shipment until we receive and inspect it.

If the issue is significant, the project team will study actions that would reduce or remedy the situation effects on the project. This leads to change requests.

Part 2 (click here) focuses on the definition of risk and explains a side of risk that most PMP prep materials overlook.

Copyright 2013, 2014 Richard M. Wheeler

Understanding the Rule of Seven

Context: Discussion of the Rule of Seven in statistical process control 

Problem: In some industries, one cannot wait for repeatable errors as defects and errors lead to loss of life. I was told that, in pharmaceuticals, a certain % of death is acceptable and almost expected. The waiting process or period of time before halting tests or evaluations is where I am stuck.

First, let's use the terms specified value and control limit rather than errors or defects.

 

Also, we would normally discuss this topic in terms of parameters that have numeric values such as temperature, weight, and speed. In this conversation, we want to deal with measurable characteristics long before they result in catastrophic failures.

Rule 1. Out-of-bound conditions

If you have just one value outside the control limits, such as a severe side effect from a drug, you stop the process and figure out what went wrong. 

Rule 2. Calibrating the results

The Rule of Seven (or Run of Seven) does not apply to parameters that go outside the control limits. The Run of Seven applies when seven consecutive, acceptable values lie on the same side of the specified value. Such a situation indicates that the average has deviated from the desired value and you need to recalibrate the process so that the average is close to the specified value.

Illustrating with a made-up scenario

Suppose the scientists at Schpooky Pharmaceuticals want to test an inoculation against the HG (Heebie Geebie) virus. In order to train the immune system to fight off a full invasion of Heebie Geebies when somebody sneezes on us, the inoculation has to cause a fever of at least 0.5 degree F. They calibrate the variables in making the vaccine and in the dosage to cause a 1.0 degree F fever, or a temperature of 99.6 degrees F.  In this test, they set an upper control limit of 3.0 degrees, or a temperature of 101.6 degrees F.

 

Specifications:

• T = 99.6 degrees F, average
• 99.1 degrees F < T < 101.6 degrees F

Using the first rule, just one person develops a temperature of 103.0 degrees F. We stop the tests to see what's gone wrong because 103.0 > 101.6, the upper control limit.

 

Using the second rule, if we have seven consecutive people develop fevers between 99.6 and 101.6, we stop the tests to see what's gone wrong. These temperatures are all acceptable, but they are all greater than the desired value.

 

The Run of Seven indicates a special cause -- that is, one or more variables in the process need to be controlled. Maybe the dose is too large and needs to be reduced. Perhaps the HG virus needs to be baked five minutes longer. So we make the adjustments and then resume the trial.

 

These rules and others like them serve to stop a process long before it reaches catastrophic failure such as the death of a patient.

But catastrophic failures do happen

You might wonder, What about the catastrophic failures? They do happen! What about the one in 10,000 who dies? How can that be acceptable?

 

This takes us to other techniques such as Decision Tree analysis (p. 299 of the Project Management Institutes Project Management Body of Knowledge (PMBOK) Guide, 4th edition).

 

Suppose withholding the vaccine results in 1,000 deaths per 10,000, but giving the vaccine causes one death in 10,000. If you distribute the vaccine to 10,000, you save 999 lives.

 

Unfortunately, many drug companies withhold such drugs because that one in 10,000 will sue them, and the juries will severely punish the companies.

 

This issue, tort reform, is one of the dividing lines between the political parties in the US. A project manager needs to use various decision-making methods and maintain awareness of a wide range of environmental factors.

Project Management and Open Communications

Project Managers need to guard against setting up an environment where bad news never reaches them. They need to praise and encourage those who communicate risks before they become issues, issues before they become problems, and problems before they become project failures.

Some managers remind me of the Clinton trial in the Senate, following his impeachment in the House.

The Senate set up a rule requiring Ken Starr to keep all the records and evidence in another building. Bringing it to their offices without an invitation would have violated protocol.

Then the majority of senators refused to go view the evidence. A few who did view it said they came away weeping, and the rest (having refused to view the evidence) said that they lacked evidence sufficient to convict.

Does your comfort zone tempt you to maintain willful ignorance? Does your character allow reliance on plausible deniability? The PM has accountability for project success, which any lack of awareness may bring about; but that accountability extends to achieving success ethically.

 

I wonder:  Do PMs ever include ethical lapses as project risks?

The Lobbyist on the Project Management Team

You are the project manager in an aircraft manufacturing company developing a new range of supersonic fighter planes. Since government approval and involvement are essential, you hire a lobbying firm to get government support to prevent unnecessary changes in your project. Which process is this an example of? (Source unknown)

While aircraft manufacturers conduct some research into designs and materials that they can incorporate into new aircraft, governments usually sponsor development of fighter jets.

 

Scope creep happens in almost all defense projects.

 

For example: 

• The Defense Department wants the aircraft to provide certain capabilities for the Air Force.
• Then the Navy wants compromises in the design so the jets can take off from carriers.
• The Army and Marines add their particular use cases.
• Allies want introperability with their systems.
• Later, one politician wants to cut costs,
• another wants the aircraft to use inadequate landing gear designed by the manufacturer in his home town,
• and over 600 politicians and thousands of bureacrats want to influence the project.
• Meanwhile, competitors and the nation's adversaries develop new technologies to which the designers must respond.
• And one of the political parties, along with the press, begin mocking your aircraft by calling it an Imperial Tie Fighter.

If you let it, the politics will multiply the cost twentyfold, drag out the schedule an extra 15 years, and make your company a laughingstock. By the time of the first production run, the aircraft will already be obsolete.

 

The same sort of changes can happen in any project. One way to control the risk of scope change is to refuse to make changes, but too little flexibility can create customer dissatifaction and cost you future business.

 

For a better way to reduce the risk of scope creep, maintain close personal relationships with the stakeholders, keep them informed of the costs of changes, and negotiate agreements that best serve the business case.

 

The PM cannot always do this, so the company hires a lobbyist with exceptional people skills and knowledge of the bureacratic systems. The lobbyist uses various methods to convince the politicians and bureaucrats to resist tinkering with the project requirements.

 

In process terms, hiring a lobbyist does not proceed from the Project Communications Management processes. Lobbying does not contribute directly to producing the product or providing a service. A first pass through the Identify Stakeholders and Plan Communications processes would assume everything goes as planned and would focus on required reporting and coordination. The lobbyist's job goes far beyond that.

 

If the team identifies scope creep as a risk, they make a note to consider it later when they follow the Identify Risks process. They would, at that time, add recruiting a lobbyist to the Risk Management Plan portion of the integrated Project Management Plan.

 

Don't forget that, as a member of the project team, the lobbyist becomes a stakeholder. For example, the team must add the lobbyist's tasks to the WBS and estimated costs during the next iteration of project planning. They must also consider the lobbyist's information needs during the next iteration of the Project Communications Management processes.