Effective Methods of Risk Identification
By Carl M. Manello
“There are risks and costs to a program of action. But they are far less than the long-range risks and costs of comfortable inaction.” –President John Fitzgerald Kennedy
There are risks everywhere, whether they are called out and addressed or whether they are ignored. It is our job as consultants to make sure that we are mitigating risks, in Kennedy’s words, through action. We have found that the most critical and most difficult action in Risk Management is the cataloguing of risks. The challenge is to find effective ways to elicit risks from stakeholders. After all, you can’t manage risks if you don’t know what they are. And while it may seem that the identification of risk should be the easiest part of the process, we find that stakeholders and project teams do not always understand the concept of “risk.” Sure, now you are thinking, “what are some effective ways of identifying risks?” There are many methods for Risk Identification; here are some of the most effective.
- Reviewing documentation from past projects
- Conducting brainstorming sessions
- Engaging subject matter experts
- Working directly with stakeholders via questionnaire or survey
- Facilitating a “Why This Won’t Work” meeting
Risk Identification Methods
- While the Project Management Institute tells that documentation from past projects is like “gold” to the project manager, it is really more like the Holy Grail. Reviewing documentation from past projects can be an effective way of uncovering risks, especially if you can get ahold of a risk register from a similar project. However, the challenge with this method is that few companies store documents in a way that is easily accessible. Even when they do, the risk register is not typically one of the required deliverables and therefore isn’t always kept with the project documents. If you are able to find a risk register from a similar, past project, latch on to it. It can provide a lot of insight into what risks you might encounter.
Brainstorming is a much better way to identify risks. As you begin to understand who all the stakeholders are, you can determine who the key stakeholders for your initiative are. Who are the important stakeholders (i.e., who are the ones that should be listened to most and who know the most)? Who are the most vocal leaders (either as proponents or adversaries)? Prior to the meeting, set the expectations for these stakeholders and get these individuals on your side by explaining to them how you will run the meeting, the types of questions you will ask, and what you want to get out of the meeting.
Getting these individuals on your side will ensure that the meeting runs smoothly and that you identify as many risks as possible. During the meeting, use any tool to capture and document the risks as they are mentioned. Invite each of the people in the meeting to mention as many risks as they can think of. Prime the pump with a list of risk categories to get people thinking (e.g., resources, technology, schedule) and put these categories on the tool you are using to catalogue the risks. Have attendees state their risks in the format, “If X happens, then Y will result.” Encouraging the attendees to provide risks in this format forces them to think about the impact of the risk and causes them to self-edit when the risk they are providing really isn’t a risk. Gather as many risks as possible to use later in risk analysis and planning.
Talking to subject matter experts (SMEs) can enable you to identify risks. On a recent project to migrate a client’s email system to the cloud, two SME’s were identified. Both had been on this type of project before. Working with these SME’s enable the project to identify the risks that might be encountered. The SME’s were also tapped to help explain how they had managed those risks in the past. SMEs don’t necessarily need to be directly from your project team or from your organization. If you are implementing third party software, you can ask the vendor to put you in contact with resources who have implemented the software in the past. These individuals can be valuable sources for risk identification.
If you cannot get all of the stakeholders together in a meeting, you can try a questionnaire or survey to leverage those stakeholders. The object of this questionnaire is to collect as many risks as possible from the stakeholders. The survey form can simply be blank with fields for the stakeholders to complete such as category, description, and impact. Or seed the form with categories so that you get the stakeholders thinking about risks. You can pre-populate categories like technology (is it a new technology?), support from vendor, and resources.
A final method to identify risks is to hold a “Why This Won’t Work” meeting. The goal of this meeting is to have stakeholders voice their doubts about the project. These doubts often lead to risks. When you hold this meeting, invite as many stakeholders as possible. Provide them with post-it notes and ask them to write their reasons for why the project won’t be successful on the post-it notes. Gather the notes and go through them with the group, capturing all the necessary fields for your risk register as you go.
In her book Risk Management: Tricks of the Trade, Rita Mulcahy suggests combining several of these methods to ensure you identify as many risks as possible. That’s a great idea if your timeline can handle it. If not, start slowly with a brainstorming session and as you gain momentum and others see the value in what you are doing, try to layer on additional risk planning techniques. This will ensure that you identify as many risks as possible and will ensure that your project runs smoothly. Whichever approach you choose, remember the essence of risk planning is to get the risks out into the open where you can manage them. To paraphrase President Kennedy, do not ask what risk management can do for you, but what you can do to prepare for risks.
Carl Manello is a Solution Lead for Slalom‘s Program & Project Management practice based in Chicago who enjoys exploring how to tightly couple the art and science of project delivery with business operations. You can read from Carl on his blog.