A Brief Overview of a Complex Topic
Bill Hoberecht - This email address is being protected from spambots. You need JavaScript enabled to view it.         

Becoming familiar with the organization and structure of Risk Management activities is a necessary precursor to building a solid competency in managing the risks of your project.  Project Managers who overlook the need for risk management on their projects end up exposing their projects to unnecessary threats and probably leave unnoticed opportunities untapped.  This article summarizes a PMBoK-based framework for Risk Management.


Risk Management – Simple, yet Complex

Risk Management, like so many other project managements topics, is at once both simple and complex.  At a high level the concepts seem reasonable and easy to comprehend, but when it comes time to apply risk management to a project numerous complications arise: confusing terminology, an unclear or undefined set of actions to take in managing risks.  Quite frequently the result is a very flawed implementation of risk management – an implementation where risk management is almost purely administrative (with lots of activity but no real management of risks) or where confusion reigns and the project fails distinguish between the two very different concepts of risks and issues.

This article introduces the basic framework of risk management – the purpose of this article is to provide a project team with a brief, easily understood structure for managing risks on their project.  This article focuses on this framework and how to execute risk management on your project – this is a 10-minute introduction to a topic that is far more complex.  Accompanying articles present the importance and relevance of risk management along with many references to other expert resources on risk management.

The information in this article is primarily based upon the PMI’s PMBoK, but the PMI isn’t the only authoritative source of information on the topic.  My short list of reference information goes beyond the PMI and includes: SEI, DOD, Prince2 and several published authors.  Unfortunately, each of these expert sources has created their own terminology and process framework for risk management, leaving project management in a somewhat confused state on this topic. 


Uncertainty is the Breeding Ground for Risk

Project managers are in the business of organizing teams of individuals to achieve a specified goal.  A large part of a project manager’s job is getting a good definition to the work steps that must be completed and then ensuring that these work items are all completed as needed.  We would all enjoy a higher degree of project success if the job was as simple as: understand the goal, plan the activities and execute those tasks.

Problem is, every project environment has some degree of uncertainty caused by factors that might be internal or external to the project. This uncertainty might make it easier for the project to complete or it may introduce problems that make it more difficult for the project to complete.  Recognizing and understanding this uncertainty is a core project management responsibility, and comes under the banner of ‘risk management.’

Effective management of project risks has these components:

  1. Use of a process framework that organizes the tasks of risk management.  There is no need to invent one for your project; several substantially similar frameworks exist, are well documented, and could be the basis for your risk management activities.
  2. Universal use of a risk management process.  Starting with training for all who are involved in risk management activities and a continuing expectation that the process is used to the benefit of the project.
  3. Depth of skills in risk identification, risk analysis and planning.  Having a widespread ability in the project team to dig sufficiently into a possible problem or opportunity, understand its potential impact on the project, and create the proper actions to take as a response to the risk.


A Well-Formed Risk Statement

Sometimes a novice to project management will declare a project risk using general language such as “The project is at risk of running over budget.”  While this could be a helpful statement, in that it gives an alert that there could be some undisclosed problem that might cause the schedule to be missed, it is certainly not a sufficiently complete statement of a project risk.  Indeed, this alarmist statement could potentially be interpreted as a pre-emptive excuse for an upcoming project failure.  When the budget does overrun, the project manager can legitimately look back and say, with integrity, that early notice was given of a potential problem.  In effect:

  • This poorly formed risk statement: “The project is at risk of running over budget”
  • Uses risk management jargon to communicate this message: “The project may overrun the budget by some unknown amount, but it is not my fault and there is nothing I am doing about it.”

In general an ineffective or incomplete risk statement is not helpful in actually managing a risk.  Managers and stakeholders who are presented with incomplete statements will almost always go down one of two paths:  instruct the project manager to go back and do a better job at risk management (by identifying and analyzing risks and producing a set of complete risk statements) or by jumping in and micromanaging the project’s risk management activities (disempowering the project manager).  Prevent either of these reactions by always preparing and using well-formed risk statements.

A well-formed risk description contains this information:

  • The Risk Cause: describes project decisions or conditions that may give rise to the Risk Event.  This provides context information about the risk.
  • The Risk Event: describes the possible future event or circumstance that affects your project and introduces uncertainty.
    • The risk likelihood indicates the probability that the risk event will occur.
      • Typical quantitative measures are Very High, High, Medium and Low. 
      • A quantitative measure would be a specific probability greater than 0% but lower than 100%.
    • A risk trigger is an identified measure or indicator that signals to the project that the risk event has occurred.
  • The Risk Impact: the anticipated effects on the project’s ability to execute planned activities and successfully achieve its objectives.
    • This risk impact describes a specific impact to the project’s defined scope, schedule, cost and quality objectives.
    • Initially, might be qualitative: Very High, High, Medium and Low
    • Some risks may undergo further analysis and have quantitative impacts

Here’s an example of a well-formed initial risk statement – the first version of the risk statement is in italics, the rest of the text was added in a second examination of this risk; more accuracy and detail would be added as the risk is analyzed.

  • Cause: Our project requires installation of a new server and we decided to have an external vendor install the software; many subsequent project tasks are dependent upon installation of the new server.
  • Event: There is a very low chance that the vendor will be late installing the new operating system; previous experience with this vendor has shown very good performance in completed their work as contracted.  If the vendor is late by two weeks,  
  • Impact: then our delivery of new features will be four weeks later than committed and project costs will increase by about 10%.

Here’s a second example:

  • Cause:  Our project is hiring a new technical designer. We’ve interviewed several candidates and just extended an offer of employment to our first choice for the position.
  • Event:  We know that the candidate is speaking with other prospective employers and don’t know if the candidate favors our offer of employment.  We would guess that we have a 50% chance that our offer will be accepted.  If the candidate accepts our offer of employment and starts work on the project within a month  
  • Impact: then our time to design the new system will decrease by at least two full months.


An Overview of a Risk Management Process

As in other aspects of project management, there is no universally agreed process definition for Risk Management.  Fortunately, just about all the process definitions that I’ve seen have many common elements.  Unfortunately, slight terminal differences and differences in representation make it unlikely that all project managers have the same lexicon and process steps for risk management.  (An accompanying article on Risk Management provides pointers to various risk management processes).

Here’s a straightforward risk management flow, based upon Risk Management as defined in the PMBoK:


Risk Management Process – Primary Flow 


Risk Management Process Overview


This representation appears as a linear set of steps, but this depiction is just to introduce the organization of the process steps.  Risk Management in practice is not nearly so linear and has multiple feedback paths.  As well, reporting and audit processes surround this primary flow.

Risk Management starts early in the life of a project.  It starts during project planning and is continuously executed throughout the life of the project.  Risk management is not standalone, but is integrated with many other project management processes.

Risk Management Planning

Risk Management Planning is usually performed only once, during project planning.  However, if the project experiences a significant change (e.g., scope, personnel, schedule) then the Risk Planning process would be re-visited concurrently with any overall project re-planning.  Decisions made during this planning establish the approach to risk management for the project and define how to conduct risk management activities for the project, including:

  • Selecting or creating the Risk Management Process
  • Selecting or creating the Risk Management toolset
  • Establishing a risk repository and defining risk reporting templates
  • Training project team in risk management
  • Constructing the project’s Risk Management Plan


Risk Identification

Risk Management would be fruitless without any risks to consider and act upon – Risk Identification activities are focused on identifying those potential risks that pose opportunities or threats to the project. Risk identification determines which risks might affect the project and identifies some of their characteristics.

Risk identification is executed continuously during a project’s life; it is first performed during Project Planning to identify an initial set of project risks.  This activity results in the first version of the project’s Risk Register, which shows all identified risks and other related information.  It is executed periodically, as scheduled in the Risk Management Plan, to identify new risks that may have surfaced or become apparent as project conditions have changed.

Effective risk identification is heavily influenced by the experience of project team members and others who participate in risk identification activities.


Qualitative Risk Analysis

Naming a risk and adding it to a project’s risk register is important, yet this accomplishment doesn’t give us sufficient information about the significance of the risk to the project.  Risk Analysis, shown in this process flow as the two distinct steps of Qualitative and then Quantitative Risk Analysis, prioritizes risks for further analysis and risk response planning.  It is through this analysis that the project team identifies the most significant risks and targets those risks requiring immediate or near-term attention.

Qualitative risk analysis supplements information assembled during risk identification and adds new information for each risk about the probability (typically using a High/Medium/Low scale or some other scale that has a limited number of choices) of the risk occurring and the risk impact (again, using a High/Medium/Low or other limited scale).  This analysis also results in a relative priority of each risk (relative to the other identified risks).  This priority is used to focus attention on most significant risks.

Qualitative Risk Analysis is performed periodically during a project’s life, and is explicitly executed as the list of identified risks change and as project conditions change.


Quantitative Risk Analysis

Think of Qualitative Risk Analysis as a low-cost, streamlined activity that tells the project team which risks warrant further attention.  Quantitative Risk Analysis is an in-depth investigation of significant risks that were prioritized during Qualitative Risk Analysis – not all risks merit this level of examination. 

Quantitative Risk Analysis assesses a range of project outcomes based upon risks, and will almost always make use of advanced analysis, modeling and simulation techniques.  Quantitative Risk Analysis is sheer joy for those who crave a numerical description of risks, providing meaningful figures (e.g., probability of achieving project cost and schedule) under a variety of conditions and assumptions.  As in Qualitative Risk Analysis, this process step gives a prioritized list of project risks – this list is a key consideration in planning risk responses.

The Risk Management Plan should explicitly decide, based upon several factors, whether quantitative risk analysis is appropriate for your project.  On smaller projects or those projects with few significant risks, quantitative risk analysis may not provide any additional insights beyond the information generated during qualitative risk analysis.  Quantitative risk analysis is an advanced skill that may be unfamiliar to the project team, and there may be no opportunities to acquire or build this skill for your project.  This project management skill may not be present within the project or executive team - project executives and stakeholders may not comprehend the significance of the generated analysis and as a result may not be able to use this information in making decisions.


Risk Response Planning

Risk Response Planning develops options and selects actions to take that will enhance opportunities (positive risks) and reduce threats (negative risks) to the project’s objectives.  The focus of attention is on priority risks, with little or no effort devoted to lesser risks.   This is performed periodically during a project’s life as Qualitative or Quantitative Risk Analyses produce updated risk information.

The results of Risk Response Planning are added to the project’s risk register, including, for each priority risk:

  • Classification of the Risk Response (i.e., mitigate, transfer, avoid, accept, exploit, share, enhance)
  • Assigned risk owner and, where actions are needed, an agreed schedule of actions
  • Risk trigger identification, along with the monitoring method


Risk Monitoring and Control

Risk Monitoring and Control is continuously performed during a project’s life, and is the primary means of ensuring that risks are being handled properly on a project.  Through Risk Monitoring and Control activities, the project incorporates newly arising risks into the Risk Management activities and monitors previously identified risks.   This process step ensures that the project always has a valid list of risks to be managing and that proper action is being taken for all prioritized risks.

Risk monitoring includes reviewing the project’s implementation of the risk response plan, keeping tabs on the most significant project risks and revising information in the risk register about each identified risk.  Risk control activities ensure that risk identification, analysis and response activities are repeated as project conditions necessitate, as well as conducting risk reassessments, risk reviews, and risk audits.  These activities collectively result in periodic revisions to the priority list of risks, risk response plans and status of risk responses actions that are underway. 


Various Risk Management Process Definitions

The six-step process I've presented above is only one of several possible ways to view the activities of Risk Management.  Here are a few of the most widely recognized high level representations of the Risk Management process.

 PMBoK Risk Management Process

PMBoK – Risk Management as defined by the PMI, from A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fourth Edition

The PMBoK shows relationships between Risk Management processes and the many project management processes, reinforcing the notion that Risk Management is not standalone, but is integrated with other project management activities.

 DOD Risk Management Process

Risk Management as outlined by the DOD, from Risk Management Guide for DoD Acquisition (Sixth Edition, Version 1.0)

Prince2 Risk Management Cycle

Risk Management as outlined in Prince2 2005 (obsolete; replaced by Managing Successful Projects with PRINCE2: 2009).

Management of Risk Framework from OCG
Management of Risk Framework from the OCG.  A similar approach to risk management has been incorporated into Prince2: 2009.
 IEEE Risk Management Process

Risk Management as outlined by the IEEE, from IEEE Std 1540-2001, “IEEE Standard for Software Life Cycle Processes – Risk Management.”


What’s Next?

This article has barely scratched the surface of the complex topic of Risk Management – you might even recognize most of the information presented here.  However, before rushing to implement Risk Management on your project you will want to become familiar with details of each step in the Risk Management process, be aware of some very valid alternatives to the Risk Management process outlined here, and other implementation details.  An accompanying article supplies many references to other expert resources on risk management that can help you on your implementation journey.