A practical guide to risk management

Hey there, and welcome to the Minimum Viable Project.

First off, I wish you all the best for 2023!

I'm fully recharged after some family time and a few days in the mountains. It's time to hit 2023 hard, and I'm happy you're coming along for the ride.

Two months ago, I wrote the most popular newsletter to date about identifying risk within your project.

Today, we're following up on that.

Because just knowing your risks is not enough.

You need to do something about it.

Unfortunately, poor risk management is one of the top causes of project failure.

Risks that are not identified or responded to, cause budgets to blow up, deadlines to be missed, and stakeholder relationships to crumble. In the worst case, it can even cost a project manager's job.

But there's good news too. Risk management can sound daunting, but it's straightforward if you apply the right steps.

Let's break it down:

1. Identify risk

We've gone into this in-depth in October, you can read the full post here.

In short: you need to identify what you don't know, and what could happen. This sounds like a joke, but I'm dead serious. By approaching this in a structured and repeatable way, you'll be amazed by how much you'll uncover.

2. Analyze your risks

Next up, you need to analyze your risks. You do this in a risk register, for which I've made a handy template for you to steal.

Following the columns from left you right:

1. Give your risk a fresh ID number

2. Describe what the risk is

3. Describe the impact if the risk becomes a reality

4. Assess how big of a problem this is, on a scale of 1-5

5. Select the probability of the risk happening, on a scale of 1-5

6. Select your response (discussed later)

7. Write out how you'll respond. With larger responses, this becomes a link to a risk response document. (discussed later)

8. Select an owner for the risk

I've inserted an example from a recent newsletter: I sent a mail with a dead link to you and 6,000 other people. Ouch.

3. Respond to your risks

Now that you have your risks listed and rated for impact x probability, column F shows you the priority. The higher the priority, the more attention the risk deserves - both during the planning and during the execution of the project.

The owner that you've assigned earlier is often the person who brought up the risk, but it doesn't have to be. What's important is that she or he understands what comes with the responsibility:

• You own the risk from the identification until project closure

• You create & own the risk response, and keep it up-to-date

• You're responsible for the ongoing risk monitoring

• When needed, you're in charge of taking action

As a project leader, it's your job to give the risk owner what they need to come up with an appropriate risk response. This can be resources, time, tools, access to people - anything. Facilitate them, don't tell them how to respond. They have to feel ownership from day one.

For smaller projects, this can be a 2-hour meeting with a hand full of risk owners.For big projects, this can be a process of weeks and 1:1 meetings with risk owners, while you're working on other parts of the plan.

Ultimately, it's your responsibility to ensure all risks are logged with a response, and that the overall project risk is acceptable for your organization.

The TAME framework for risk response

So how do you respond to risk? As you've seen in the template, you have 4 options. Let's look at them one by one:

T = Transfer

Transferring a risk means moving it to someone else. While this sounds like passing on a turd, it's far from that. While something is a high risk for you, a contractor might have more experience, different systems, or better tools. If it's less risky for them, they might be happy to take part of your scope for a reasonable contract fee.

Two other popular transfer options are to insure yourself against the risk or to build contract clauses where another party takes responsibility for consequences if their delivery is delaying the total project.

A = Accept

Sometimes, transferring, mitigating, or eliminating risk is impossible or not cost-effective. Every project has a different tolerance for residual risk, and it's crucial that you establish this with your executive sponsor.

If your sponsor demands a 0-risk project, remind them that they probably drove to work this morning. While cars are very safe these days, there's a small residual risk you accept every time you get behind the wheel.

A medical trial has a lower tolerance for risk than building a software prototype You have to find your project's spot on that spectrum and adjust your risk response accordingly.

For example, there's a small risk of a typo in a newsletter link. Because both the impact and the probability are low, I choose to accept that risk.

M = Mitigate

Mitigation means you'll take action to lower either the probability or the impact of risk, thus lowering the total risk score. You can think of implementing additional controls, tests & procedures, or giving team members additional training. These all lower the probability.

Other common mitigation strategies are contingency budgets and time buffers - these don't impact the probability but reduce the impact on the total project.

While this will lower the total risk score, it's unlikely to reduce it to zero. Mitigate it so far that the remaining residual risk is acceptable, without becoming cost inefficient.

E = Eliminate

If you're lucky, it's possible to eliminate a risk completely. You could do this by changing the scope, redesigning a process, or using a different supplier for example. While this sounds attractive, make sure to explore all options - eliminating something could be 5x more expensive than accepting a very low residual risk.

Bonus

Experienced project leaders often stack different methods from the TAME framework. How about changing a process to lower the probability (Mitigate) and insuring yourself against the residual risk (Transfer)?

4. Monitor and control risk

Once you have your risk response plan in place, you can move ahead with your execution. But it doesn't mean you're done!

Context changes.

Assumptions are proven wrong.

And all of a sudden, the probability of a risk goes 2x, or you need to add a new one to the risk log. That's why you need to hold regular project risk meetings.

In these risk meetings, you gather all risk owners and go through the risk log one by one. Each risk is discussed, and the owner explains if anything has changed that means you need to take action.

This step is often overlooked, but doing these well keeps you on top of risk throughout your implementation. Please, don't sleep on this.

Putting it all together

Risk ruins projects, but it also provides opportunity. By being comfortable with a little risk and having a good plan in place, many projects can be done in far less time or for half the cost. Be strategic about it, and always involve your executive sponsor.

Risk management in 4 simple steps:

1. Identify

2. Analyze

3. Respond (TAME)

4. Monitor and control

Risk management is simple, but not easy. Please reply if you have any additional questions, and let me know how you like the template. I'll gather all questions and do another follow-up in the near future.

That'll do for this week - until next Tuesday!

Cheers,Jasper