Some of you might think that managing risks is just one of the million boring things that exist in this world… and it is if you do not have the right mindset. Nowadays we hear a lot about Agile, but this goes above and beyond.
I won’t invest time in having you convinced that you need Risk Management in every project, it’s your call how you control (or ignore) those things that are not a problem but they might become a big problem for your team and destroy your project (being dramatic).
With the latter in mind I would recommend understanding the minimum, focus the team on the 4W’s – WHAT, WHO, WHAT and WHEN):
- What is that thing that is not a problem, but it could become a problem (A Risk)? What will happen if it is not solved? – (Risk Description)
- Who oversees the risk? Who is the owner? (Risk Owner)
- What are you or the owner doing to prevent that risk? (Risk Mitigation)
- When is this risk due? When do you expect to solve this risk? (Risk Control)
Now, some of you might think that the W’s is something easy and that you don’t need anything else to control your everyday risks in your project… well, you might, but I’m trying to take this “Risk Management” post to an exponential mindset where you need to control more than 20 to 50 risks at a time and consequently communicate this on time so the team can help to minimize the impact or go through the happy path and mitigate the Risk.
Note: Keep in mind that this approach is useful in any aspect of your life, not only working with Agile or Traditional (Waterfall) but aiming to use ONLY what you or your team find meaningful for the project.
Worst case scenario: A Risk will become an Issue, then it will become a Change. Once you conduct all necessary actions to handle the change then you can archive the entry. (Don’t get me wrong, it is ok if you have changes, is part of your job to handle them).
Disclaimer: From this point, the boring part of Risk Management (The learning part) starts, but once you learn, rest assured that your “almost a problem” (Risks) will be diminished to nothing (most of them).
Risk Management is defined as a “key project management practice” that helps you to reduce the number of surprises while your project is “in-flight”. Picture this, it is impossible for you to magically close your eyes and start to predict the future with certainty. That is why it is important to define a process to treat uncertainties, its easy (I will try to help).
The ultimate output of managing risks is to minimize the probability of occurrence of those “almost a problem” situations and to increase the chance of having an excellent project completion.
Some of the best practices:
- Keep it simple
- Define a Cycle
- Build a Layout
- Define Catalogs
Keep it simple
ISO 31000 defines three phases: risk identification, risk analysis, and risk evaluation. In my case, I have seen different Risk Lifecycles depending on the area. But in this case, we can stick to this one: Identify, Evaluate, Handle, Control, and Learn.
Build your risk file layout
Keep it simple, Once you have in your mind the cycle steps (overall) then the best way to start building something useful is to picture the kind of information you want to show in your risk dashboard (“Killer Report”). Then create your Risk File Layout. (Reverse engineering)
“Mind the gap” that in this layout is not intended for stakeholders’ sight, but to empower the desired communication of your killer report. Once you have data you can play with the different information to manage and communicate as required.
i.e: Some layout fields that I use (you don’t need them all).
- Risk Status (open or closed): Usually I managed “open” or “closed”.
- Entry (risk, issue or change): I manage my entries first (if possible) as a Risk, then if the risk was not mitigated then is an issue and if applicable the issue should become a change.
- Risk Issue or Change type (Cost, Scope, Schedule etc.): Create a catalog where you can consult the definition of every “R” “I” “C” Type.
- Date reported & Risk Due Date
- Description: Make sure you define a way of describing a Risk that looks the same for all (coherence).
- Mitigation plan & action items (Updated weekly)
- Impact (Low, Medium, High): You need define in the catalog what L, M or H means to each type of entry.
- Risk RAG Status: (Red, Amber or Green – where each color indicates how close the risk is to become an issue) Also a Catalog.
- Risk Owner: Make sure you identify the right person who has to help you to execute the mitigation plan.
- Impact (Qualitative or Quantitative)
And among others like comments, impact in days, budget impact, resource impact… etc. To mention a few that had worked for me.
To mention a phew catalogs that I manage on a daily basis:
- Risk Type:
– Financial: Situations that may or may not impact the project budget.
– Schedule: Situations that if they happen to become an issue it would impact schedule.
– Technology related: Situations where technical inputs threaten project progress (licenses, machines, servers, etc.)
– People/Team Related: Situations where the lack of time that people can dedicate to the project threaten project progress (Vendors, Stakeholders, Upper Management, etc.)
Among other Catalogs based on what you need to track: Scope, Probability, Impact, Status, etc.
A very efficient way to identify risks is to create a set of parameters. Those parameters will help you to associate risks with a relevant area within the project. The objective of having these different catalogs is for you to understand how to classify risks/issues or changes in a seamless way.
As mentioned in some of the recommended fields, people find catalogs as a proper way to keep a flat understanding of what you are trying to communicate. For every risk you need a risk description, in this case, the catalogs empower the risk description and help the audience to have less text to read, therefore it will be easier to understand.
Measure your risks (Risk Exposure)
This is for reference only; please keep in mind that like everything else in the world we need to know what’s important and what’s urgent (Different but complementary) so you can easily bring up the attention to what really matters.
There are two ways to measure your risk:
- Qualitative: High, Medium, Low.
- Quantitative: you can use probability.
One of the best practices is to multiply the Impact Rating with Risk Probability. This is useful with Stakeholders that take actions based on numbers, please consult the following reference for more information:
Find reference on how to deeply assess Risks: Risk Impact Assessment and Prioritization.
Analytics: Collect and Think
After a while recollecting data, we can build up a knowledge base of risks and identify those areas that are causing our team struggles. And in the aftermath get lessons learned so we can take corrective actions if required.
These are basically the things that you need to know to control your project risks after this is up to you how you use them as best fit in your project/life. From here, everybody that oversees project processes based on any framework (Scrum, PMI, Prince, Kanban, etc.) can take action on anyway this tool might fit in.
Keep in mind that these are just best practices where the final objective is to empower your management skills to take care of those things that “are not a problem now, but they might become a major issue”.
Risk Management is not only for you, is for your team, stakeholders, vendors, client, and all parties involved. So, please think exponentially and communicate accordingly.
About the author
Graduated from Industrial Engineering from Universidad Francisco Gavidia. Oscar has over 10 years of experience in Project Management. He’s currently a Project Manager at Applaudo Studios.