Making risk management work (4): The tools you need

This post is part of the Content Is The Web risk management series.

This post explains the tools and tables you’ll use to manage risks properly. It follows on from earlier posts about the framework and conversations that risk management uses.

The short version:

Each risk is documented in a separate report, and each piece of content you work on needs a register of all its risks. So long as you’re having the right conversations and following the framework, this is basic admin.

There are two main tools: a report for each risk, and a register of all risks.

Each risk is documented in a separate report

Each risk has its own report, which contains everything you need to know about it. In most cases this doesn’t need to be any more than a one-pager (whether physical or digital). However you construct them, make sure you have a decent filing system.

A risk report tells you:

  • Which content the risk relates to – this can identify the page or document you’re dealing with, or be more specific (e.g. ‘About Us, paragraph 3’)
  • Who the risk reporter is
  • The risk statement
  • The initial risk assessment (shown on the severity table)
  • Mitigation actions, assigned to an individual
  • Later assessments (after mitigation)
  • Acceptance detail – the risk owner who’s accepting the risk, and the date.

The main thing risk reports do is track responsibilities, and hold the all-important signature from the risk owner when the risk is accepted and your content is one step closer to publication.

As a risk moves through the stages I introduced in part 3, you update the risk report.

Report: As soon as a risk is raised, start a report and fill in the first three details (what the content is, the risk reporter, and the risk statement).

Rate/Re-rate: As you hold full risk conversations, you can properly assess the risk.

Accept? If you think the risk is acceptable, get the report in front of the risk owner and see what they say.

Mitigate: Set and record tasks, and document whose responsibility they are.

Accepted: When the risk owner is happy to go ahead with things the way they are, get it in writing!

Report, rate, then either accept or mitigate.

Each piece of content you work on needs a register of all its risks

A risk register gives you a single place to see progress on a given piece of content. The more content you work on, the more risk reports you’re going to have, so a register is an easy way to group reports.

Risk registers work best as spreadsheets.

  • Content name or identifier
  • Risk owner – remember from part 1 that each piece of content has one single risk owner
  • For each risk:
    • Risk statement
    • Current assessment
    • If it’s not accepted yet, the name of the person who’s working on it

So long as you’re having the right conversations and following the framework, this is basic admin

If keeping this documentation up to date is difficult, you probably have a bigger problem. The paperwork is deliberately straightforward and simple because the hard parts, if there are any, come in the conversations (i.e. teasing out all the details you need from risk reporters) and in setting up the framework (i.e. agreeing on how to measure likelihood and consequence, and working out what level of risk is okay to take).

Ladies and gentlemen, that’s it

This is the end of the Content Is The Web risk management series. I really hope you can make some good things happen with this approach. Please, let me know what you think, or ask me questions – leave a comment here or tweet @MxDEJ.