“How do you actually identify risks?” Corwin asked me after a lecture.
I was surprised and couldn’t get the question, “I have just explained tools and techniques I use to identify risks, haven’t I?”
“Yeah! Documentation Reviews, brainstorming, diagramming and designs. But how do you do that?”
It is interesting because I get this kind of questions from time to time:
How to identify risks in project management?
I usually describe some of the critical tools and techniques. Just like in this article:
Project managers cannot understand that risk identification processes are simple by design. But they are difficult to master to make them efficient and timely.
However, I don’t use something special.
So, I want to take time today to explain how to identify risks on practice.
What documents should you review to find risks?
The answer is every document you have on a project.
Do I really review all the documents on my projects?
No, I don’t.
Some of them are quite similar to the ones I used on several previous projects. So, I just make sure that the same plans, templates, and workflows will work for the current situation.
So, where should you focus?
Be that a specification or a User Story you need to review it from all possible aspects.
Here is how it usually works:
We get a high-level draft of requirements from a customer (product owner, product team). Me or business analyst explains it to the project team.
It is up to you to decide whether you need the whole team or not. However, I do recommend to have at least one person from every function or department.
On a high level, we write out our concerns, questions, and assumptions. And send them back to the customer.
It saves us some time and efforts. We show the areas we want them to focus on. Usually, we already have a rough opinion whether this piece of requirements will need our attention.
Next time requirements are already drafted out with many details. All our initial questions and concerns are answered.
I ask the team to read and think through requirements. They need to understand and discuss them with colleagues.
Then, we have a grooming session.
One of us explains a requirement to the rest of the team. The goal is to ensure we are all on the same side. We need a shared vision of what we need to deliver.
Usually, by this time there are quite a lot of questions. Someone understood it in another way. Someone pointed out some dependency with other requirements. Or possible difficulties to implement, test or design it.
In any case, in the end, I ask several additional questions:
- What is the possible impact?
- How complex is this requirement? What do you think?
- Who is the best candidate to implement the requirement?
- How will we test this?
- Are there any risks here? (Team should be educated in risk management)
So, I pack all the feedback into questions, assumptions, and concerns. Then, I send it back to customers for clarifications.
If our concerns are solved – excellent. If not, we log them as risks.
Use the same process for scope, schedule, and estimates.
I use the same process to verify our Work Breakdown Structure. Draft after draft I collect feedback from the team and correct the WBS.
Sometimes it shows poor requirements definition. Therefore, we need to get a step back.
Once I have a draft of schedule, I show it to the team.
They review dependencies, critical path, float that we have. They also think through their personal plans, vacations, and other errands. It helps me to correct the plan early on and includes these possible delays.
I have explained how I deal with estimates in this article:
How do I use brainstorming and interviews?
I’m not a big fan of separate meetings to identify risks.
Usually, risk identification is tied to other activities.
Therefore, brainstorming and interviews are usually about scope, estimates, the technical aspects of implementation, resource allocation, etc. Risk identification runs a red thin lined through all of them.
I use interviews to get feedback and validation from someone outside of the project team. Most of the time it is either my management I depend on or subject matter experts.
As for brainstorming, I apply it to find solutions on critical and quite specific problems. Nevertheless, you may use it to brainstorm possible risks for the project in general or some of its part.
How to Identify Risks with Visualisation
I’m a big fan of visualizing workflows, information flows, and user experience.
Moreover, it is a great risk identification technique.
If your product, service or result has a user interface or any tangible form take your time to draw it.
You will identify a lot of new use cases, weak spots in requirements, and inconsistencies.
I know that Network Diagrams are not the most popular tool nowadays. Nevertheless, it is a crucial source of schedule-related risks.
Different part of your project depend on each other, and you want to make sure nothing blocks your progress.
Do you know how different tasks and information circulate on your project?
It is a valuable exercise to do.
You will identify roadblocks, areas of diffused responsibility, inefficient communication, etc.
Another source of risks is your superiors who need to approve parts of your work.
It all shows up on a diagram of project workflows.
I should say that it is not a trivial task to do. It will require serious efforts.
Conclusion or How do I Find Time for all of These?
First of all, it is your responsibility to explain value and benefits of all these processes, tools and techniques.
Moreover, you need to get engagement from stakeholders. They have to participate from time to time. You need their help.
So, do think through the benefits these techniques provide to the different stakeholders. Also, keep in mind that the ones we discussed today help to identify and proactively prevent risks. It is something that saves time during the whole project lifetime.