Project Management/PMBOK/Risk Management

From Wikibooks, open books for an open world
Jump to navigation Jump to search

Risk Management's goal is to increase the impact and probability of positive risks and decrease them for negative risks. The point is not only avoiding failure, but to bring about opportunities. Time and energy can be spent avoiding, transferring to a third party, and mitigating potential failures. They can be similarly spent on accepting, sharing with third parties and enhancing opportunities. It is task of Risk Management to determine how much time and energy should be on avoiding failures and promoting opportunities.

Risk management includes six main processes in PMBOK theory[1]. These are risk management planning, risk identification, qualitative risk analysis, quantitative risk analysis, risk response planning, and risk monitoring and control.


[edit | edit source]

In the Risk Management Planning' process, it is decided how to execute the risk management activities of a project. The level of risk management is decided as it needs to be in line with the risk and importance of the project as a whole. This way resources can be properly alloted at this stage.

Risk Planning is usually the last project management process to be completed during the planning phase as the overall plan and scope are needed to find out where risk management tasks can be allocated.


[edit | edit source]

There are four inputs within the PMBOK model[2]. Enterprise Environmental Factors involve the attitudes and policies set down by the organization that sets the levels and tolerance of risk that is deemed acceptable. Organizational Process Assets are possible predefined risk management approaches set down by the organization. These may include templates, roles, authority levels, risk categories, and definitions. The last two inputs are the Statement of Scope (from the Project Scope Management) and Project Management Plan (from Project Integration Management).

Techniques and Tools

[edit | edit source]

The project team has meetings to set out the basic plans for Risk Management throughout the project. These include budgeted cost, scheduled time, assigned responsibilities, and established risk templates. Establishing the risk templates includes customizing the risk categories and definitions for organizing risk levels, probabilities, and impact.


[edit | edit source]

The output of the planning process of Risk Management results in a methodology, roles and responsibilities, budget, schedule, risk categories (possibly including a Risk Break Structure), the definitions of risk probability risk impact (these can be numerical or relative "very unlikely"), probability and impact matrix, a revised stakeholders' tolerance, formats for any reports, and documentation of how the risk management aspects of the project will be tracked.


[edit | edit source]

The goal of risk planning is to establish how the overall risk management will be conducted for the project. The time spent, the role and responsibilities, and template formats of the reports should be all established in this process. Once the preliminary work is done, identifying, analyzing, and adjusting for risks can be done.

Risk Identification

[edit | edit source]

Risk identification helps to avoid risks when possible, as well as control them in case this is necessary. If you don't know where to start, one possibility is to focus on known and predictable risks, for example: product size, business impact, process definition, development environment, technology to be built, and staff size and experience.


[edit | edit source]

There are a few strategies or techniques when determining project risks. The easiest strategy is the scenario based strategy. This strategy involves using creative brainstorming ideas to come up with positive and negative risks inside the scope of the project.

An example of the scenario based strategy would be: 'What happens if we exceed the time limit budgeted in the time planning phase?'

The second strategy to determining positive and negative risks in a project would be the relative experiences strategy. Here, risks are determined by relating past projects and experiences and tweaking them to fit the scope of the current project.

An example of the relative experiences strategy would be, say in your project, there were problems with unavailable team members. What if that were to happen again?

There is a third strategy to determining risks in project management. This is called the objective based scenario. This strategy follows the same ideas as the scenario strategy and the relating past experiences strategy, but instead of making up scenarios or using past experiences, risks are determined based on goals and wanted outcomes for the project. This type of strategy works best with finding the positive risks in a project versus the negative risks.


[edit | edit source]

There are a few tools required for completing Risk Management starting with the three strategies mentioned above. The biggest tool is the formula for calculating the rank of a risk. The Risk Management can then be formatted nicely into a professional report for presenting to the clients.

Qualitative Risk Analysis

[edit | edit source]

Qualitative Risk Assessment relies on judgment and experience. New project managers should seek out lessons learned from the organization’s knowledge management system (hint, hint) or ask for input from experienced PMs. You can guide thinking about potential risks by posing theoretical questions to yourself or to a brain storming team working the project such as:

  • What would happen if Sam left or got sick – assuming Sam is a key contributor with unique skills?
  • Have all important decisions on platform, language and process approach been made?
  • Do all stakeholders understand and agree on the project objectives?
  • What if subcontractor X fails?
  • Does the cost and schedule accommodate a learning curve for new hires or new technologies?
  • Do schedule dependencies – see “How to create and use predictive project scheduling” – show any tasks that could bring down the entire effort if unsuccessful?

Quantitative Risk Analysis

[edit | edit source]

The final strategy for Risk Management would be the handy formula for determining the rank of a risk. This formula requires two variables, one for the likelihood of the risk to happen and one for the impact of the risk if it did happen. You can rate these variables, for example, out of 5 stars. The formula then calls for the first variable to be added to the second variable, and then divide by the total number of possible stars, which would be 10 stars. Once all of your risks have an answer to that calculation, the risks are then ranked by their answers from highest to lowest.

Once the risks have been created, they must then be ranked in an order of most important to the least harmful. A way of determining the rank of a risk is to use a small mathematical formula. Once the risks have been ranked in an ascending order from highest to lowest, the risks must then be given a treatment or an avoidance strategy. This last step of risk planning is critical because if a risk happens to fall upon the project in the future, the team will already know how to solve it or prevent it from happening in the first place.

Risk Response Planning

[edit | edit source]

The project manager brainstorms and gathers all the positive and negative risks. It is important to note that this list of risks is not every possible thing that could happen, but rather the category of things that could happen. Consider, for example a project to build a house. Risks to consider would be on the order of slow progress, lack of material, lack of money, change of plans. Not run out of wood or the house catches fire. The purpose of risk planning is to have a plan on how to respond to a type of risk, not figure out all possible risks. So when a risk is realized and becomes an issue or problem, the team knows the steps to assess and respond. These risks would then be inputted into a report followed by the likelihood, impact, and rank of each risk.

Risk Monitoring and Control

[edit | edit source]

The final input for Risk Management would be the control/treatment plans for each risk in case the risk unfolds into the project down the time line. The Risk Monitoring and Control process is where the risks are diagnosed with treatment and control plans. The team also examines the scope items to ensure they are out of the way of the negative risks.

Risk Management Summary

[edit | edit source]

After the positive and negative risks of a project have been well defined and ranked, the team can then refer and familiarize themselves with all of, or just the highest ranked risks, in order to prevent them from occurring during the lifetime of that project. If the risk occurs, the team will know how to respond to it if they know the treatment plans outlined in the risk management document. Poor risk planning is a major factor in projects failing. It is an easily overlooked section of the PMBOK theory.


[edit | edit source]
  1. ^ PMBOK, p. 237.
  2. ^ PMBOK, p. 242.
  3. ^ PMBOK, p. 202.


[edit | edit source]
  • Pressman, Roger S. (November 3, 2011), Software Engineering, a practitioner's approach. (7th ed.), McGraw-Hill, p. 895, ISBN 9780071267823