Risk Identification (What is it, techniques and examples)

Here’s the most important thing you need to take from this article.

Risk identification is not a rigid process that you follow step-by-step. Instead, good risk identification comes from communication and collaboration with all project stakeholders.

Moreover, you need to educate others on how to use your risk management process. 

Let me explain how it works in the real world with real people.

What is Risk Identification?

Risk identification is an effort to discover threats and opportunities that may impact a project, its feasibility, or its management plan by applying risk identification techniques. 

As a result, you need to capture all identified risks into a Risk Register. 

Note that risk identification is the first step in the process. You will continue analyzing risks in the next steps of your risk management process.

When Do You Perform Risk Identification?

In practice, you should use an integrated risk management approach. This means that you should talk through possible risks for each and every activity during the project. 

For example, when you collect requirements and write specifications, you and your team should always be on the lookout for risks:

• Track all the assumptions you make.
• Check if the requirements are ambiguous, i.e., do people understand the exact same requirements differently?
• Don’t hide uncertainties. Instead, transform them into risks.

But that’s not enough. You also need in-depth risk identification sessions at specific critical points in project planning where you take a broader look at the project as a whole.

For example, here are some important moments at which to consider the need for dedicated risk identification sessions:

• When clients identified the project goal.
• After you’ve identified key stakeholders.
• When you’ve reviewed risk categories for the first time.
• After you’ve collected most of the requirements.
• After you’ve created a draft of the work breakdown structure (WBS).
• After you’ve identified the required resources.
• After you’ve drafted the project schedule.
• After you’ve drafted the project budget.

How to Identify a Risk?

Risk identification technique is an approach to discovering threats you were unaware of by collaborating with project stakeholders. 

We use just a handful of risk identification techniques in practice. The most popular risk identification techniques are:

1. Talking about risks (not a real technique, but I’ll explain it below).
2. Checklists (risk categories).
3. Document analysis.
4. Root cause analysis.
5. Assumptions analysis.
6. Brainstorming.
7. Interviews.

Now, you need to understand when to use them and how to apply them to your project management documentation. 

You’ll capture all identified risks into the Risk Register.

How to Use Risk Identification Techniques

Some techniques, like brainstorming, are universal. You can apply them to anything on a project. 

Other techniques, like requirements analysis, are specific to a piece of project documentation, and you do it once. 

You don’t always use all the techniques on everything. However, you might apply several techniques to one input. For example:

You can review the project schedule with the team (#1) and brainstorm (#2) possible threats. After that, you’ll check common risk sources in the risk categories (#3). Then, you’ll take the schedule to a senior project manager and interview (#4) her to get her insights.

Notice how we used four different techniques on the same piece of project documentation. Of course, not all artifacts require so much attention. However, for example, I recommend putting more effort into the project budget and schedule.

Overall, it all boils down to efficiently using your time and resources. Keep in mind that risk management is not free of charge. You use time and resources from your project.

Now, let me give you some real-life examples.

Risk Identification Examples

In real life, it’s tough to make risk identification techniques timely and efficient. The key is to keep things simple. Team members and stakeholders should be able to use them without special training or experience. 

That’s why I’ve selected these seven techniques you can use on any project, no matter how experienced you are.

#1: Continuously Discuss Possible Risks

In the real world, we continuously identify risks. It’s the most effective approach. 

But it’s not a casual conversation. It has specific rules and agreements. That’s why you need to educate all team members and stakeholders in your risk management process. 

In essence, you need to ensure that everyone has the same understanding of the following:

1. Importance of risk management.
2. Responsibility of each person in risk management.
3. What is a risk, and what is a fact?
4. How do we capture risks in the risk register?
5. How do we handle risks in general?

It will ensure that you use the same terminology and mean the same thing when talking about project risks.

Therefore, when you have a shared vision of risk management, you can incorporate risk identification into every project activity. For example, you can ask something along the lines of:

• Do you see any risks here?
• How risky is this approach? 
• Please provide a list of risks along with estimates.
• Let’s think about possible risks.
• What may go wrong with this plan?

So, all other techniques below will have sporadic or one-time appearances. However, talking about risks happens daily. 

#2: Analyze Risk Categories to Discover Typical Risks

Most organizations carry out projects of a similar nature. Processes and policies are the same. Some stakeholders never change. So, a new project inherits all the same sources of risks from your environment. 

Risk categories are just a list of these common sources of risks in your organization.

In practice, that means all organizations in the same niche share the same sources of risks. So, this technique is really worth your time because you can reuse it throughout your whole career.

The list of risk categories comes from lessons learned in risk management. Ideally, project managers should share these lessons with others. However, that is rarely the case. 

That’s why you won’t find such a list in your organization. What’s even worse, for the same reasons, you probably don’t even have your own list of risk categories right now. But I’ve got you covered. You can use my list of categories.

So, risk categories technique:

• helps you to identify risks that you may not be aware of; 
• prevents you from forgetting about some risk sources; and 
• structures your risk identification efforts.

The process is simple – you need to get through the list to identify risks that may apply to your current project. You can approach this in different ways.

You may review the list alone and shortlist the categories, then discuss the shortlist with your team. Or, you can brainstorm through the whole list with your team. Usually, the best time to do this is when you already know the project’s scope of work. 

I also recommend keeping the list close at hand as a cheat sheet or template for other risk identification sessions. It will be a good starting point for identifying new possible sources of risks.

#3: Perform Requirements Review

A requirements review is just one part of assessing the project documentation, but I want to focus on it separately because it’s critical.

Requirements contain significant risks for a project. Therefore, you need to analyze them to find any ambiguous or unclear aspects. This review will help you assess how much work is required to fulfill each requirement. 

Poor requirements are the number one cause of project failure. However, it’s not just their quality and level of detail: It’s also important to have enough time to analyze the project specifications. 

You need to have a chance to review and discuss each requirement with the team with the big picture in mind. You need to ensure that the requirements don’t conflict with one another. Not giving yourself the time to do all of this is a risk in itself!

In the real world, you clarify requirements throughout the whole project’s lifetime. Therefore, you need to re-evaluate the risks progressively here. So, here’s what you need to do in practice:

1. Select some requirements.
2. Select a group for analysis (the whole team or just group leaders).
3. Let them read through the specifications, designs, and emails.
4. Plan a meeting to analyze the requirements.
5. Let one person explain the requirements to the others.
6. Clarify requirements to the point where everyone has the same understanding.

If you have never done this before, try it at least once, even if just out of curiosity. You’ll notice that different people read the same words and sentences differently.

Likewise, I’m a big fan of visualizing workflows, information flows, and user experience. 

If your product, service, or result has a user interface or any tangible form, take time to draw it out. You will identify a lot of new use cases, weak spots in requirements, and inconsistencies. As the old saying goes, a picture is worth a thousand words.

#4: Review the Project Management Plan with the Team

This is the more general part of reviewing project documentation that can be applied to any assessment of risks. 

So, what documents should you review to find risks? The answer is every single one! For example, once you have a first draft of the project management plan, review it with your team.

First of all, engaging the project team in the planning activities is vital. So, you need to ensure their buy-in from the start. A disengaged and unmotivated team that doesn’t believe in the project plan is a huge risk by itself. 

On the other hand, your team is the primary source of information and risks. When you walk the whole team through the project plan, I can promise that each person will find at least one risk related to them. It’s better to find out such risks early and adjust the plan accordingly.

There are many aspects that you need to talk about with the team. At the very least, you need to discuss the following:

• Units of measurement. Did they provide estimates in effective or ideal hours, working days, etc.? 
• What did they include in those estimates? Is there a buffer?
• Do they know how to report the money they spend?
• Do they know how to log their progress and when?
• Do they know your project management approach in general? What about risk management? 
• Do they understand the definition of a completed task?

The list goes on and on. Never assume that team members see and understand your plan the same way as you do. Moreover, don’t assume that all team members have a common understanding of all project activities.

Once I have a draft of a schedule, I show it to the team. They review dependencies, the flow of tasks, and any buffers that we have. They also think through their personal plans, vacations, and other errands. 

For example, a team member sees the project schedule. He has several critical tasks next week. Then, suddenly, he remembers that he’s planning an important trip he has not told you about yet. You can then adjust the schedule to allow for his absence.

Moreover, different parts of your project always depend on others, and you want to make sure that nothing blocks your progress. So, team members may discover hard dependencies that I’ve missed. Therefore, it helps me to correct the plan early on and include these possible delays.

I use the same process to verify our Work Breakdown Structure (WBS). Draft after draft, I collect feedback from the team and correct the WBS. This often reveals insufficient details in requirements. Therefore, we need to take a step back. Occasionally, we discover a new piece of work when we look at the product as a whole.

I also recommend creating and reviewing project workflows. At the very least, you need them for the following:

• starting, reporting on, and finishing a task;
• identifying and controlling risks;
• reporting on project status;
• identifying and fixing defects;
• integrating a change request; and
• elaborating requirements from concept to an approved specification.b

You can draw the workflows on a piece of paper or create them in a tool like diagrams.net. But I believe you do need to visualize them. If you use project management software, you need to tie it all to “statuses” and “fields.” You don’t need any flashy diagrams here: Just make it clear to team members.

The good thing is that you’ll only need to do this once for each organization. Then, you can adjust it for new projects. But it will help you identify roadblocks, areas of diffused responsibility, inefficient communication, etc. 

Another source of risks is your superiors, who need to approve your work. All these show up on a diagram of project workflows.

Q: Dmytro, do you really review all the documents on your projects?

A: No, I don’t. This is because some of them are pretty similar to the ones I used on previous projects. So, I just make sure that the same plans, templates, and workflows will work for the new project.

#5: Use Brainstorming and Interviews Techniques for Deeper Analysis

In general, I don’t like to identify risks with wild brainstorming. However, there are critical points in project planning when I use brainstorming for risk identification on a higher level. These are:

• when analyzing essential requirements;
• while reviewing the WBS;
• when reviewing the schedule and HR plan;
• while creating a quality management plan; and
• before finalizing the whole project management plan.

So, for example, once I have a draft of the WBS, I plan several brainstorming sessions. Then, I analyze major deliverables one by one with the team. My main question is, “What could go wrong when we implement this piece of the project?” And I point at one of the deliverables. 

Then, I ask, “What challenges do you see in putting it all together in one piece?” So, we take a broader look at our future work once we know enough details.

I use interviews with Subject Matter Experts (SMEs) in the same manner. Unfortunately, these experts usually don’t have time to participate in all risk management activities. So, instead, I try to get feedback and validation on the most critical risks and related response plans.

#6: Apply Root Cause Analysis for Systematic Risks

In practice, I use root cause analysis for risk identification in three scenarios:

1. To analyze severe problems of past projects. It might be my previous project. It might be a similar one in the organization carried out by another project manager. It can also be relevant notes from lessons learned or a list of risk categories.
2. When I’m trying to solve a systematic problem. This usually relates to inefficient communications, poor quality, inaccurate estimates, or ambiguity in requirements.
3. To group all identified risks by the root cause. It helps to see the primary sources of problems and identify even more risks.

So, in a real-world project, you don’t carry out root cause analysis during planning. Usually, it’s a post-mortem or analysis after a significant problem. 

So, first, you collect lessons learned. Then, you allocate time at the end of the project for a root cause analysis session. You can use the fishbone diagram, the “5 Whys” technique, or a scatter plot diagram. Later, develop a systematic risk response plan for the next project. 

Don’t assume that the same risks will not occur in the next project. On the contrary, they undoubtedly will – especially those related to your project management approach and your organization’s environment.

Always put such risks on your risk categories list.

#7: Analyze Assumptions to Identify the Most Impactful Risks

By nature, assumptions involve risks. If an assumption is wrong, a project is in trouble. 

So, first of all, you need to keep track of all major assumptions. I keep a separate list of project-level assumptions. In addition, I log all assumptions related to specific requirements right in the specification document. After that, you need to review and validate the assumptions regularly. 

We make assumptions all the time. But most are made right at the start of a project. So, they may impact the project later down the road. Assumptions that you make due to problems in the organization are the most risky. These include the following:

• An assumption that you’ll get the required resources in time. Why?! Do recruiters always hire people quickly?
• An assumption that your SME will be available for your project. But what if he’s assigned full-time to another critical project?
• An assumption that a third party will provide their deliverables on time. Usually, they don’t, and the whole project stalls.

You need to work hard to validate an assumption and either make it a fact or transform it into a known risk.

How to Find Time for These Activities?

First of all, efficient delegation is the key. You don’t need the whole team for risk identification. 

Second, you can incorporate these techniques into other processes and meetings. There’s no need for separate meetings unless you want to explore possible risks in depth.  

Third, when you educate people about risk management techniques, they start using them on the fly: they include risks and assumptions in all their conversations. 

On the other hand, you need to explain the benefits of risk management to the project owners. You need to strike the right balance between your efforts and the potential benefits they provide, and ensure that you ask for enough time to achieve those benefits.

Conclusion

Unfortunately, this article was just one piece of a complex project risk management framework: Many other processes happen before and after this one.

If one part doesn’t work, the whole system breaks.

My Risk Management Plan Template connects all processes and tools into one cohesive system. It also provides access to other articles and videos on risk management. 

Don’t put your projects and reputation at risk. Ensure you know how risk management works in the real world.

All successful project managers know it’s better to learn from someone else’s experience (aka lessons learned). Tap into my 12 years of practical IT experience and get the Risk Management Plan Template.