Risk Management

Friday, December 2nd, 2011

An often neglected, yet essential, element of project and program management is project risk management.

Project Risk Management is concerned with the identification and planning for potential risks that may impact the project (both positive and negative impacts).

Risks can be positive (Opportunities) or negative (Risks or Threats).

* Positive Risks:

  • Per-GB cost of storage may decrease during the course of the project
  • Scope of data conversion work may turn out to be less than we anticipated

* Negative Risks:

  • Commercial software product may not perform as expected
  • Degree of software modification may turn out to be greater than we anticipated

Note: Risks and Opportunities are not mirror images of each other. For one thing, a risk that has a less negative impact than expected can be considered a positive risk, though it may not necessarily offer an opportunity. In addition, definitions of opportunities are usually less precise than definitions of risks.

Risk has two primary components for a given event:

  • A probability of occurrence of that event
  • Impact (or consequence) of the event occurring (amount at stake)

Issues vs. Risks

There is some confusion between issues and risks. While both issues and risks have consequences (impact), the probability (and, to some extent, the time) dimension is different.

A risk is an event or situation that may possibly, but not necessarily occur, in the future. The probability can range from 0% to 100%. An example: possible loss of key staff members. When risks are identified ahead of time, we can determine mitigations and responses to prevent the risk from becoming an issue.

An issue is a situation that either is currently occurring or will occur in the future. It’s usually unexpected or has a low enough impact and/or probability that developing a mitigation or response was a low priority and, therefore, not part of the risk register (see below). The probability is 100%. An issue that has occurred or is currently happening is referred to as a problem. An example: upcoming termination of vendor support for an older release of a software product. When we know that the end-of-support date is approaching, it becomes an issue. When the date is actually upon us, it becomes a problem. When we know that an issue is coming up, we can try to take steps to deal with the issue before it becomes a problem. Too often, however, issues arise unexpectedly and immediately and must be addressed immediately.

Steps in the Project Risk Management Process

Project risk management proceeds as follows:

  1. Early in the planning, the project lead defines how risk management will be conducted for the project. The output of this activity is the risk management plan which becomes part of the overall project plan.
  2. The project lead then works with project team to identify the project risks and conducts qualitative and quantitative analyses of the risks to determine the probabilities and impacts of the risks.
  3. After scoring the risks based on the probabilities and impact, the top risks are identified and a risk mitigation / risk response plan is developed defining the actions to be taken in the event of those risks.
  4. Throughout the duration of the project, as part of monitoring & controlling, the risk responses are carried out (when needed), new risks are identified, and previously identified risks are re-evaluated for any changes in their impact or probability. As a result of these activities, the schedule and/or cost baselines may be modified.

Risk mitigation vs. risk response.

Risk mitigation is a planning technique used to reduce the probability of  a risk occurring or reduces the impact to an acceptable threshold.

Risk response is the action to be taken in the event that the risk actually occurs. As each risk in the risk register is identified, one or more responses to the risk are determined and documented. Creating the risk register along with risk mitigation and responses is important:

Imagine this scenario. Due to the complexity and unique nature of your organization’s business processes, the development of the business rules for a new ERP system is taking 3 times as long as expected. When the project sponsor asks about this set-back, you reply, “I knew this was going to happen!”

If you don’t have risk response previously identified, then the sponsor can ask you, “if you knew this was going to happen, why didn’t you have a response plan in place?!?”

Another element of risk is cause. The existence of something or the lack of something can cause a risky or dangerous situation to exist. The source or cause of this situation is referred to as a hazard. The degree of risk can be viewed as a function of hazards vs. safeguards where safeguards mitigate the level of risk. For example, lack of technical knowledge can be a hazard that can be mitigated by training.

The risk management processes occur throughout the project life cycle – starting with risk identification during the Planning phase, continuing with risk analyses and the creation of the risk register.

The risk register is reviewed during project monitoring:

  • Changes in the project plan can lead to additional risk identification.
  • The occurrence of a previously identified risk can result in changes to the project plan.
  • Scope changes can result in new risks. Scope changes can also result in the elimination of previously identified risks.

Look for Upcoming Post: Project Risk Management vs. Enterprise Risk Management (ERM).

Sources:

The Guide to the Project Management Book of Knowledge, 4th Edition (PMBOK Guide), ©2008, Project Management Institute

Practice Standard for Project Risk Management, © 2009, Project Management Institute

Project Management: A Systems Approach to Planning, Scheduling, and Controlling, Tenth Edition, by Harold Kerzner, John Wiley & Sons © 2009

© 2011, Jerry Bucknoff, MBA, PMP
Sphere: Related Content

Upcoming Article on PM Best Practices

Thursday, May 27th, 2010

Watch this spot

Project Management Lessons Learned from the Apollo Moon Landing Project

Monday, November 23rd, 2009

Looking at the Apollo program, we can see a very vivid (and real life) example of how the Triple Constraint works in a large, very expensive, politically charged and highly visible project.

Project: Put a man on the moon

“First, I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the Moon and returning him back safely to the earth.” (President John F. Kennedy, Joint Session of Congress on May 25, 1961)

Scope: Landing a man on the Moon AND returning him safely to Earth

Time: Before the decade is out

Cost: Whatever Congress will approve

Triple Constraint

What are the immutable constraints here?
(more…)

Sphere: Related Content

The P3MO (Part 2) – Best Practices

Monday, November 9th, 2009

High-level View of Project, Program, and Portfolio Management

In part 1 of this series, we defined the P3MO as an acronym for “Project, Program, and Portfolio Management Office.” It’s based on the concept of a PMO (project management office)  elevated to cover project portfolio management as well as project and program management. In part 2 we will discuss the relationship between the three components of the P3MO: project management, program management and portfolio management.

Project management ensures the successful completion of initiatives and their associated deliverables within the time, scope and cost parameters agreed to by the end-users of the product, service or result. The project manager manages stakeholder expectations and communication between all team members and stakeholders.

P3MO Relationship Venn - Click on image to enlarge

P3MO Relationship Venn - Click on image to enlarge

Program management provides overall leadership and vision to the project management process. The program manager is responsible for delivering value to the community of stakeholders.

Portfolio management aligns the portfolio of projects and other work with the objectives of the organization and ensures that the work delivers value to the business.

The relationship between projects, programs and portfolios

Portfolios are made up of projects, programs and other work. (Other work includes on-going operations, ad-hoc activities and other “business as usual” work.)
(more…)

Sphere: Related Content

The P3MO (Part 1) – Best Practices

Saturday, October 31st, 2009

My experience at PMI’s 2009 North America Congress was excellent and, as always, well worth the trip. I met and exchanged ideas with some of the top practitioners, researchers, consultants and authors in the project management industry.

Management PlanningThere is no doubt about it. The benefits realized from a sound and well-organized project management methodology based on globally recognized project management standards have been well established. These benefits cannot be overstated. Organizations that make full use of the power of a project-focused environment gain a competitive advantage over those organizations that do not leverage this power. They also gain a competitive advantage over those organizations that publish an “official” project management standard but make little or no attempt to implement it or to make it a part of organizational policy. *

One of the hot project management topics at the Congress was the P3MO (project, program, portfolio management office). Another was that of “value driven project management”, the topic of Harold Kerzner’s closing session speech and the topic of his new book, co-authored with Frank P. Saladis.  An integrated project portfolio management environment (i.e., a P3MO) with a focus on driving business value represents the state-of-the-profession thinking right now. I can personally confirm that this approach is beginning to emerge out in the field. At my most recent client, a global life insurance company doing business on three continents, my colleagues and I recommended exactly this approach and delivered guidelines for achieving this. **

(more…)

Sphere: Related Content