Skip to content

Risk management

Here's one way to use a framework for managing risks in a project.

Identifying risks is the easy part. Actively managing risks is where great TPMs excel.

Urgency vs. importance

In his seminal book The 7 Habits of Highly Effective People Stephen Covey describes the things we do on two axes: urgency and importance. The same ratings also work for risk management.

urgency

Photo by Towfiqu barbhuiya on Unsplash

Urgency is a time factor. Urgent risks might happen today, or maybe this week, this sprint, or this milestone. (There are degrees of high urgency too.) Less urgent risks are further out in time: they might happen this milestone (yes, there's potential overlap in this axis), or sometime this month, this quarter, or this year.

Importance you can think of as the degree of impact that the risk might have. Unimportant risks have a small potential impact on your program. Risks with high potential impact are rated with high importance.

It doesn't matter what number of levels or minimum and maximum values you use for your urgency and importance axes. Just pick something and use it consistently so people on your team get to know what a "priority 1" risk means in terms of urgency. You might pick levels 1, 2, and 3. You might pick a scale between 1 and 10.

There's a joke about people with MBA degrees: Everything they do can be described by a four-quadrant chart. In this case, it's good tool for risk management.

Low urgency (3) High urgency (1)
High importance (1) Risk 001
Low importance (3) Risk 002

Once you pick a scale or set of values, you can start to assign them to your risks in a risk register.

Risk register

The risk register is just a table of all the risks you've identified for your program so far. Here's an example format.

ID Description Urgency Importance Owner Date last updated
001 Key team member resigns 3 1 Team member's manager March 25
002 External partner is late this sprint 1 3 Partner manager March 23

Note: We've used Team member's manager and Partner manager here as generic descriptions of the owner. In a real risk register use someone's name whenever possible. This helps provide clarity and accountability.

Mitigation and contingency

Every risk should also have a mitigation and contingency plan. Mitigation is what you're going to do to reduce the chance of the risk happening. Mitigation happens before the risk occurs. Contingency is what you're going to do if the risk happens. Contingency plans are used after the risk occurs. Note that you can have more than one mitigation or contingency per risk item.

Put another way, if your mitigation plan is successful the risk never happens. A successful contingency plan reduces the negative effects after a risk happens.

Example: The mitigation for a team member leaving might be for their manager to have a conversation about why they want to leave. Another mitigation is to have the person who might leave do some cross-training with other team members. The contingency plan for when the team member does leave is to have another team member fill their role. Another contingency plan would be to hire or transfer someone into the team.

graph LR Mitigation Risk Contingency Mitigation --> Risk Risk --> Contingency

Once you've identified mitigation and contingency plans, add them to your risk register as new columns.

Idea: For any program of significant size consider using a data-backed risk register tool instead of a flat table. Something like GitHub Issues and a Project Board, a Jira project, or almost any item-based project management tool are good choices to identify and manage risks.

Risk mitigation

There are a number of different ways to mitigate risks, including:

  • Avoidance - Avoiding a risk means taking steps to prevent it from happening in the first place. For example, if a risk is that a key team member will leave the project, the team could avoid this risk by offering competitive salaries and benefits.
  • Reduction - Reducing a risk means making it less likely to happen or less severe. For example, if a risk is that a project will be delayed, the team could reduce this risk by creating a detailed project plan and sticking to it.
  • Transfer - Transferring a risk means shifting the responsibility for it to another party. For example, if a risk is that a project will go over budget, the team could transfer this risk to the insurance company by purchasing project insurance.
  • Acceptance - Accepting a risk means acknowledging that it exists and that there is nothing that can be done to avoid it. For example, if a risk is that a project will be subject to delays due to bad weather, the team could accept this risk and build in contingency plans to deal with it.

Contingency plans

A contingency plan is a plan that is put in place to deal with a particular risk if it occurs. It is a way of planning for the unexpected and ensuring that the project can continue even if things go wrong. They should also be reviewed and updated regularly to ensure that they are still effective.

Some common types include:

  • Recovery plans - These plans aim to recover from a risk if it does occur. For example, a recovery plan might involve having a backup plan in place if a key piece of equipment fails.
  • Acceptance plans - These plans accept the risk and do not attempt to mitigate or recover from it. For example, an acceptance plan might involve accepting the risk that the project will be delayed due to bad weather.