Project Management Best Practices

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.

Sources:

The Guide to the Project Management Book of Knowledge, 4^th 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