Risk Identification Techniques and How to Brainstorm Well

Risk Identification Techniques
Risk Identification Techniques

At the start of every project, you as a project manager (PM) have a lot of important things to do, and you don’t want to forget any of them. They may all be priorities, but near the top of your list is figuring out what could go wrong – because, take it from me, plenty will!

The risk management process is core to our practice of Project Management. It crosses the boundaries of all project types, from the tightest of predictive projects, to the most agile and flexible of adaptive projects. At the start of the process are two conversations: one strategic, and one tactical.

Strategic and Tactical Risk Kick-off

The strategic conversation is about the project’s appetite to incur and manage risks. Some will, rightly, want to minimize all scope for risk. While others, because of their need to innovate and step into the unknown, will have a far greater tolerance for risk. This will set the tone for much of your decision-making.

On top of this, we layer the risks we can foresee. Predicting foreseeable risks will be an ongoing and never-ending process throughout your project. In the jargon of project risk management, this is called “Risk Identification.” In lay-person’s terms, it is simply spotting anything that can go wrong.

Many PMs have similar training or grow up in the profession reading similar entry-level project management books. They learn how to manage risk by getting their team together and running a risk identification or risk kick-off workshop. At that workshop, we identify risks by brainstorming everything we can think of.

And there’s nothing wrong with brainstorming.

There is a huge value in an all-hands workshop, and brainstorming is…well, okay, but not great. So, let’s see how we can optimize what’s good, and add some extra resources to your toolkit.

Risk Identification Workshop Structure

There’s no ‘right way’ to structure a risk workshop, but the points to hit are:

  1. Welcome and Introductions: Include the context and objectives for the meeting, its agenda, and why it’s important for everyone to contribute.
    Pro Tip: If you can get your Project Sponsor to lead this part, it will add to the impact of the whole meeting.
  2. Basic Project Context: Define the goal, scope, and approach the project will take, to set the risk identification process in context. This will ensure that everyone has a common understanding.
  3. Risk Identification: Use a selection of techniques to access the group wisdom on all the things that could go wrong.
  4. Risk Processing: Determine how far you want to go  with classifying, analyzing, prioritizing, planning, and allocating the risks you identify. Draw a balance between your desires to (a) make a lot of progress, and (b) dedicate good quality thinking time to important matters.
  5. Next Steps: Wherever you decide to stop, remember that it won’t be the end of the process. Spell out what will happen next and any responsibilities you wish to allocate.
  6. CloseAs with the welcome, this can set the mood going forward. In the same way, if you can get your sponsor to lead on this and thank your team, it can have a big positive impact.

Brainstorming Well

Brainstorming can work well. But often, it doesn’t. At best, it gives mediocre and sub-par results. So, let’s understand when it can work best, and how to facilitate it.

Brainstorming can easily degenerate into a confusing mess, where the most vocal get heard, and it is their ideas that shape the processes. So, to counter this, avoid brainstorming with large groups. This way, you can control the process better and ensure that everyone’s ideas get through.

I recommend that you split the facilitation role, with one person focusing entirely on the group’s experience, and giving everyone a chance to speak. Have someone else write down the contributions, ideally with their back to the group to avoid distractions.

This role of scribe is important. To fully respect what people say, you need to write down their words exactly as they say them. If you interpret or “improve” them, you risk losing connection with the contributors. If the two facilitators cannot keep up with the pace of contributions, or make sure quieter members have their say, then the group is too big!

Brainstorming 2.0: Brainwriting

For larger groups, split them into tables of three to six people and put a big pile of blank cards (6” x 4” or A6 is ideal) and pens on each. Ask people to write their ideas on cards, with one idea per card. Allow a fixed time for this – five minutes is usually enough. Some background music with a fast pace can help – but nothing intrusive. In five minutes or so, you’ll have loads of ideas.

At the end, gather the cards on each table, and move each pile to a new table. In the next five-minute session, ask people to take a card and add to it, either with an expansion of the idea, or a suggestion for mitigating the risk. If it prompts them to think of something new, ask them to put it on a fresh card. You could do two rounds of expansions, and then three rounds of mitigation ideas. Rotate the card stacks to different tables each time. You can fit all six rounds into 45 minutes – imagine how many ideas and solutions you’ll have. Then end the hour by clustering the cards into logical groups.

Identifying Sources of Risk

A great way to identify a load of risks is to start with categories and look for things that can go wrong under headings such as:

  • Social, Societal, and Sociological
  • Political
  • Economic and Financial
  • Commercial and Competitive
  • Technology
  • Regulatory and Legislative
  • Environmental
  • Safety and Security

This is my “SPECTRES of the Future” framework, which I developed for my book on risk management, Risk Happens! But you can use other headings too, for example, these good old Project Management favorites:

  • Time or Schedule Risks
  • Cost, or Budget Risks
  • Scope, or Functionality Risks
  • Quality, or Value Risks

Risk Breakdown Structure

We can even take this approach to the max. Indeed, perhaps this is the most rigorous way of determining all possible risks to a project. As a result, this is not a Definition or Initiation stage risk identification method. It relies on having a complete Work Breakdown Structure for your project.

Once you have a full WBS, you can extend it to create a Risk Breakdown Structure (RBS). For each product at the base of your WBS (or activity, if that’s how you create them), consider all the risks that flow from it. This way, you can create an RBS dictionary, from which you can build out your Risk Register.

Will your RBS contain every risk? No, of course not. The particular danger with this approach is missing the big picture risks that span whole areas of your project – or the entire project. So, powerful as this method is, it should complement other techniques, and never stand alone.

Experts

I am going to mix a few approaches under the title of experts. Clearly, subject matter experts will have a particular insight into some specialist risks. However, they are equally likely to have blinkers and blind spots. I recommend choosing a broad cross-section of stakeholders and specialists to interview and have wide-ranging conversations on the topic of failures and threats.

But don’t forget that there is one special group of people who can be particularly helpful to you at this stage: Mr. or Ms. Pessimistic. These are the people who almost instinctually see all the problems in a situation. I am one of them. They can be a drain on group energy when you are trying to innovate, but at the same time, they can sometimes protect the group from disaster!

Seek them out and listen to their fears. Take down all their worst catastrophe theories. Then, subject those ideas to a rigorous assessment.

Pre-Mortem

This is a fabulous approach to risk discovery. It was developed by Gary Klein, and he documents it in his wonderful book, The Power of Intuition. In a way, this method allows everyone to take on the role of Mr. or Ms. Pessimistic, for the duration of the exercise!

Once you have gathered and briefed your team, ask them to imagine that the go-live of your project is a disaster. Be completely non-specific and ask each of them to imagine their own kind of fiasco. Then get the different scenarios on a board. For each scenario, ask everyone to imagine reasons why this disaster may have happened. What are the causal events, failings, errors, or omissions. Again, I like to put each idea onto a card.

Then you can go through the steps of discussing and consolidating the ideas, to form a list of risks which you can build into a risk register. The genius of this idea is that it overcomes the bias we have that risks arise from errors in the plan, and starts, instead, with the outcome. This allows us to envisage left-field threats to the project, without the constraints of starting from what we know.

To Conclude

Identifying risks to your project is too important to trust to a single approach. The more tools that you have, the better your results will be. What are your favorite methods for identifying risks to your projects? Let me know in the comments below.

Next Webinar

Webinar highlights: Project for the Web Views - An Overview of Features and Functionality for Efficient Project Management

Written by Mike Clayton
Dr. Mike Clayton Mike Clayton is a Project Manager. He is founder of OnlinePMCourses.com and presenter of the successful Project Management YouTube Channel, OnlinePMCourses. Contact Mike by email: mike@onlinepmcourses.com
Share This Post
Have your say!
00
2 Comments
  1. A note on risk identification. I’ve found that Risk Identification, labeled as such, draws blank stares from the project teams I’ve managed. Not because they’re adverse to it, but because they’re unsure about it.
    However, when I ask the team to identify what they worry about on the project, I will almost always get a list of 25-100+ items. I then walk the team thru a simple exercise asking them one question on each “worry”. The question is this; “Is this under the teams control?”. For example, if they worry about not testing the interface sufficiently, I ask if that’s under their control. Phrased another way, would they feel comfortable telling Sr. management that the project had a bug because they didn’t test the interface sufficiently? In this case, the “worry” is not a risk. It’s something the team controls because they control the test plan/cases. So that “worry” gets moved into a list of items to address in the test plan.
    If it’s something they can’t control, for example requirements impacted by a change in a state law, then it is a true risk and goes in the risk list.
    Typically, after this process, I’ve found that a “worry” list consisting of 30-100+ items is typically paired down to a handful of actual risk items. And after the team understands the “we own it” concept, whittling the list down to actual risks probably takes about 30 minutes. And, as a side benefit, other parts of the project, like the test plan in my example, become strengthened.

  2. Daryl
    Thank you for your comment. I like your approach. Especially the idea of putting things the team can control straight into the work planning process.

    I have used the ‘sleep disruption’ test to estimate impacts with one team of project board members:
    – occasional restless period through to constant sleeplessness. It’s a great intuitive way to scale risks.

Leave a Reply