How to perform risk identification?
What risk identification techniques to use?
Which ones are efficient?
And in general:
How to discover problems that you’re unaware of?
Check the topic on PMBOK® Guide:
It says nothing about the practical application of risk identification processes.
In this article, I’ll tell you what techniques you can use today. And you won’t need any specialized training.
Test Yourself in Risk Management
Do you think you know enough about Project Risk Management?
Take this short quiz and identify gaps in your knowledge.
In the end, I provide correct answers and explanations.
Project Risk Management Overview
But first, let’s be clear about one thing. Risk Identification Methods vs. Risk Identification Techniques.
Risk Identification Methods
“A Risk Identification Method is a settled workflow or a procedure that you use to discover risks. It includes the list of techniques that you use.”
There’re three Risk Identification Methods you can use on a practical level:
1. Integrated Risk Management
In this method, you try to identify risks as a part of each process.
For example, you Collect Requirements and write specifications. During this process, you and your team should always be on the lookout.
They need to track all the assumptions they make. They need to check if there’s ambiguity in requirements. If there are unclear aspects of functionality?
While you keep the Risk Register always at hand and log all the risks.
Keep in mind that you do need to log them all! You will shortlist them later in the process. Check out the article on Qualitative Risk Analysis to learn more:
How to Perform Qualitative Risk Analysis for the First Time
2. Event Risk Management
In this method, you have risk identification checkpoints.
For example, you created a Work Breakdown Structure or a draft of the project schedule.
At this point, you plan a dedicated event to analyze the project artifact.
You and your team brainstorm all possible risks in this area.
Again you log everything you identified.
Hybrid Risk Identification Method
In real life, you’ll use the best of two Risk Identification Methods.
You’ll try to identify and log risks on the go.
Still, you will have in-depth risk identification sessions. You need to select certain critical points in project planning.
Here are some important spots to consider:
- When clients identified the project goal
- After you collected a major part of requirements
- After you created a WBS
- After you identified the required resources
- After you created a draft of Project Schedule
- After you created a draft of Project Budget
- After you identified key stakeholders
Here’s what’s important!
When I was a junior project manager, I focused on apparent risks.
It was the poor accuracy of estimates, unexpected problems with team members, or unclear requirements.
But, real problems always appeared from sources I never expected.
So, to select appropriate risk identification techniques, you need to understand the inputs as well.
Risk Identification Inputs
PMBOK® Guide lists 13 inputs to “Identify Risks” process. In fact, you can narrow down the list to six practical questions:
- Does your project management plan look consistent?
- Do you have a clear scope of the project?
- Do you have appropriate resources?
- Are your estimates accurate?
- Do you know how to engage key stakeholders?
- Does your organization environment have problems?
On the other hand, it’s not practical to go through all the questions at once. They’re interrelated and impact each other.
It’ll take much time to analyze all the documentation at the end of the project planning.
Therefore, I suggest you use a hybrid identification method.
Each milestone in your planning effort should be accompanied by a small session of risk identification.
So, what techniques can you apply?
1: Analyse Risk Categories to Discover Typical Risks
(Usually, you use this technique once)
Project managers should collect lessons learned after each project.
You do know that, don’t you?
However, it is rarely the case.
That’s why, most likely, you don’t have a list of risk categories available.
“Risk Categories are just a list of common risks in your organization. It’s a part of lessons learned from risk management.”
The idea’s simple:
You need to analyze the list to see risks that may apply to your current project. This approach helps you to identify risks that you may not be aware of.
In general, an organization does projects similar in nature. Processes and policies are the same. Part of stakeholders never changes.
Therefore, a list of common risks is a quick way of risk identification. Here is a starting point for you:
43 Important Risk Categories for Effective Risk Identification
You can approach it in different ways:
You may either review the list alone and shortlist the categories. Then, you discuss the categories with the team.
Or you can brainstorm through the whole list with the team at once.
2: Requirements Review as Risk Identification Technique
(You should use this technique in a hybrid mode)
Requirements contain significant risks.
You need to analyze them to find ambiguity and unclear aspects. Nowadays, you clarify requirements throughout the whole project lifetime. Therefore, you need to reevaluate the risks progressively.
Poor requirements are the number one cause of project failure.
Not only the quality and the level of details of requirements matter.
It’s also important to consider the amount of time available to analyze the documentation. You need to have a chance to review and discuss requirements with the team.
Lack of time to do that is a risk.
Moreover, it is essential to have a big picture of the product. It should be in sync for the whole team.
Here’s the trick:
You need to allocate time for requirements analysis.
When you have a small team, you can try the following approach.
- Specify a piece of requirements.
- Select a group for analysis (the whole team or just group leaders).
- Let them read through the specifications, designs, emails.
- Plan a meeting to analyze requirements.
- Let one of them explain requirements to the others.
- Clarify requirements to the point where everyone has the same understanding.
Try it at least once out of curiosity.
You’ll notice that different people read the same specification differently.
3: Review Project Plan With Team
(Usually, you use this technique once. Additionally, you apply it when significant changes to the plan happen.)
Once you have a first draft of the project management plan, review it with your team.
The benefits of engaging the project team into the planning activities are vital. The disengaged and unmotivated team is the huge risk by itself. So you need to ensure their buy-in from the start.
On the other hand, your team is the primary source of information.
And risks.
Why?
For example, a team member sees the schedule. His tasks are on the Critical Path.
Suddenly, he remembers that he’s planning an important trip he has not told you about yet.
It’s better to find out such risks early.
There are many aspects that you need to talk about with the team:
Units of measurement and reporting, roles, and responsibilities, major processes, and procedures…
Just never assume that they see your plan the same way as you do.
4: Use Brainstorming Technique to Make Deeper Analysis
(You should use this technique in a hybrid mode)
There are critical points in project planning when I use brainstorming for risk identification. Here is the list:
- During analyzing essential requirements.
- While reviewing Work Breakdown Structure.
- Reviewing schedule and human resources plan.
- While creating a Quality Management Plan.
- Before finalizing the whole Project Management Plan.
So, for example:
Once I have a draft of work breakdown structure, I plan brainstorming sessions. We analyze major deliverables first. Usually, risk identification is a part of scope definition for us.
In case we don’t have a clear understanding of how to deliver something – it’s a risk.
The critical point is to gather ideas from different perspectives.
5: Apply Root Cause Analysis For Systematic Risks
(You should use this technique for specific cases)
In practice, I use root cause analysis for risk identification in three cases:
- Analyze severe problems of past projects. It might be my previous project. It might be a similar one in the organization done by another PM. It can also be relevant notes from lessons learned.
- When I try to solve systematic problems. It usually relates to poor communications, inaccurate estimates, or ambiguity in requirements.
- To group all identified risks by the root cause. It helps to see the primary sources of problems and identify even more risks.
In real-world projects, you don’t do it during planning.
Usually, it’s a post-mortem analysis. You collect lessons learned. Then, at some point, you need to act upon them.
So, allocate time at the end of the project to have such root cause analysis sessions. Develop a risk response plan for the next project.
Don’t assume that the same risks will not happen in the next project.
They surely will.
Especially those related to your project management approach and a company’s organization.
6: Make Assumptions Analysis to Identify the Most Impactful Risks
(You should use this technique in a hybrid mode)
By nature, assumptions involve risks. If an assumption is wrong – a project’s in trouble.
Review and validate assumptions regularly. We make assumptions all the time. Some of them may have a severe impact on the project.
In most cases, it’s worth to write them down right into the project management plan.
In it’s simplest form, you can create a simple list. Just name all the assumptions that you make. Review the list regularly.
Here’s the truth:
Assumptions that you make due to the problems in the organization are the most severe ones.
An assumption that you’ll get the required resources in time. Why! Recruiters always get the people fast.
An assumption that your subject matter expert will be available for your project. But the next day he’s assigned full time to a critical project.
And so on…
Conclusion
All risk identification techniques try to answer one question:
What can go wrong?
That is the question you must think about constantly.
You may not need any specific techniques or tools for that.
Just a habit.
Also, I recommend to read:
- Next in the series: 43 Important Risk Categories for Effective Risk Identification
- Previous in the series: Simple Project Risk Management Plan that Works
- Overview of Risk Management: Full Guide to Risk Management Process in Project Management
- PDF: Complete Guide to the Basics of Project Risk Management
Great list! Root Cause Analysis is a tool I’m using more and more in the last few years. I find that going through the exercise with the team generates great discussion and leads to interesting findings. I love also that you mention utilizing lessons learned from past projects. Much of the time, that knowledge is ignored and it’s value is lost.
Excellent article.