What is Project Risk Management? Process, Definition, Principles

What is Project Risk Management?

Risk management is defined as the art and science of identifying, analyzing, prioritization, management and responding to risk factors throughout the life of a project and in the best interests of its objectives.

Broadly speaking, for the project manager the process of risk management includes asking the following questions:

• What is likely to happen (the probability and impact)?
• What can be done to minimize the probability or impact of these events?
• What cues will signal the need for such action (i.e., what clues should I actively look for)?
• What are the likely outcomes of these problems and my anticipated reactions?

---

Project Risk Definition

The Project Management Institute defines project risk as “an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.”

This definition is important because, unlike in the past when project risk was automatically assumed to lead to negative consequences, it is now recognized as the source of either opportunities or threats.

Project risk is based on a simple equation:

Event Risk = (Probability of Event)(Consequences of Event)

Project managers must acknowledge the possibility that the same risk event may bring several outcomes, with either a positive or detrimental effect on the project. Underlying these definitions is the recognition that many events, both within the organization and outside its control, can affect our best efforts to successfully complete projects.

---

Project Risk Management Principles

The key principles to managing project risks include the following:

• All risk management: All project management is risk management. The current approaches and rules of modern project management, especially the ones surrounding portfolio management, project definition, and project planning, are all risk management focused. From past experiences, we now know how to structure a project for total success and how to greatly increase the likelihood the project will achieve its objectives.
  
  
  
• “Healthy paranoia”: It’s all attitude, even if it is a little psycho. Effective project managers take responsibility for managing risks on their project – believe me, no one else wants the job. As a result, you must strike the balance between having a paranoid outlook about your project (constantly thinking about what could go wrong) and doing everything you can to make sure the project is executed as planned.
  
  
  
• Appropriate: The level, type, and visibility of risk management should be consistent with the level of risk and the importance the project has to the organization. The cost of the risk response should not be greater than the impact loss the risk event might cause.
  
  
  
• Systematic: Any factor or risk that could impact the project should be identified, quantified, and assessed for possible impacts to the project. This includes all people, process, technology, organizational, and environmental influences.

---

Risk Management Process

The risk management process is a framework or steps that assists project managers in identifying existing and potential problems, the resources and strategies necessary to reduce their probability and impact, and the ability to quickly and effectively communicate risk information up and down the management chain.

1. Planning Risk Management
2. Risk Identification
3. Performing Qualitative Risk Analysis
4. Performing Quantitative Risk Analysis
5. Planning Risk Responses
6. Implementing Risk Responses
7. Monitoring Risk

Planning Risk Management

Planning risk management involves deciding how to approach and plan risk management activities for the project. The main output of this process is a risk management plan.

• Inputs
  1. Project charter
  2. Project management plan
  3. Project documents
  4. Enterprise environmental factors
  5. Organizational process assets
     
     
• Tools & Techniques
  • Expert judgment
  • Data analysis
  • Meetings
    
    
• Outputs
  • Risk management plan

A risk management plan documents the procedures for managing risk throughout the project. Project teams should hold several planning meetings early in the project’s life cycle to help develop the risk management plan.

Like plans for other knowledge areas, it becomes a subset of the project management plan.

It is important to clarify roles and responsibilities, prepare budget and schedule estimates for risk-related work, and identify risk categories for consideration. Table 1 below lists the general topics that a risk management plan should address.

It is also important to describe how risk management will be done, including assessment of risk probabilities and impacts as well as the creation of risk-related documentation. The level of detail included in the risk management plan can vary with the needs of the project.

In addition to a risk management plan, many projects also include contingency plans, fallback plans, contingency reserves, and management reserves.

• Contingency plans are predefined actions that the project team will take if an identified risk event occurs.
  
  
• Fallback plans are developed for risks that have a high impact on meeting project objectives and are put into effect if attempts to reduce the risk do not work.
  
  
• Contingency reserves or contingency allowances are funds included in the cost baseline that can be used to mitigate cost or schedule overruns if known risks occur.
  
  
• Management reserves are funds held for unknown risks that are used for management control purposes.

Topics addressed in a risk management plan

Topic	Questions to Answer
Methodology	How will risk management be performed on this project? What tools and data sources are available and applicable?
Roles and responsibilities	Which people are responsible for implementing specific tasks and providing deliverables related to risk management?
Budget and schedule	What are the estimated costs and schedules for performing risk-related activities?
Risk categories	What are the main categories of risks that should be addressed on this project? Is there a risk breakdown structure for the project?
Risk probability and impact	How will the probabilities and impacts of risk items be assessed? What scoring and interpretation methods will be used for the qualitative and quantitative analysis of risks? How will the probability and impact matrix be developed?
Revised stakeholders’ tolerances	Have stakeholders’ tolerances for risk changed? How will those changes affect the project?
Tracking	How will the team track risk management activities? How will lessons learned be documented and shared? How will risk management processes be audited?
Risk documentation	What reporting formats and processes will be used for risk management activities?

Risk Identification

Identifying risks involves determining which risks are likely to affect a project and documenting the characteristics of each. The main outputs of this process are a risk register, risk report, and project documents updates.

• Inputs
  • Project management plan
  • Project documents
  • Agreements
  • Procurement documentation
  • Enterprise environmental factors
  • Organizational process assets
    
    
• Tools & Techniques
  • Expert judgment
  • Data gathering
  • Data analysis
  • Interpersonal and team skills
  • Prompt lists
  • Meetings
    
    
• Outputs
  • Risk register
  • Risk report
  • Project documents updates

Also, remember that you cannot manage risks if you do not identify them first. By understanding common sources of risks and reviewing a project’s project management plan, project documents, agreements, procurement documents, enterprise environmental factors, and organizational process assets project managers and their teams can identify many potential risks.

Remember that risk implies the potential for both positive and negative effects on the project.

Common Sources of Risk in Project

Risks commonly fall into one or more of the following classification clusters:

• Financial risk: Financial risk refers to the financial exposure a firm opens itself to when developing a project.
  
  
• Technical risk: When new projects contain unique technical elements or unproven technology, they are being developed under significant technical risk.
  
  
• Commercial risk: For projects that have been developed for a definite commercial intent (profitability), a constant unknown is their degree of commercial success once they have been introduced into the marketplace.
  
• Execution risk: What are the specific unknowns related to the execution of the project plan? Execution risk is a broad category that seeks to assess any unique circumstances or uncertainties that could have a negative impact on execution of the plan.
  
  
• Contractual or legal risk: This form of risk is common with projects in which strict terms and conditions are drawn up in advance.

After understanding the broad categories of risk, you want to anticipate some of the more common forms of risk in projects. The following list, though not inclusive, offers a short set of some of the more common types of risk to which most projects may be exposed:

• Absenteeism
• Resignation
• Staff being pulled away by management
• Additional staff/skills not available
• Training not as effective as desired
• Initial specifications poor or incomplete
• Work or change orders multiplying due to various problems
• Enhancements taking longer than expected

Suggestions for Identifying Risks

There are several tools and techniques for identifying risks. Project teams often begin this process by reviewing project documentation, recent and historical information related to the organization, and assumptions that might affect the project.

Project team members and outside experts often hold meetings to discuss this information and ask important questions about it as they relate to risk.

Some common risk identification techniques are explained below:

Brainstorming meetings

Brainstorming is a technique by which a group attempts to generate ideas or find a solution for a specific problem by amassing ideas spontaneously and without judgment. This approach can help the group create a comprehensive list of risks to address later during qualitative and quantitative risk analysis.

To be effective, brainstorming meetings must be free of judgments, criticism of others viewpoints, and pressure to conform.

Expert opinion

This technique can be used in two alternative ways in assessing project risks. The more quantifiable method, commonly referred to as the Delphi approach, collects and consolidates the judgments of isolated anonymous respondents.

For Delphi to be used effectively, some preliminary screening of potential contributors is usually necessary.

The collective “wisdom” of the set of experts is then used as the basis for decision-making. The simpler, more intuitive method for using expert judgments is based on the principle that “experience counts.”

You simply identify and consult people within the organization who have had similar experiences in running projects in the past or who have been with the firm long enough to have a clear grasp of the mechanics of project risk analysis.

History

In many cases the best source of information on future risks is history. Has a firm encountered a consistent pattern of problems while pursuing projects over time? What “storm signals,” or events that preceded past problems, have been detected?

Experience can be used to identify not only risk factors but their leading indicators as well. The problem with experience is that it is no guarantee of future events.

Multiple (or team-based) assessments

Using single-case sources to identify project risks is itself a risky proposition because of the potential bias in any one person’s viewpoint.

A team-based approach to risk factor identification encourages identification of a more comprehensive set of potential project risks. At the same time, a collaborative approach can help persuade the half-convinced or uncommitted members of the team to support project goals.

SWOT analysis

SWOT analysis can also be used during risk identification by having project teams focus on the broad perspectives of potential risks for particular projects.

Risk Register

One important output of risk identification is a list of identified risks and other information needed to begin creating a risk register.

A risk register is a document that contains results of various risk management processes; it is often displayed in a table or spreadsheet format.

A risk register is a tool for documenting potential risk events and related information. Risk events refer to specific, uncertain events that may occur to the detriment or enhancement of the project.

Elements of a risk register include the following:

• An identification number for each risk event: The project team may want to sort by risk events or quickly search for specific risk events, so they need to identify each risk with a unique descriptor, such as an identification number
  
  
• A rank for each risk event: The rank is usually a number, with 1 representing the highest risk.
  
  
• The name of the risk event: Example names include defective server, late completion of testing, reduced consulting costs, and good publicity.
  
  
• A description of the risk event: Because the name of a risk event is often abbreviated, it helps to provide a more detailed description.
  
  
• The category under which the risk event falls: For example, defective server might fall under the broader category of technology or hardware technology.
  
  
• The root cause of the risk: The root cause of the defective server might be a defective power supply.
  
  
• Triggers for each risk: Triggers are indicators or symptoms of actual risk events.
  
• Potential responses to each risk: A potential response to the defective server might be to include a clause in the supplier’s contract to replace the server within a certain time period at a negotiated cost.
  
  
• The risk owner or person who will take responsibility for the risk: For example, a certain person might be in charge of any server-related risk events and managing response strategies.
  
  
• The probability of the risk occurring: There might be a high, medium, or low probability of a certain risk event. For example, the risk might be low that the server would actually be defective.
  
  
• The impact to the project if the risk occurs: There might be a high, medium, or low impact to project success if the risk event actually occurs. A defective server might have a high impact on successfully completing a project on time.
  
  
• The status of the risk: Did the risk event occur? Was the response strategy completed? Is the risk no longer relevant to the project?

The Risk Report

Another important output of identifying risks is a creation of a risk report. Overall project risk is the effect of uncertainty on the project as a whole.

Contents of a risk report include sources of overall project risk, important drivers of overall project risk exposure, and summary information on risk events, such as a number of risks, total risk exposure, distribution across risk categories, metrics, and trends. The risk report is developed progressively during the entire risk planning processes.

After identifying risks, the next step is to understand which risks are most important by performing qualitative risk analysis.

Performing Qualitative Risk Analysis

Performing qualitative risk analysis involves prioritizing risks based on their probability of occurrence and impact. After identifying risks, project teams can use various tools and techniques to rank risks and update information in the risk register. The main outputs are project documents updates.

• Inputs
  • Project management plan
  • Project documents
  • Enterprise environmental factors
  • Organizational process assets
    
    
• Tools & Techniques
  • Expert judgment
  • Data gathering
  • Data analysis
  • Interpersonal and team skills
  • Risk categorization
  • Data representation
  • Meetings
    
    
• Outputs
  • Project documents updates

Qualitative risk analysis involves assessing the likelihood and impact of identified risks to determine their magnitude and priority. Using the methods described below can greatly improve qualitative risk analysis.

Using Probability/Impact Matrixes to Calculate Risk Factors

People often describe a risk probability or consequence as being high, medium or moderate, or low.

A project manager can chart the probability and impact of risks on a probability/ impact matrix or chart, which lists the relative probability of a risk occurring and the relative impact of the risk occurring. Many project teams would benefit from using this simple technique to help them identify risks that need attention.

To use this approach, project stakeholders list the risks they think might occur on their projects. They then label a risk as having a high, medium, or low probability of occurrence and a high, medium, or low impact if it does occur.

• Some project teams develop a single number for a risk score simply by multiplying a numeric score for probability by a numeric score for impact.
  
  
• A more sophisticated approach to using probability/impact information is to calculate risk factors. To quantify risk probability and consequence, the U.S. Defense Systems Management College (DSMC) developed a technique for calculating risk factors—numbers that represent the overall risk of specific events, based on their probability of occurring and the consequences to the project if they do occur.
  
  The technique makes use of a probability/impact matrix that shows the probability of risks occurring and the impact or consequences of the risks.

Top Ten Risk Item Tracking

Top Ten Risk Item Tracking is a qualitative risk analysis tool. In addition to identifying risks, it maintains an awareness of risks throughout the life of a project by helping to monitor risks.

Using this tool involves establishing a periodic review of the project’s most significant risk items with management; similar reviews can also occur with the customer. The review begins with a summary of the status of the top ten sources of risk on the project.

The summary includes each item’s current ranking, previous ranking, the number of times it appears on the list over a period of time, and a summary of progress made in resolving the risk item since the previous review.

Table 2 provides an example of a Top Ten Risk Item Tracking chart that could be used at a management review meeting for a project. For sake of example, we have just taken only the 5 risk lists.

Risk Event	Rank This Month	Rank Last Month	Number of Months in Top Ten	Risk Resolution Progress
Inadequate planning	1	2	4	Working on revising the entire project management plan
Poor definition	2	3	3	Holding meetings with project customers and sponsor to clarify scope
Absence of leadership	3	1	2	Assigned a new project manager to lead the project after the previous one quit
Poor cost estimates	4	4	3	Revising cost estimates
Poor time estimates	5	5	3	Revising schedule estimates

A risk management review accomplishes several objectives

• First, it keeps management and the customer (if included) aware of major influences that could prevent or enhance the project’s success.
  
• Second, by involving the customer, the project team may be able to consider alternative strategies for addressing the risks.
  
• Third, the review promotes confidence in the project team by demonstrating to management and the customer that the team is aware of significant risks, has a strategy in place, and is effectively carrying out that strategy.

The main output of qualitative risk analysis is updating the risk register. The ranking column of the risk register should be filled in, along with a numeric value or rating of high, medium, or low for the probability and impact of the risk event.

Performing Quantitative Risk Analysis

Performing quantitative risk analysis involves numerically estimating the effects of risks on project objectives. The main outputs of this process are project documents updates.

• Inputs
  • Project management plan
  • Project documents
  • Enterprise environmental factors
  • Organizational process assets
    
    
• Tools & Techniques
  • Expert judgment
  • Data gathering
  • Interpersonal and team skills
  • Representations of uncertainty
  • Data analysis
    
    
• Outputs
  • Project documents updates

Quantitative risk analysis often follows qualitative risk analysis, yet both processes can be done together or separately. On some projects, the team may only perform qualitative risk analysis.

The nature of the project and availability of time and money affect which risk analysis techniques are used. Large, complex projects involving leading-edge technologies often require extensive quantitative risk analysis.

Decision Trees and Expected Monetary Value

A decision tree is a diagramming analysis technique used to help select the best course of action when future outcomes are uncertain. A common application of decision tree analysis involves calculating expected monetary value.

Expected monetary value (EMV) is the product of a risk event probability and the risk event’s monetary value.

To create a decision tree, and to calculate expected monetary value specifically, you must estimate the probabilities or chances of certain events occurring.

Simulation

A more sophisticated technique for quantitative risk analysis is a simulation, which uses a representation or model of a system to analyze its expected behavior or performance. Most simulations are based on some form of Monte Carlo analysis.

Monte Carlo analysis can predict the probability of finishing by a certain date or the probability that the cost will be equal to or less than a certain value.

Sensitivity Analysis

Many people are familiar with using sensitivity analysis to see the effects of changing one or more variables on an outcome.

For example, many people perform a sensitivity analysis to determine their monthly payments for a loan given different interest rates or periods of the loan.

Many professionals use sensitivity analysis to help make several common business decisions, such as determining break-even points based on different assumptions.

Planning Risk Responses

Planning risk responses involves taking steps to enhance opportunities and reduce threats to meeting project objectives. Using outputs from the preceding risk management processes, project teams can develop risk response strategies that often result in change requests, updates to the project management plan and project documents.

• Inputs
  • Project management plan
  • Project documents
  • Enterprise environmental factors
  • Organizational process assets
    
    
• Tools & Techniques
  • Expert judgment
  • Data gathering
  • Interpersonal and team skills
  • Strategies for threats
  • Strategies for opportunities
  • Contingent response strategies
  • Strategies for overall project risk
  • Data analysis
  • Decision making
    
    
• Outputs
  • Change requests
  • Project management plan updates
  • Project documents updates

Developing a response to risks involves developing options and defining strategies for reducing negative risks and enhancing positive risks.

Response Strategies for Negative Risks

The five basic response strategies for negative risks are as follows:

• Risk avoidance or eliminating a specific threat, usually by eliminating its causes. Of course, not all risks can be eliminated, but specific risk events can be.
  
  For example, a project team may decide to continue using a specific piece of hardware or software on a project because the team knows it works.
  
  
  
• Risk acceptance or accepting the consequences if a risk occurs.
  
  For example, a project team planning a big project review meeting could take an active approach to risk by having a contingency or backup plan and contingency reserves if the team cannot get approval for a specific meeting site. On the other hand, the team could take a passive approach and accept whatever facility the organization provides.
  
  
  
• Risk transference or shifting the consequence of a risk and responsibility for its management to a third party.
  
  For example, A project team may purchase special insurance or warranty protection for specific hardware needed for a project. If the hardware fails, the insurer must replace it within a specified period of time.
  
  
  
• Risk mitigation or reducing the impact of a risk event by reducing the probability of its occurrence. Suggestions for reducing common sources of risk on IT projects were provided at the beginning of this chapter.
  
  
• Risk escalation or notifying a higher level authority. If the risk is outside of the scope of the project or the proposed response is outside of the project manager’s authority, it would make sense to escalate the risk to a higher-level manager within the organization.

Response Strategies for Positive Risks

The five basic response strategies for positive risks are as follows:

• Risk exploitation or doing whatever you can to make sure the positive risk happens.
  
  For example, organize news coverage of the project, write a press release, or hold some other public event to ensure that the project produces good public relations for the company, which could lead to more business.
  
  
  
• Risk sharing or allocating ownership of the risk to another party
  
  
  
  
• Risk enhancement or changing the size of the opportunity by identifying and maximizing key drivers of the positive risk.
  
  
  
  
• Risk acceptance also applies to positive risks when the project team does not take any actions toward a risk.
  
  
  
• Risk escalation or notifying a higher level authority also applies to positive risks.

Implementing Risk Responses

Implementing risk responses, just as it sounds, involves implementing the risk response plans. Outputs include change requests and project documents updates.

• Inputs
  • Project management plan
  • Project documents
  • Organizational process assets
    
    
• Tools & Techniques
  • Expert judgment
  • Interpersonal and team skills
  • Project management information system
    
    
• Outputs
  • Change requests
  • Project documents updates

The main executing process performed as part of project risk management is implementing risk responses as defined in the process to plan risk responses. Key outputs include change requests and project documents updates (i.e. issue log, lessons-learned register, project team assignments, risk register, and risk report).

Monitoring Risk

Monitoring risk involves monitoring identified and residual risks, identifying new risks, carrying out risk response plans, and evaluating the effectiveness of risk strategies throughout the life of the project.

The main outputs of this process include work performance information, change requests, and updates to the project management plan, project documents, and organizational process assets.

• Inputs
  • Project management plan
  • Project documents
  • Work performance data
  • Work performance reports
    
    
• Tools & Techniques
  • Data analysis
  • Audits
  • Meetings
    
    
• Outputs
  • Work performance information
  • Change requests
  • Project management plan updates
  • Project documents updates
  • Organizational process assets updates

Carrying out individual risk management plans involves monitoring risks based on defined milestones and making decisions regarding risks and their response strategies.

---

Using Software to Assist in Project Risk Management

you can use a variety of software tools to enhance various risk management processes. Most organizations use software to create, update, and distribute information in their risk registers. The risk register is often a simple Microsoft Word or Excel file, but it can also be part of a more sophisticated database.

Spreadsheets can aid in tracking and quantifying risks, preparing charts and graphs, and performing sensitivity analysis. Software can be used to create decision trees and estimate expected monetary value.

More sophisticated risk management software, such as Monte Carlo simulation software, can help you develop models and use simulations to analyze and respond to various risks.

Several high-end project management tools include simulation capabilities. Several software packages have also been created specifically for project risk management.

Although it has become easier to do sophisticated risk analysis with new software tools, project teams must be careful not to rely too heavily on software when performing project risk management.

---