My boss wants a risk management plan; what is it and how do I get one?

Keeping your project on the rails is a breeze if you follow a few essential steps. Here’s an easy plan for destroying risk and succeeding where others fail.

Photo by John Moeses Bauan on Unsplash

Risk management made easy

“Risk management” sounds intimidating. It sounds like something you do for a government body or maybe the Department of Defense. I think most people find it intimidating because of complex frameworks, matrices, and formal methodologies that can seem overwhelming. The terminology and structure makes it feel academic and impractical — especially for people who are just trying to get things done.

I’m going to break those preconceptions. I’m going to show you a simple, 3-step approach to managing all the risk right out of your project.

And while doing it, I’ll also show you how to succeed where others fail — because they are still intimidated by managing risk when you won’t be.

Plus, I’ll give you two templates to work from — one wiki page and one spreadsheet. You can pick which one you prefer.

If you’re new, welcome to Customer Obsessed Engineering! Every week I publish a new article, direct to your mailbox if you’re a subscriber. As a free subscriber you can read about half of every article, plus all of my free articles.

Anytime you'd like to read more, you can upgrade to a paid subscription.

Why “risk” is scary

There are a few other reasons “risk mitigation planning” turns most of us off. Before we see how simple it can be, let’s dispel some of those myths and preconceptions.

People are afraid of uncertainty and failure. It’s just part of our nature. It takes a rare individual to charge headlong toward the threat. And risk management is basically forcing us to confront uncertainty and potential failure. Most people prefer to avoid thinking about what could go wrong. But I’m going to ask you to deliberately examine how you can fail — which can feel uncomfortable. It's psychologically easier to assume things will work out fine. But, I think there’s a mental shift that will flip that script. Instead, look at is as planning for success. Instead, anticipate the other side of this journey: walking away knowing that you examined everything that could possibly go wrong, and that you’re prepared for it.

Some may be turned off by perceived over-analysis paralysis. I know, focusing too much on “risk analysis” could seem like endless planning without action, or that dwelling on too many potential problems will make a project seem impossible. Let’s dispel that right now: in this article, I’ll show you how to make risk management an easy, day-to-day action that doesn’t slow you down.

You need deep experience, or lack a clear starting point. You might feel that without experience, it's hard to know where to begin or how comprehensive the process needs to be. It feels daunting. Just like the previous point — I’ll show you how it’s actually easy.

Time and resource constraints mean “we can’t do this now.” Risk management can seem like additional work on top of already busy schedules. But what’s going to happen when those unplanned-for risks materialize and derail your project? The cost of dealing with problems later are much higher and often crippling. On the other hand, preparing ahead of time needs just a tiny bit of effort now and returns huge benefits later — by successfully avoiding failure.

Overestimation of what it takes. Most people avoid risk management thinking it needs to be highly sophisticated or require specialized expertise. In reality, much of it is just common sense — thinking ahead about what might go wrong and making sure you have a backup plan. I’ll show you how to capture that forward thinking into a concrete plan.

The irony is that most people already do informal risk management every day. They check the weather before leaving home. Keep some emergency funds on hand. Backup important files. “Risk management,” by any other name, is just a little preparation for sweet, sweet success.

Risk management 101

In planning this article, I wanted to compare my own approach to readily available “accepted wisdom.” What I found was overcomplicated and boring. Most formal risk planning talks about 5-7 “steps” using lots of words that will have most people’s eyes glazing over — like “quantitative risk analysis” or “probability impact matrix.” You can ignore all of that.

The approach I use is practical. I’ll even explain those eye-glazing terms — toward the end of this article — so that you understand them and can decide if there’s value you can extract from those concepts.

But what we’re going to do is much easier.

Practical risk management

Risk management really comes down to two very common sense things: first, we have to be aware of a possible problem before it occurs, and second, we need to prepare and respond with a suitable solution.

There is, of course, subtlety to these two ideas.

1. Risk awareness. How do we become aware of potential problems before they happen? And once we are aware, exactly what do we do about them?

2. Risk response. Should we handle different kinds of risks in different ways? For instance, what about a risk that probably won’t happen, versus one that almost certainly will happen? And how can we be sure something isn’t ignored?

In my experience, things tend to break down largely at the second point. Nearly every team I’ve worked with is aware of risks. In fact, most of them were already writing down their risks before I showed up.

The problem is that’s as far as it went. Risks would get noted down on a wiki, or work ticket somewhere — and then they became orphans. Nobody did anything about it.

Each team member thought, “I did my job — I told everyone about it.”

But that’s wrong thinking. That is not everyone’s job. Everyone’s job is to shepherd the project to success — to delight customers. We can’t do that if we ignore that massive, looming risk that we know is going to hurt deeply in the future.

So the most important take away here: you aren’t done until the risk is done, too. It’s an existential threat to your success. Pounce on it. Kill it. Destroy it.

Writing a valued tech journal is hard! But, you can help — comment about what you like! Let me know about the biggest risk failure you’ve run into. Most important, please refer a friend (you’ll earn free premium access)!

3-step risk management

I’ve developed an easy to use, practical and effective risk management plan. It decisively captures risks, prepares your team to handle them and ensures each one is dealt with. Most important, it doesn’t require a lot of preparation and heavy analytics.

I’ve also provided two templates you can use to implement this risk management plan; one uses a wiki-style approach, and the other a spreadsheet-style. Each one accomplishes the same thing, but one nice feature in the spreadsheet is that it uses a formula to calculate urgency. Basically, that’s an added benefit that helps relieve some of the manual work versus the wiki. (Both templates are linked below).

The plan separates risk management into three distinct activities: capture and awareness, response planning, and ensuring your plans take place:

1. Risk awareness. Risks are documented and added to your risk log.

2. Response planning. New risks trigger immediate planning activity and may change your project status.

3. Monitoring. Risks become escalated tasks in the team backlog, triggering increased activity until resolved.

Following are the details of each step in the plan. A complete “risk plan outline” is summarized at the end, for handy reference.

Risk awareness

This is usually the easy part, because generally speaking it’s not awareness that’s the issue. Too often, after the fact we hear, “yea, saw that coming.” Step one of our plan is to make sure every risk is added to your risk log. As well as noting down the risk itself, we’ll also record its likelihood and its severity:

1. Likelihood. This is how probable the risk is — in other words, the chance of it actually happening. I usually use a scale of four: improbable, possible, probable, certain. (“Certain” basically just means “it’s definitely happening.”)

2. Severity. This describes how bad the situation would be if the risk comes to fruition; in other words, what’s the impact to the project. Here, I use a scale of four as well: acceptable, tolerable, undesirable, intolerable. (“Intolerable” means we can’t proceed without addressing the risk).

The likelihood and severity scores are intended to be reasonably intuitive. There’s no heavy math behind them:

1. Likelihood

   1. Improbable — it’s rather unlikely the risk would actually occur.

   2. Possible — there’s a good chance it will occur, like a 50/50 coin toss.

   3. Probably — it most likely will occur (but it might not).

   4. Certain — it absolutely will (or maybe, already has).

2. Severity

   1. Acceptable — we don’t love it, but we can live with it just fine.

   2. Tolerable — it won’t prevent anything from working, but it’s really not great.

   3. Undesirable — there’s a workaround, but it hurts product function.

   4. Intolerable — we cannot proceed without a solution.

We can see our risk categories visually using a “risk heatmap.” The heatmap shows the conjunction of likelihood and severity, imposing a degree of escalation as both increase.