Making risks more visible to make them part of regular conversation
The recent Covid-19 pandemic took most people and organisations by surprise, including most of the UK public sector.
"It's a black swan event," people say, "there's no way it could have been predicted."
But that's not true. It was predicted, and it should have been totally expected.
Since 2008 the UK government has published a National Risk Register. Pandemic human disease has always been at or near the top of the threats identified.
Here's the chart of risks from the National Risk Register published by the Cabinet Office in March 2010:
You can see that pandemic has the same likelihood as severe weather — but more impact than any other risk by quite a distance. That combination made it the highest risk identified. It has remained at or near the top in every update to the national risk register since.
So why were people so taken by surprise?
Because the information needed was in a report, that they probably read once (if at all), and then didn't refer to again. Maybe in parts of government it was on some other documents that also got read once and filed too. But there were 'other distractions' that seemed more urgent at the time.
And so this major risk, that could derail the entire economy and leave so many people dead or with lasting health issues, wasn't a regular part of conversation.
It's the same with more common risks in the delivery work at a lower level.
How many times have you seen a risk register diligently prepared at the start of a project as big spreadsheet with lists of things and scores and cells that are red amber or green.
It gets prepared for sign off at the beginning — but then it gets saved on a shared drive and forgotten until some governance meeting further down the line asks for it and it's hurriedly updated by a delivery manager.
It is treated as only a compliance step, not a valued part of the delivery toolkit.
Having seen this approach on so many projects in so many organisations, I wanted to experiment with ways to make risks more a part of everyday conversation. This came out of my wider work on Healthy Governance, and I'd done some research interviews with stakeholders and teams — and found that nobody really wanted risk spreadsheets, they just thought they ought to.
Stakeholders just wanted reassurance that teams were aware of risks and were working to manage and mitigate them.
Within wider agile and lean practices there is the idea of the 'information radiator', making things very visible and simple rather than having complex documents.
So about five years ago I started experimenting with not doing a risk register at all, and instead showing risks on an information radiator. I wanted to do it in as simple a way as possible, so that what mattered was the conversation between teams and stakeholders rather than the documentation on a shared drive.
After sketching out a few ideas I came up with the idea of the risk radar as the simplest thing that might work. At first it was just drawn on flipchart paper or on whiteboards, but then gradually we've used tools like Miro to be able to work across multiple locations. It just looks like this...
Then with sticky notes (real or virtual) we capture a short meaningful headline about the risk on the board (I've just created some random examples here)...
At its simplest (which is how teams should start to use it before iterating it to work better in their context) there is only one type of sticky note, and the only variable is that being closer to the centre means the risk has higher 'proximity' to the team in that it could happen sooner or closer to home.
Then, this board should be visible, in every single project meeting or discussion. The idea is to keep the risks on it in people's minds, and to prompt conversation around these risks. But also, as other risks become apparent in the project, it should become second nature to say "let's put that on the radar" or similar.
At a regular cadence in the project, such as each sprint if you use Scrum, you run through the risks on the board and decide to add or remove risks, or to move them around to represent where the team feels they are now...
That movement is one of the key things to watch, and to discuss with the team and stakeholders. It's worth drawing in the line of travel to show the movement of each note, so people who aren't in the meeting where it's moved can easily catch up with changes and bring them up for discussion.
Remember, everything that is on the board is a prompt for conversation, so do regularly bring it up for discussion.
Identifying risks to put on the radar
At first you only have a blank radar screen on the board, and it can seem hard to think about what to put on it. While this is no different from figuring out what to put in the old risk registers, I think we can make this easier and more effective.
When running inceptions on new projects, I run a pre-mortem. I set the scene that it's a year from now. The project has gone so horrendously wrong that someone senior has had to resign, there are questions in parliament and the National Audit Office (NAO) has come in to do a report. Now, imagine you are the NAO team in that situation, and imagine the things you find that caused things to go so so badly. What are they? That generates lots of hilarity, and lots and lots of ideas for problems that might come up. We don't gather them on the radar yet though, just in a big cloud of problems on the wall.
We get to the risk radar towards the end of inception, when the dust has settled from that exercise, and there have been lots of other exercises understanding the vision for the project, mapping the stakeholders and more. During all of these exercises, my colleagues are briefed to be quietly listening for risks hidden in other discussions that come up ("I guess that depends on when the new CEO is appointed," someone might say. "Aha, there's going to be a change in CEO," my colleague will note. "That sounds risky to projects!"), and capturing them.
Then, when we get to the Risk Radar section I tend to break the session up into thinking at different altitudes, one at a time, which gives more context and so feels more constructive and manageable...
At each altitude we think about what risks might present themselves, then we also refer back to the risks found in the pre-mortem, or that my colleagues have captured during the other sessions, and sum these up on a single sticky note per issue onto the radar.
These sessions generally end up with way more suggestions for risks to track than can practically be kept on the board, so then we have a discussion about merging notes, or about some that can be parked. Parking them puts them in a cluster of notes outside the radar that can be reviewed from time to time to see what should be brought onto the radar screen.
You ideally want a maximum of a dozen notes on the radar at any time.
How to consider national and global risks
There are some risks that will come up at these altitudes that will seem impossible to do anything about. A pandemic could be a good example of this. What you need to do in that case is think about the risks that would be presented in your domain, by that big risk.
So, for example, if the big risk was a pandemic, you might put the following risks on your radar:
- Unable to access the office
- Team members unable to travel
- User interviews and testing with users need to be done remotely
- Key or multiple team members off work or with reduced availability
Now what's interesting is each of those could be caused by other things than a pandemic (eg a fire, flood, terrorist attack, transport disruption and so on could all mean you're unable to access the office. Or even a team member breaking their leg playing 5-a-side could mean they're unable to travel or access the office for a while). So by preparing for these and monitoring for them you'd be resilient in a whole host of scenarios.
That's exactly what we did at Convivio. We knew pandemic was on the national risk register, so we prepared for the risks that might directly affect us, as above. And we were then alert to them arising. We saw the first warning signs that moved pandemic onto our radar board in late December 2019, and on 11th Jan 2020 we updated our preparations fully (and advised others to update their business continuity plans too). On 28th January 2020 we emailed our clients with details about the risks we had assessed and our preparations. We offered to help clients prepare too, and provided some with 4G dongles to help with working from home.
Having conversations around the Risk Radar
Remember that the whole idea of this is to be an 'information radiator' that prompts useful conversations. So do take the time to have those conversations, whether that's in regular project ceremonies, in governance/steering meetings, in team meetings or general project discussions.
Things to raise for discussion:
- What action can we take to feel we can move this risk further out?
- What preparations do we need to make for the closest risks? What could we do that would reduce their likelihood or impact?
- Why has this risk moved in the way it has?
- What is worrying us, but not on the radar?
- With this risk, what are things we might see happen that would cause us to be more concerned and move it closer?
Developing the Risk Radar further
As you start to use Risk Radar, you should be open to adapting it, like anything else in the team's work, based on things that come up in retrospectives or ideas the team have.
I've trained lots of client teams in using the Risk Radar, and presented it at various GovCamps, Delivercamps and so on over the years. From time to time I hear back from teams on how its going and how they've evolved it. Some ideas I've heard/seen include:
- Things in front of the plane on the screen are external risks, things behind the plane are internal
- Things directly in front of the plane are the more likely risks, things that are further to the sides are less likely to hit.
- Different size/colour sticky notes to denote the magnitude of the risk and its potential impact
- Different colour sticky notes to denote different risk topics / teams / other things
Start with the Risk Radar being really basic and only experiment with these 'upgrades' or your own ideas when it's running well in its basic form. And don't feel you have to experiment at all. Let it be driven by the needs of your team and the context of the project.
We've published the Risk Radar in the spirit of openness and sharing. You're free to take it and use it. I love hearing stories about how teams are using it though — my email is firstname.lastname@example.org and I'm on Twitter as @steveparks. Do drop me a line.
We can also provide training sessions on how to use it, run inception workshops based on it for your projects, or provide coaching to teams and stakeholders on approaches to risk and resilience.
I hope you find the idea useful, and it helps you create a healthier approach to risk in your work. Good luck!
Convivio is a challenger consultancy, helping knowledge-work organisations be more effective in the digital age.