One of the key skills that a Project Manager brings to the table is risk management. In order to manage risk, it’s important to understand what it is, why it needs to be managed (not as simple as it sounds), and how to manage it.
First, let’s describe what risk is. Risk is the likelihood or probability that something is going to happen. In almost every definition you’ll find, this refers to something adverse happening, something that is going to negatively impact a project or effort. The “something” might cause delays, or schedule impacts, or increased cost.
Often these impacts are obvious, but in other cases they are more subtle – for example, when something happens that appears to be positive, but has impacts that resonate across the organization. A simple example: let’s say we ordered a particular tile from Italy. We are given a lead time of six weeks. We plan to bring on a tile setter to install the tile, planning the work to coincide roughly with the arrival of the tile. We identify a risk that the tile might show up late, and we make a plan to deal with that.
But what if it arrives early? Great, right? Well… if we can’t adjust the schedule to get the tile installed early, we have to store it. Where do we store it? What is that going to cost? So this seemingly good thing – a material arrives earlier than expected – can cause issues.
Because risk is a probability, it is expressed as a number between 0 (never gonna happen) and 1 (for sure gonna happen). It can also be shown as a percentage. Having a number associated with risk is important, as we’ll soon see.
(While risk itself is a probability, and there is an event tied to that probability, the word “risk” is often used to talk about both. This bothers the strict word geek in me, but it has become common usage.)
Why does risk need to be managed?
It sounds obvious, but the answer is a bit more subtle.
Each entity – business, non-profit, even a person or family – has a particular risk profile. The risk profile combines three things:
- risk tolerance (a subjective, psychological measure of an entity’s willingness to take on risk)
- risk capacity (a measure of the financial resources that can be brought to bear to deal with risk)
- risk requirement (the level of risk needed to achieve certain financial goals).
How exactly risks are managed is determined by the risk profile. Whatever tactics are used to manage a given risk have to fit comfortably in the risk profile.
Identifying Risks.
At the beginning of a project, and on an ongoing basis during the project, risks need to be identified. In any organization, there are some risks that are a part of every project. These vary by entity. For example, in one of my jobs my office was in a building adjacent to a major airport. Every project had to include a risk along the lines of “A plane falls on the building.” It had to be included in the plan.
Other examples of “standard” risks include “A key developer leaves the company,” “Technology changes in the middle of the project,” and “Financial resources get pulled/diverted/reduced during the project.”
There will also be additional risks that can be identified that are not necessarily standard. A great place to start in identifying these is in a brain-storming session with a representative of each stakeholder group. This should not include EVERY stakeholder, but every constituency needs to be involved in this exercise.
All the risks that are identified are entered into something called a Risk Register. Now, it’s important to attach metrics to each of these risks – beyond, “Hey, that would be pretty bad!” There are commonly two parameters used to quantify risks: the probability, and the impact.
The probability – again, a number between 0 and 1 or a percentage from 0 to 100 – is the likelihood that this event could happen. The more that is known about the risk, the more refined this number can be. Take the “A plane falls on the building” example above. It is possible to learn what the actual frequency of flights over the building at any given time will be. As well, it might be possible to determine the number of air disasters at this airport in general. Taken altogether, these could point to a very low likelihood – so we’d assign that a 0 or .01 or so.
The impact refers to the consequences if a particular risk comes to fruition. The impact should be specified in terms of what is actually affected – whether it’s the project, the company, the stakeholders, etc. It’s most useful if the impact can be expressed in terms of a particular unit of measure. This will typically be dollars (or the local equivalent). Even if the impact is related to time (for example, the project schedule), this should be translated into a financial impact.
We can then use the probability times the impact to come up with a risk score. This allows us to assign a ranking to the risks in question. This can have a bearing on how the risks are dealt with, as we’ll soon see.
One thing to note: In theory, the risk score should give an indication of the order in which risks are addressed and planned for. The higher the risk score, the higher the priority and the higher the level of attention that risk should get. While this is good in theory, it’s important to hold the risks in the light of the organization’s risk profile. If there might be, for example, a reputational impact of a certain risk, one that might be very challenging to put into numbers, and even with that it’s just not something the organization is comfortable with, then it might get more attention than the risk index might imply. Similarly, anything having to do with regulatory issues will likely have a boosted position on the list. In actual practice, the risk register is a somewhat flexible tool – but it should not be treated willy-nilly. The more objective the ranking can be, the better.
Approaches to dealing with risks.
Having identified the risks associated with a project, having attached a risk index to each, and finalized the order on the risk register, it’s necessary to decide how to deal with the risks. There are several main approaches.
- Mitigation – This is the process of reducing the probability of an event. This is a preemptive approach. In the example mentioned above – “A plane falls on the building” – mitigation might involve relocating the team to another building or only scheduling work in the building when there are no or very few overflights. In a more real-world example, this might include implementing redundant power systems to reduce the risk of work interruptions caused by power failures.
- Contingency Planning – While mitigation is a preemptive approach to reduce the probability aspect of risk, contingency planning aims to reduce the impact of an event. By examining the “what if” scenarios of risks, the organization can identify and plan reactions if an event takes place. For example, if the event is “Vendor A goes out of business,” a contingency plan would include having other vendors “in the wings,” already vetted, so that supplies are maintained. Even having multiple sources at the outset is a contingency plan – it may look like risk mitigation, but having multiple sources doesn’t reduce the chances that Vendor A goes out of business. It just keeps the organization ready if that’s what happens. Thus, this is a contingency strategy.
- Transfer – Transferring risk involves shifting the impact away from the organization – this is usually done through insurance. The organization pays a certain amount to an insurance company – far less than the cost of the event – and the risk is then assumed by the insurance company. The insurance company is able to assume the risk because they have such a great volume of subscribers. The premiums they receive far outweigh the reimbursements they make.
- Acceptance – Each of the other risk management strategies mentioned have costs associated with them, whether in redundant hardware, additional vendors, or insurance premiums. It is possible that an organization will decide that the cost of dealing with the risk is greater than the impact, or the risk index is sufficiently low. The organization then simply accepts the risk because even if the event happens, the outcome will not seriously impact the bottom line.
And then? AND THEN?
There is a general rule in project management: nothing is carved in stone. Nothing is immutable. Change is a part of every project. No artifact is created simply to check a box, set it aside, and never look at it again. Each work product needs to be revisited throughout the lifetime of the project. The Risk Register is no exception.
As a project progresses, the likelihood of certain events may go up or down. A certain risk – “There could be a large number of vacations taken at the end of June” – is moot as of July 1. So the risk probability goes to zero – or the event could be tweaked because, in reality, a bunch of people scheduled their vacations for July this year.
As well, certain events may come to pass and contingency plans put into play – or the impact was misjudged initially, and the company just “lets this one go” because it’s the economically prudent thing to do.
Regularly looking into the Risk Register is a vital and sound practice – the Project Manager has the responsibility for this, and must work with the stakeholders to ensure that the Risk Register is current and true.
Meanwhile, back at the project….
Regular monitoring of the risks for a project lets the PM and the team be ready to act, if necessary, to activate contingency plans if an event occurs. Note that contingency plans should be as complete as possible, detailing the impact to the project’s scope, timeline, and budget. Depending on the state of the project when an event occurs, it may be necessary to adjust the contingency plan that covers that event.
Managing risk, as you can see, is a sophisticated process with a number of moving parts. This is a main reason why good PMs add so much value to a project and a company.