Project risk is defined by the Project Management Institute as an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives. Risk management is the process of identifying, analyzing, mitigating, and communicating risks.
When a risk event occurs, it is no longer uncertain. It becomes an issue.
Risk can be broken down into two underlying components:
- Probability: The likelihood of the event happening.
- Impact: The consequences of the risk event.
The formula for risk is very simple:
Imagine the following two hypothetical events:
- Being hit by a car
- Tripping over a protruding tree branch
Both of these potential events motivate you to perform basic mitigation actions. In the case of being hit by a car, you look both ways and cross when there are no vehicles. In the case of the tree branch, you will make sure you take the long way around it.
Why do you do this? In the case of being hit by a car, this risk has a low probability, but a high impact. The perception of risk is driven by the impact (quite literally!). In the case of the tree branch, the opposite is true – it has a high probability, but low impact, and the perception of risk is driven by the probability.
If you ever have both high probability and impact, this is likely a major risk that probably requires advance planning and mitigation. An example might be the risk of falling while working on newly installed beams on a building construction site. In this case, various conditions need to be assessed before the work is deemed feasible, like the weather, condition of beams, stability of connections, etc.
The risk can be quantified by stating the probability and impact in numerical terms. For example, if I determine that the likelihood of underestimating the time a mobile crane will be required is 20%, and the cost will be $3,000 (i.e. there is a 20% chance of incurring a $3,000 charge), you could assign a risk value of $600. But what exactly does this number represent?
It means that if you entered a contingency of $600 into the project, it will cover the risk of underestimating the crane’s time if you had many, identical projects. Of course, you will not have many identical projects, but statistically speaking, this is the ideal contingency.
Risk Events
All projects have risk. By definition, projects are temporary endeavors which seek to change some form of operational or status quo processes or products. As a minimum, the project has an inherent risk that it does not accomplish its stated objective. But as you will see, there are a multitude of secondary risks that, if not carefully considered, create a toxic atmosphere for the project.
It is not a worthwhile goal to attempt to eliminate all risks. Project sponsors and stakeholders generally accept the basic inherent risks – that’s why they signed up to the project in the first place. Because of this, risk management can feel like a communication issue sometimes. It’s really about quantifying and communicating the risks, and the changes to them, at the appropriate times to the appropriate stakeholders.
Risk Tolerance
The amount of acceptable risk on a project depends on the organization’s as well as individual stakeholder’s risk tolerance. Thus, stakeholder’s attitudes to risk is an important variable that the project manager should be familiar with and actively manage.
Opportunities
Project risk management is not only concerned with negative events. Positive events can occur during a project’s execution, which are called opportunities. Oftentimes project work results in circumstances that allow savings in time, cost, resources, or any other item that can be exploited to enhance the project’s mission. In it’s relentless pursuit of its critical success factors, the project should seize any opportunities available to it.
Thus, risk management attempts to increase positive events as well as decrease negative events, and the positive events are an equally important part of the equation than the negative ones.
An example might be a building project where a trade is working on a site nearby during a specified time period and can mobilize quickly, saving time and money. The project schedule can be adjusted to accommodate the potential savings.
Risk Management Plan
A risk management plan is a subset of a project management plan, and it provides the foundation for risk management for a project. For large projects it can be a stand alone document, but for smaller projects it is a section of the project management plan.
The Risk Management Plan contains the following items.
- Introduction. Risk management methodologies, organization, roles and responsibilities, tools, and anything else that doesn’t warrant its own dedicated space.
- Risk Register. This is where the value is created. The risk register, also called a risk log, is a central repository of project risks, created at the project planning stage. The most important risks to the project’s critical success factors are determined, which are then categorized according to the Risk Breakdown Structure. It is not possible to ensure all risks are identified, and you can go overboard with identifying small insignificant risks, but the exercise ensures that project stakeholders are satisfied that the risks to the project have been considered. The risk register also contains the results of risk analysis, which prioritize risks by probability and impact, the two underlying factors.
- Risk Response Plans. The largest, more important risks should have a well planned out, written response and/or mitigation plan, particularly those that rank high on both the probability and impact scale. This can be an additional column in the risk register or its own separate section.
- Stakeholder Risk Tolerance. Although not always requiring its own dedicated space, stakeholder risk tolerance should be investigated and carefully considered. If you can’t define and write down the risk tolerance of the stakeholders, maybe it’s time to have a chat with them. Communication is key here.
- Risk Breakdown Structure. This is an optional, categorized organization of the project risks. Although PMI has only recently included this in the PMBOK, it’s helpful to organize risks into categories. For an engineering project, risk might be divided into technical, organizational, and external risks.
- Communications. Many times project issues aren’t really all that important on an absolute level, but make stakeholders unhappy because they were expecting something different. Thus, potential risks need to be communicated with stakeholders, so that everyone is prepared for the risks as they arise. Managing stakeholder expectations is the central foundation of risk management, and thus communication is key. Any changes to the risk profile of the project (i.e. the risk register) need to be communicated to the relevant stakeholders, and the communications plan can lay out how that will be done.
- Monitoring and Control. It is important to re-visit the risks regularly throughout the project, and this section will define how often that will happen and what that will look like. For most projects I would suggest weekly is an appropriate timeline. Often revisiting the risk register during a project is an easy task because risks are made obsolete (i.e. they can be labeled “did not occur”).
Risk Management Culture
Risk management is often overlooked in favor of schedule and cost, the two stereotypical project management functions. But to ensure a project isn’t blindsided by unexpected variances that consume project resources and threaten project success, a proper risk management plan should be developed.
But the true goal is a risk management culture within the organization. When a good risk culture is established, project managers are always thinking about what could happen to the project and communicating with this with stakeholders. Adequate risk planning and analysis of project risks become central to the organization, and project success on an organizational level is a huge benefit in a very competitive business landscape.