This is a guest blog post from Giuliano Abraini…
Hi everyone, you all know the popular saying: “a project manager not managing risks is under big risks…”. No? Well it’s mine anyway! But still it does make a lot of sense right?
Anyway, you folks are experienced project managers so you do know how important is to carefully manage all the risks during your project’s cycle. If not, some bad surprises could eventually occur and lead your project to a dead-end way.
But you’re probably thinking “yes, but “risk management” implies endless meetings, unreadable reports, no decision making,…”. In a word, it’s usually a large process for no result.
And this is when I come to my point: it is possible to manage risks without all the above constraints thanks to Agile … true story! And when you see the light at the end of the tunnel, you just realize that Agile is AWESOME (“High five” would say my friend Barney Stinson).
First of all, you need to use your Scrum Master survival kit. I.E. a large paper board, some post-its, color pens.
To start with, you have to draw a 2 dimensions table. A first one, identifying the probability that a risk occurs (scale from 1 to 4). And a second one, assessing the impact on the project when a risk occurs (from 1 to 4). Like this, a risk with a high probability to occur and with big impacts will get a quote of “probability = 4” and “impact = 4”.(1)
In our table, we have also identified (in pink) a “zone” where risks should be monitored more carefully. (2)
Then, you need to split “the thing” in 3 phases:
– Identify risks
– Put them in categories
– Take actions to reduce / delete / avoid the risks
The first step consists in identifying all risks (and I really mean all) linked to your project and to put them in the table previously prepared. Here we just use 1 yellow post-it for each risk and we simply write down the risk description. Please note on the photo, that we also use blue post-its. These are used to identify risks for which no actions can be taken (3). For example, if you have only one analyst programmer in your team, the fact that this person can be sick a not be able to take part to the project for a few days is an identified risk. But you cannot do anything to reduce this to happen even if you buy a brand new scarf to your analyst programmer.
For the second step, you need to classify all the identified risks in your “risk” table according to the probability and the impact. (4)
The third step consists in identifying all the actions that could be taken for each risk and to write them down on green post-its. Then, you will also classify each action according to the following categories (5):
– Mitigate: these are actions that will reduce the impact if the risk happens
– Avoid : here you will put actions that makes the risk not to occur
– Contain: there are actions that will lower the probability that a risk occurs
– Transfer : here you will transfer the risk to other departments or stakeholders that have the needed tools to positively influence the probability or the impact of the identified risk.
Last but not least, you now have to set-up regular reviews. The best is to organize “reviews” in the same mindset as daily scrum meetings where people discuss about the taken actions and the consequent results.
After each review, it is important to re-assess the risks, identify new ones and finally schedule new actions.
That’s all folks. Enjoy!!!
I am consultant – Project Manager for 3 years now and I have 8 years of experience in IT. I am specialized in SCRUM and PRINCE 2 (Foundation certified).
I have a master in Economy & Finance and I went into the IT world by chance. Since then I am still active in IT. I had experiences as Analyst, Product or Project manager in various activity sectors such as banking, finance, public sector.
As project manager I am focused on satisfying the project sponsor. I also want to make sure that all team members enjoy taking part to the project.
Outside the IT world, I like travels and all kind of sports.
You can contact me at email@example.com
This content is published under the Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported license.