Product
Solutions
Resources

Why You Need a Risk Management Process (+ Free Template)

risk management process

Can you afford to lose $185 million?

That’s what Wells Fargo had to pay in fines after failing to apply a working risk management process.

Their lack of attention to the risk and pressure that they exposed their employees to led to sales practices that were bad enough to cause 5,300 employees to be fired and the penalty fines mentioned above.

Risk is inherent in everything we do – from conventional ideas of the risks in gambling to the chance of collisions while traveling. In business, risks can come from any direction and can severely impact your output.

Whether you wake up late and get less work done because of it or someone doesn’t get their work done on time and holds up the rest of the team, you need to be able to predict, prepare for, respond to, and monitor the things that can go wrong.

That’s why our post today will examine everything you need to know to build a risk management process to make your work watertight. We’ll even throw in a free, fully-built risk management process for you to use!

If you want to skip to a particular section then feel free to use the links below:

Let’s get stuck in.

Why you need a risk management process

“Risk management is just common sense – as long as we’re careful we shouldn’t have a problem.”

I was listening to one of my regular podcasts when the topic of having a risk management process came up. Suffice to say, I wasn’t impressed with the idea of (as I saw it) tying myself up in red tape when I could be getting on with my work and dealing with things as they come

After having my work blow up in my face due to unexpected circumstances more times than I can count, I now see why risk management is so vital.

A risk management process provides you with control over the worst that can happen. It’s your safety net in an unpredictable world.

It’s no understatement to say that it forms the backstop of any survivable company, from insurance brokers to SaaS teams.

In insurance, it’s easy to see the effect of risk assessment and management. Heck, insurance itself is akin to betting against the broker that something will go wrong – the higher the likelihood (risk) of something happening, the more expensive it is to insure yourself.

In regular businesses it’s much less visible, leading risk management to have a largely underplayed role. Nevertheless, it’s vital to your team’s (and business’) survival.

Think of the last time that something bad happened at work.

Maybe someone missed a deadline, a delivery didn’t make it on time or a power cut prevented your team from getting their jobs done.

Every consequence – every last piece of damage – that those situations caused could have been avoided if the risk of those situations had been assessed and managed.

The trick is to avoid thinking about “risks” as conscious gambles for a better result. While this covers some of the situations you need to account for, it will inherently make it more difficult to see the things you take for granted.

Instead, think of “risks” as the likelihood of a negative situation occurring. If something can go wrong (no matter the track record), you need to be able to act if it does go wrong.

That’s where your risk management process comes in.

The risk management process

risk management process
(Source)

Before we dive into the standard risk management process it’s worth noting that there are different processes designed to meet certain standards, based on what’s required by the industry you’re in.

ISO 31000 and COSO are some of the biggest contenders for documented risk management standards, with ISO 31000 being a set of guidelines for companies to get started with risk management, and COSO being aimed towards enterprise risk management.

However, these systems are vast to the point that they need dedicated material to convey them sufficiently. This post isn’t aiming to give you an exhaustive rundown on every aspect of the risk management process but, instead, a rough summary which you can use in any situation.

If you want to learn more about ISO 31000, check out our post on the topic here:

The risk management process we’ll examine is made up of five steps:

Let’s go over these individually.

Set and align your objectives

First, you need to set clear objectives for whatever task, project or process you’re going to be assessing. This will help you make sure that all work goes towards improving the result and gives you guidelines and what kind of negative results can be expected.

The key here is to make sure that your objectives are simple enough that anyone can understand them.

You also need to check that your objectives align with your business strategies. This isn’t important to the risk management process itself but it is vital for assessing the goals of your work and the likelihood of the various risks involved occurring.

Take our company for example.

Our mission statement here at Process Street is to make recurring work fun, fast, and faultless for teams everywhere. This is relevant to everything from our product to this very blog post.

The objectives of this post are to instruct and educate readers in the most comprehensive and easy-to-understand way possible, while getting traffic by ranking highly in Google. We approach every post with the objective of being better than any other existing content for the keyword we target.

This gives vital context for the risks associated with our blog posting project as a whole and this post specifically.

To expand on that, we need to…

Identify and document risks

Now you need to identify and document the risks associated with the task, project or process you’re examining.

This is self-explanatory – you should think of anything that could prevent you from meeting the objectives previously set out. Try to take nothing for granted, no matter how large or small the risk may seem at a glance.

Here’s where I used to trip up all the time in my work.

I had a habit of taking certain tasks for granted. Social duties would take a half-hour every day, writing would take four hours and I’d get X number of words written, and so on.

The only risks I’d identify with writing my blog posts would be broad topics such as finding a suitable keyword and submitting my image requests a couple of days before the publish date.

That approach was, frankly, rubbish.

Here’s the kind of list I should have been building for my blog posts:

  • Images might take longer than expected
  • Family emergencies
  • Power cuts
  • Internet outages
  • Keyword difficulties
  • Severe edits
  • Time for feedback
  • The topic is broader than first thought

That’s not even mentioning basic risks such as the website being online!

You can see what I’m getting at – the key is to go into as much detail as possible and cover everything that has even the slightest chance of messing with your objectives.

Assess documented risks

Once you’ve identified and documented the risks that your chosen project presents it’s time to assess them.

The goal is to qualify how likely each risk is to happen, when it will happen in the project’s timeline and how severely it will affect your ability to achieve your objectives.

The best way that you can do this is by using a system to prioritize each risk.

For example, you could use a prioritization matrix to differentiate between risks that are high importance, high impact, both or neither. Risks that are high impact and importance should take precedent when it comes to dealing with and responding to the risks.

risk management priority
If you want to know how to make a prioritization matrix, check out our post on the topic! (Source)

Let’s apply this thinking to our (basic) previous list of risks when creating a blog post. In this case, each risk would probably earn the following distinction:

  • Images might take longer than expected – high impact, low importance (I could always create images myself, albeit of lower quality)
  • Family emergencies – high impact, high importance (these are unpredictable but unavoidable and result in complete time off)
  • Power cuts – high impact, high importance (for the same reasons as family emergencies)
  • Internet outages – medium impact, high importance (after research, the majority of work can be completed offline but a connection is needed for final upload)
  • Keyword difficulties – low impact, medium importance (a keyword needs to be set before work starts on each post but a topic can be replaced if no suitable keyword is found)
  • Severe edits – medium impact, medium importance (edits will take extra time but they should be achievable and improve the quality of the post once complete)
  • Time for feedback – low impact, medium importance (feedback is important to get but giving enough time to give it is relatively simple)
  • The topic is broader than first thought – low impact, low importance (if a topic is too much for a post to cover the focus of it will need to narrow)

Now that we have prioritized our risks it’s time to respond to them.

Respond to risks

Risk responses, in general, are typically easy to think of but hard to optimize. The key is finding a solution which is effective at mitigating the likelihood of something going wrong, limits the impact it will have if it does go wrong, and is worth the resources put into carrying out the safeguard.

In other words, you need to aim are the core of each risk and do your best to weed it out entirely.

There are four main methods of doing this:

  • Avoidance
  • Acceptance (sometimes called “retaining“)
  • Mitigation (otherwise known as “reduction”)
  • Transference (alternately, “sharing”)

We have covered these responses in more detail in our full risk management guide but, for the sake of ease, I’ll summarise them here.

The basic point of risk response is to take your assessed risks and, based on their importance and impact, plan how to avoid the risk altogether, limit the effect of an unavoidable risk or involve other parties to share the risk.

The other alternative is to take a gamble and move forward despite the risk (usually reserved for when multiple parties agree that the risk is worth the reward).

As mentioned earlier, the response that you take will depend on the severity and likelihood of the risk you’re responding to. You also need to bear in mind how resource-intensive your solution is versus the effect it will have and the severity of the risk in the first place.

You don’t want to spend time and money trying to mitigate a risk that was never going to be impactful in the first place. That’s why it’s so important to identify the risks that matter and assess them accordingly.

In my blog post example we could take the following methods to mitigate or eliminate the risks involved:

  • Set the deadline for posts to be two weeks before the publish date – this gives extra time to limit the impact of every risk posed to the blog post
  • Images need to be requested when writing has just started – this allows our graphic designer to work on the images while the post is being created, leading to more than enough time for the graphics to come together
  • Peer reviews can be introduced at the first draft stage to allow for feedback to be given before the bulk of cleaning-and-writing-up has been done – this will lessen the impact of severe edits as the plan can be approved and improved before too much time has been spent
  • Our team should each have multiple backup locations that they can go to in the event of a power or internet outage at their main office – this is possible due to having a remote team but the two-week deadline buffer should mitigate this risk for in-office teams too
  • Keyword (and topic) details and options should be presented to the rest of the team once found – this will allow us as a whole to agree on what the post should focus on without the writer alone getting confused and lost in a topic

The responses you take will vary greatly but you can see the logic behind each decision.

Aside from the initial catch-up period, the two-week buffer for our deadlines has required no extra time or effort on our end and completely solves the risk of items taking more time than we thought. The deadline shouldn’t be pushed back but the leeway those two weeks gives us is a massive improvement to our old blog posting system.

Monitor risks

lusitania risk
The Lusitania suffered as a result of taking a risk by bringing civilians into a war zone. Risks aren’t always life-threatening but that doesn’t mean you can ignore them. (Source in public domain)

Once you’ve responded to each risk it’s vital to have a system which allows you to monitor them going forward. This will let you see the effect that your responses have, whether further action needs to be taken, and so on.

The system you use will depend on the risk you’re monitoring but let’s go through the blog post example we’ve been using to demonstrate.

Most identified risks (power cuts, missed deadlines, etc) can be monitored by merely keeping track of each blog post. If something goes wrong and causes the deadline to be missed then you need to talk to the people involved and find out what the issue was.

There’s also the chance for other issues which you didn’t account for to become clear further down the line – you can’t always predict where difficulties will lie.

Either way, once an issue has been reassessed or identified it’s time to start the risk management process again to take action on it. That way you can mitigate or remove the risk before it causes any more issues.

If no changes to your identified risks are observed, it’s still worth running this process at least quarterly to stay on top of your projects and the issues that could affect them.

How to deploy a risk management process

Deploying a new process is always risky. Problems can crop up in any direction.

However, let’s keep things simple. Let’s say that you’ve adapted the risk management process above to your own needs and planned the implementation to the point where, in theory, it shouldn’t clash with any existing values or processes that the relevant team holds or carries out.

If you don’t have a solid change management model in place, the entire process can fail when it comes to getting your team to take the new practice on board.

A team that isn’t prepared for and guided through a new process isn’t going to have any attachment to it and may not understand why each step is important in its own right.

Plus, we all know that a process carried out badly can be more damaging than one not implemented at all.

Work through the new risk management process with everyone who the process will affect from top to bottom. Explain why it’s being introduced and give tangible ways that it will benefit their work and make life better for them.

Above all else, encourage them to ask questions and give feedback. The more they talk and get involved, the more ownership they will feel over the new process.

If your team feels that they were part of forming and adapting the process, they’re more likely to understand its value and carry it out correctly.

For more information on (and examples of) change management models, check out our post on the topic:

Your free risk management process template

risk management process checklist
(Source)

We here at Process Street know how useful it is to document your regular processes. It lets you quickly train your team with detailed instructions, delegate tasks effectively, and ensure a consistently high level of quality in your results.

We also know how much of a pain it can be to build your processes from scratch.

That’s why we’ve built a full Risk Management Process which you can use for free!

This process template is built out and ready-to-use with detailed instructions for every step.

The process is also fully customizable to your needs, lets you assign team members, track individual checklists run from your process, automate it through integrations with other apps and much, much more.

Grab your free Risk Management Process and Process Street account today!

How do you manage risk? Do you have any tips for others to use? We’d love to hear from you in the comments below!

Get our posts & product updates earlier by simply subscribing

Ben Mulholland

Ben Mulholland is an Editor at Process Street, and winds down with a casual article or two on Mulholland Writing. Find him on Twitter here.

Leave a Reply

Your email address will not be published. Required fields are marked *

Take control of your workflows today