How to perform risk identification? How to discover problems that you are unaware of? Check the topic on PMBOK® Guide. I believe, it says nothing about the practical application of risk identification processes. Though the techniques are simple.
Though the techniques are simple. In this article, I will tell you what techniques you will be able to use today. And you won’t need any special training.
However, real problems always appeared from sources I never expected.
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 is not practical to go through all the questions at once. They are interrelated and impact each other. It will take much time to analyze all the documentation at the end of the project planning.
Therefore, I suggest you do it step by step. Each milestone in your planning effort should be accompanied by a small session of risk identification.
So, what can you apply?
1: Risk Categories
Project managers should collect lessons learned after each project. You do know that, don’t you?
However, it is rarely the case. That is why, most likely, you do not have a list of risk categories available.
Risk Categories are just a list of common risks in your organization. It is a part of lessons learned from risk management.
The idea is 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.
2: Requirements Review
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 is 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.
Moreover, it is important to have a big picture of the product. It should be in sync for the whole team.
3: Project Plan Review
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 is planning an important trip he has not told you about yet.
It is 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: Brainstorming
There are critical points in project planning when I extensively use brainstorming for risk identification. Here is the list:
- Analyzing critical requirements.
- Reviewing Work Breakdown Structure.
- Reviewing schedule and human resources plan.
- Creating 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 do not have a clear understanding how to deliver something – it is a risk.
The key point is to gather ideas from different perspectives.
5: Root Cause Analysis
In practice, I use root cause analysis for risk identification in three cases:
- Analyze serious problems of the past projects. It might be my previous project, a similar one in the organization, or 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 main sources of problems and identify even more risks.
6: Assumptions Analysis
By nature, assumptions involve risks. If an assumption is wrong – a project is in trouble.
Review and validate assumption regularly. We make assumptions all the time. Some of them may have a severe impact on the project.
In most cases, it is worth to write them down right into the project management plan.
All risk identification techniques try to answer one question. What can go wrong? That is the question you must think about constantly.
If you liked the article, consider joining PM Basics for free. You will get access to my Project Management Library. Check the form below.
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.