I’ve compared projects with living entities (like human beings), and the life cycle of a project with life cycle of a person. Similarly, the PMBOK guide, when expanded, is called project management body of knowledge or a body of knowledge for project management. Like every human being has a body which he or she needs to be aware of, every practicing project manager needs to be aware of the body of knowledge for project management.

Your body consists of many critical organs such as brain, heart, kidney, liver, etc. As such, the project management body of knowledge (or PMBOK) consists of many key organs, which PMI calls as knowledge areas. These are identified project management areas defined by knowledge requirements and various components such as processes. Examples of such knowledge areas can be project scope management, project schedule management, and project cost management, among many others.

In this article, we will discuss one of the more important knowledge areas, project risk management. It’s a key organ in the body of knowledge for project management. In the latest edition of the PMBOK guide, the processes, interactions among the processes, and key documents associated with risk management have changed significantly. I’ve also found in my interactions with project managers and risk managers that many struggle with these concepts.

Process Flow in Risk Management

Let’s talk about the process flow and overall interaction in the risk management knowledge area.

1. First, the risk management plan is prepared in Plan Risk Management process. This plan tells how you are going identify, analyze, manage, and monitor the risks.
2. Next, we identify all possible individual project risks, as well as overall project risk in the Identify Risks process. This process creates two project documents – the risk register and the risk report. Identified individual risks become part of the risk register, and the risk report has information on the overall project risk and also summary level information of individual project risks.
3. As we have a lot of individual risks in the risk register, we cannot manage them all. Hence, the first prioritization of risks happens in the process of Perform Qualitative Risk Analysis (or Perform QLRA). This step is mandatory. The higher the priority of the risk, the higher the ranking of the risk in the register.
4. We also have a second level of prioritization of risks where we quantify them in terms of schedule and/or cost. This is done in Perform Quantitative Risk Analysis (or Perform QTRA) process. This step is optional. In this process, we look for combined effect of individual risks on the overall project objectives. Here we get the overall risk exposure for the project and it’s documented in the risk report.
5. In the next process of Plan Risk Responses, we plan for the responses of the risks, (risks that we have prioritized earlier). The risk responses are developed both for individual prioritized risks and overall project risk, and documented in the risk register and the risk report, respectively.
6. Then, in the Implement Risk Responses process, we implement or execute the risk response plans for both prioritized individual risks and the overall project risk in order to address the project risk exposure.
7. Finally, we monitor the set of finalized and prioritized risks throughout the life cycle of the project. This happens in Monitor Risks process and means that we monitor both the risk register and the risk report.

The interaction among the processes are depicted in the below diagram.

As shown in the above figure, all the processes from Plan Risk Management to Implement Risk Responses interact with each other. The process of Monitor Risks is the umbrella process which “overlooks” the rest of the six processes. The dotted line between Perform QLRA process to Perform QTRA process indicates that the former one is mandatory, whereas the latter is optional.

At this stage, we’ve looked at two project documents – the risk register and the risk report – while explaining the process interactions, but you might be wondering what they contain.

The Risk Register

The risk register is a key project document used in many other knowledge areas and many other processes. Here are the top points about the risk register:

• It’s a repository in which the outputs of project risk management processes are recorded.
• It primarily contains the information about individual project risks.
• It’s progressively elaborated throughout the processes of risk management knowledge area.

Some important fields in the risk register are:

• Risk Identifier (ID) – It uniquely identifies the risk. The ID is set when the risk is first created.
• Risk Title – It’s usually a short, one-line description of the risk.
• Risk Status – It tells the current status of the risk. It can be proposed, open, closed, assigned, managed etc.
• Risk Category – This informs the category of the risk, which can be taken from the risk breakdown structure (RBS). Examples of categories can be technical, resource, internal, external etc.
• Risk’s SWOT Value – This is determined by doing a strength, weakness, opportunity or threat (SWOT) analysis, and it tells if risk is a threat or an opportunity.
• Risk Owner – This informs who will own the risk.
• Risk Probability (P) – It’s the chance of occurrence of the risk.
• Risk Impact (I) – It’s the effect or impact of the risk.
• Risk Score – This is calculated by multiplying the probability (P) and impact (I).
• Risk Cause – The cause(s) of the risk.
• Risk Effect – The effect(s) of the risk on one or more project objectives.
• Risk Trigger – It informs on what events or conditions the risk can happen.
• Risk Response Strategy – This field notes the response strategy for individual risks. One or more strategies can be applied.
• Risk Response Actions – These are actions associated with the strategies.
• Risk Action Owner – This informs who will own the risk response action.

A Sample Risk Register

In the real world, you can use any risk management software tool, a simple spreadsheet, or MS Excel, to create a risk register. A sample risk register looks like the one shown below. I’ve broken it down into two parts because of large number of fields in the risk register. The first part of the risk register has information on risk identifier, title, status, category (which can be mapped to the RBS ID), SWOT value, risk owner, probability and impact values, and risk score.

For the second part, the risk IDs have been maintained so that you can associate the risks with their respective fields. Here, we have cause, effect, risk response strategy, response actions, action owners, and risk review details.

The risk register can have other details such as contingency plans, fallback plans, secondary risks, and a watch-list. You can add these fields into the above template when you create your own risk register.

The Risk Report

The risk report is another key project document, which is also used in many other knowledge areas and processes. Here are the top points about the risk report:

• It primarily contains the information about overall project risk and a summary level information about the individual project risks.
• It informs on the overall project risk exposure.
• It’s also progressively elaborated throughout the processes of risk management knowledge area.

Some significant components in the risk report are:

• Overall project risk: The sources of overall project risk which drives the overall project risk exposure. It informs on the probability of meeting:
  • Schedule target
  • Cost target
• Summary information of individual project risks: Overall detail of individual project risks.
  • It will be updated with prioritized list of risks as you pass through various processes of risk management.
• Risk sensitivity analysis:
  • You can have sensitivity analysis for duration, cost, tasks and risks.
  • Criticality analysis of the project tasks can also be shown.
• Calculated contingency reserve for the project.
• Audit details.
• Summary conclusion.

A Sample Risk Report

You can create risk report using any software tool such as MS Word/MS Excel. A sample risk report looks like the one shown below. In the first part of this report, you have a summary of the project plan, then overall project risk exposure details and finish date probabilistic analysis.

In the second part of the report, we have duration sensitivity analysis, risk register summary details, audit information, and summary conclusion.

Expanded Flow of Processes in Risk Management

Now that we know the contents of the risk register and the risk report, let’s extend the risk management process flow with these two documents. See the figure below.

As you can see, after the risk register and the risk report are created in Identify Risks process, they are passed through subsequent processes of risk management knowledge area.

Now, let’s check what happens in each of these processes.

Plan Risk Management process:

The risk management plan will have:

• Strategies and approaches to manage the risks of the project.
• Categories of risks represented in a breakdown structure known as risk breakdown structure (RBS).
• Probability and impact definitions of risks as well the probability and impact matrix.
• Risk appetite and risk threshold values of stakeholders.
• Risk related roles and responsibilities.
• The format and content of risk register and risk report.

Identify Risks process:

The risk register will be created the first time with:

• List of all identified individual risks.
• Potential risk owners, i.e., if you can have a risk owner, you can assign him/her in this process. The final risk owner will be confirmed in Perform QLRA process.
• Potential risk responses, i.e., if you can have risk responses, you can note these responses in this process. The final risk responses will be confirmed in Plan Risk Responses process.
• The individual risks will have other details such as risk ID, title, category, status, cause(s) and effect(s).

The risk report will also be created the first time having:

• Sources of individual project risks.
• Summary information about individual project risks.

Perform Qualitative Risk Analysis (QLRA) process:

In the QLRA process, both the risk register and the risk report will be updated with:

• Probability and impact values of the individual risks.
• The score of the risk, which is basically a multiplication of probability and impact values. It has been shown earlier in the sample risk report.
  The risk owner will be confirmed in this process.
• A watch-list containing low priority risks will be created here and it will be part of the risk register.

The risk report will be updated with:

• The prioritized list of individual project risks.
• A summary detail of the risk register.
• A summary conclusion.

Perform Quantitative Risk Analysis (QTRA) process:

In the QTRA process, only the risk report will be updated. It will have:

• Overall project risk exposure assessment along with information on meeting the schedule and cost targets. These we have seen earlier in the sample risk report.
• Probabilistic analysis of the project with S-curves, histograms, sensitivity analysis, criticality analysis. Our sample risk report contains results of S-curve and sensitivity analysis. To understand more about criticality analysis, you can refer an earlier published article.
• Contingency reserve information can be part of the risk report as well. An earlier article explains on it with an example.
• Prioritized list of individual project risks. The risk exposure of the individual project risks can also be part of the report.

Plan Risk Responses process:

In this plan risk responses process, both the risk register and the risk report will be updated. The risk register will be updated with:

• Risk response strategies for individual project risks. The risk responses will be confirmed here.
• For every response, you can response actions for which risk response action owners will be noted.
• Contingency plan and fallback can be developed here.

The risk report will be updated with:

• Risk response strategy for overall project risk.
• The summary level information of the high-priority individual project risks.

Implement Risk Responses process:

In this process, both the risk register and the risk report may be updated. This process implements the risk response plans created in Plan Risk Responses process. The risk register may be updated to have any changes to the earlier risk responses for individual project risks, whereas the risk report may be updated to have any changes to the earlier risk responses for the overall project risk.

Monitor Risks process:

In this process, we monitor the risk register and the risk report, which may be updated. The risk register can be updated with:

• New risks that are identified.
• Current status of the existing risks, e.g., the change in status, probability value, impact value, score etc.
• Closure of outdated risks.

The risk report can be updated with:

• Current status of the overall project risk.
• Current status of the prioritized individual risks.
• Conclusion and recommendations from risk audit.

Summary Video

Finally, a summary video on risk management, which captures the essence of processes and their interactions in project risk management knowledge area. (Duration: 5m 28s)

For aspiring Project Management Professionals (PMPs) and Risk Management Professional (RMP), understanding of the new risk management framework and process interactions are crucial before getting diving deeper into individual processes. It’s also foundational if you are preparing for the Certified Associate in Project Management (CAPM) examination. I hope the information I’ve presented in this article helps to build your foundation of knowledge on the new risk management framework knowledge center.

References

[1] PMP Live Lessons, PMBOK 6^th Edition – Guaranteed Pass or Your Money Back, by Satya Narayan Dash
[2] Project Management Body of Knowledge (PMBOK) Guide, 6^th Edition, by Project Management Institute (PMI)