An introduction to risk management
Risk and formal risk management play a large role in project management, service management, and IT governance. Project management tries to manage risks so that projects can complete; service management tries to contain risks and clarify the residual risks; IT governance tries to balance risk with cost and value.
Risk management is a large field. PMI, the people behind the PMP project management certification, offer a Risk Management Professional (PMI-RMP) certification. Financial institutions have made risk management (in)famous. In higher education, “Enterprise Risk Management” (ERM) projects, driven by Boards, identify and manage risks across the entire institution.
However, like many other management processes, people are often wholly unaware of risk management. If they do hear about risk management, it can sound like a waste of time: why would we spend time identifying a bunch of things that are unlikely to happen? Or, risk management may sound useful but tangential to the orders of the day.
I first used risk management in a large tool upgrade. I didn’t involve anyone else; I just built a list of risks myself and then ranked them. Then I let the list sit, and I forgot about it. Would you believe a year later that I went back to the list and 100% of the high-impact risks I’d identified had occurred? If only I’d planned in advance what I’d do for each one!
Risk management has a few components, which I’ll distill for you:
- Identify “risk boundaries”
- Identify risks, ideally working with many stakeholders
- Triage/assess risks
- Plan for (some of the) risks
- Respond to risks
- Update the risk plans
Identify “risk boundaries”
In project management, they’re called “assumptions.” In service management, they’re part of the service level agreement. At some point, you need to know what risks are out of scope for consideration. Essentially, what types of risks do you not own?
In project management, if one of the assumptions is violated, that’s grounds to stop the entire project. The assumptions should be spelled out in the charter so everyone is aware of them.
Risk boundaries for a project might include:
- The institution physically moves to a new town
- Bankruptcy or financial insolvency
- Institutional strategy changed to remove the emphasis on research
Risk boundaries for a service might include:
- Users maliciously destroy their work-issued computers
- The institution acquires a new campus
- The Board of Trustees does not approve expected staff increases
And the idea behind these risk boundaries is to set expectations: the project or the service will be disrupted and it’s not up to the provider to address the situation unilaterally.
Having risk boundaries identified also helps people understand that the remaining risks are owned by the provider.
Identify risks, ideally working with many stakeholders
Risk identification can come from team brainstorming. The more people participating, the better–stakeholders can have very different vantage points that complement one another.
Some of the risks will be highly unlikely; that’s fine. Just record them and continue.
Identified risks for a project might include:
- Server disks are too slow and cannot meet demand
- Staff unavailable due to sickness
- A second, non-production environment is not funded
- Staff overcommitted and the project schedule is delayed
These risks should all be recorded, but don’t respond to them yet. Just identify possible risks. This list of risks is the first part of the “risk register.”
(Aside: risk management can talk about good risks as well as bad risks. The term “good risk” can throw people for a loop. You may want to call good risks “opportunities,” and solicit for them. Opportunities might include “extra year-end funding available to hire contractors.”)
Triage/assess risks
Now that you have a list of risks, the list should be reviewed to identify the most important risks. There are very fancy ways to do this. An easy way is to rate each risk in two ways: likelihood and impact. Ideally, this should be done with the same stakeholders that identified the risks.
For example, for the above risks the breakdown might look like so:
| Risk | Likelihood | Impact |
|---|---|---|
| Server disks are too slow and cannot meet demand | MEDIUM | MEDIUM |
| Staff unavailable due to sickness | HIGH | LOW |
| A second, non-production environment is not funded | LOW | MEDIUM |
| Staff overcommitted and the project schedule is delayed | HIGH | HIGH |
It can also be helpful to note the level of agreement or disagreement in the room, and you may want to err on the “worse” side. If 60% of the room says the likelihood is low and 40% says it’s medium, you should probably go with medium.
This annotated list is an expansion of your “risk register.”
Certainly this process is not scientific (although again, there are more advanced risk assessment techniques that are much more rigorous), but as long as you have good rankings relative to one another you are much better off than not having any risk management.
Plan for (some of the) risks
Now that you have a list of risks, you should figure out what you’re going to do with them. Ideally, do this with the same group of stakeholders, so they all know what the plan would be.
For the low-likelihood, low-impact risks, consider documenting that you are accepting the risks. That means, don’t do anything about them and acknowledge you’ll scramble to figure it out if those risks occur.
For the higher-impact, higher-likelihood risks you should come up with a plan of what to do should that risk occur. For project management, the plan could be anything from a written paragraph to an extra section in the work breakdown structure with the work that would have to be done.
There are many ways to plan for risks–some very advanced. You might be able to purchase insurance for a risk, or you may be able to contract out the work and transfer the risk to a third party. You may be able to prevent the risk, or you may need a change to agree that the risk is a “risk boundary” that would stop work. You may need a risk mitigation plan to lessen the effects of the risk.
If you have 100 risks in your risk register, you might only have a plan for 10-20 of them. But by having that plan, everyone is better prepared. You can also track the risks to see whether they’ve occurred.
These plans should be added to the risk register.
Respond to risks
Once you have the plan, you need to use it. Someone needs to be watching for risks–maybe the project manager or the service manager. When a risk occurs, then the plan for the risk should be used.
Update the risk plans
As stakeholders learn more, through using a service or working on a project, they will have more detailed understanding of what the risks are. Consider updating the risk register from time to time, perhaps with service reviews or project milestones.
By using very simple risk management as described here, you’ll begin developing a capability to manage risk that will propel you to learn more as you need to know more. Risk management can save you and your team a huge amount of time if you keep with it and manage your risks proactively.