La gestion des risques en mode Agile

[English version below: « Risks management with Agile »]

Ce billet est l’œuvre d’un blogueur invité, Giuliano Abraini.

Bonjour à tous, vous connaissez tous l’adage populaire « un chef de projet qui ne gère pas les risques court de gros…risques… ».  Bon OK, elle est de moi celle-là mais quand même.

En effet en chefs de projets avertis que vous êtes, vous n’ignorez pas l’importance de la gestion des risques liés à votre projet.  Sans quoi, une mauvaise surprise peut vous attendre à n’importe quel moment de la vie de votre projet et mettre en péril la réussite de celui-ci.

Le problème est que « gestion du risque » est souvent associée, dans l’imagination collective, à : réunions longues et fastidieuses, rapports imbuvables, prise de décision absente, etc.  Bref, ça flaire l’usine à gaz à plein nez.

Et c’est là que la lumière apparaît au bout du tunnel et que la « génialitude » d’Agile s’exprime.  Et bien oui, il est tout à fait possible de gérer les risques d’un projet à la façon Agile.

Alors concrètement, c’est très simple.  Tout d’abord, il vous faut le matériel de survie du parfait Scrum Master : des feuilles format xxl, des post-it, des marqueurs de couleurs.  Bref rien de neuf sous le soleil.

Dans un premier temps, tracez un tableau à 2 dimensions identifiant le degré de probabilité qu’un risque se produise (de 1 à 4), ainsi que l’impact de celui-ci (de 1 à 4).  Un risque ayant une très grande probabilité de survenir et mettant en péril votre projet aura une quotation probabilité = 4, impact = 4. (1)

"Les

Dans notre tableau, nous avons identifié (en rose) une zone où les risques devaient être monitorés avec d’avantage de fréquence. (2)

Ensuite, le principe peut être découpé en 3 phases :
–    Identifier les risques
–    Les catégoriser
–    Prendre des actions pour réduire / supprimer / éviter les risques

La première étape consiste à identifier l’ensemble des risques liés au projet et de les catégoriser dans le tableau en fonction de leur probabilité et de leur impact.  Ici, nous avons utilisé des post-it de couleur jaune.  A noter, que nous avons également prévu des post-it de couleur bleue pour les risques sur lesquels nous ne prenons pas d’action (3).  Exemple, si le fait que votre seul et unique développeur tombe balade est identifié comme un risque.  Il vous est impossible de supprimer ou de réduire ce risque et ce même si vous servez un thé chaud à votre développeur tous les matins.

Pour la deuxième étape, vous devez classer dans le tableau l’ensemble des risques identifiés. (4)

La troisième étape consiste à identifier la ou les actions que vous allez prendre.  Dans notre tableau, nous avons utilisé des post-it de couleur verte.  Aussi, il est très utile de catégoriser les actions. (5)

En effet, les actions peuvent agir de différentes façons sur un risque :
–    Réduire : ce sont des actions qui permettent de réduire l’impact si le risque se produit ;
–    Eviter : ce sont des actions qui permettent d’éviter que le risque se produise ;
–    Repli : ce sont des actions qui permettent de limiter la probabilité que le risque se produise
–    Transférer : ce sont des actions qui permettent de transférer le risque vers d’autres départements ou acteurs du projet qui ont le mandat pour influencer l’impact ou la probabilité que le risque se produise.

Le Risk Board terminé

Enfin, il est impératif de prévoir un review régulier de la situation.  Pour cela rien de plus simple, organisez des réunions récurrentes au format daily scrum durant lesquelles les différents intervenants passent en revue les actions prises (+ résultats obtenus).  Ensuite, revoyez la situation actualisée des risques durant laquelle vous pouvez supprimer des risques, en ajouter de nouveaux, changer le niveau d’impact, etc.  Bien sûr, n’oubliez pas d’identifier de nouvelles actions !

Voilà, c’est déjà fini.  A vous de jouer maintenant et restez aware…

Giuliano.

(photo par Manitoba49)

A propos de l’auteur:

Je suis consultant, chef de projet depuis 3 ans et j’ai une expérience dans l’IT de plus de 8 ans.  Plus précisément je suis spécialisé en SCRUM et en PRINCE 2 (certifié Foundation).
Après un master en sciences économiques et financières, je suis tombé un peu hasard dans le monde de l’IT.  Depuis je ne le quitte plus…
Durant mes différentes expériences, j’ai eu l’opportunité de recouvrir différents rôles (Analyste, Product Manager, Chef de projet) et d’être actif dans de nombreux secteurs (banques, finance, secteur public).
Ma motivation principale en tant que chef de projet est de satisfaire le sponsor du projet, et de faire en sorte que l’ensemble de l’équipe projet y trouve sa place.

En dehors de ma vie professionnelle, j’adore voyager et je suis un mordu de sport.
Vous pouvez me contacter via giuliano.abraini@yahoo.fr

Risks management with Agile

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)

"Les

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.

Risk Board completed

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!!!

About Giuliano

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 giuliano.abraini@yahoo.fr