“Almost a problem” Management: From risk to change

Oscar Castillo Chedraui
By Oscar Castillo Chedraui

Learn key Risk Management best practices for your projects.

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):

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:

  1. Keep it simple
  2. Define a Cycle
  3. Build a Layout
  4. Define Catalogs
  5. Report

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).

And among others like comments, impact in days, budget impact, resource impact… etc.  To mention a few that had worked for me.

Define catalogs

To mention a phew catalogs that I manage on a daily basis:

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:

  1. Qualitative: High, Medium, Low.
  2. 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

Oscar Castillo Chedraui

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.