Lors d’une de mes récentes formation en gestion de projet, une question particulièrement inhabituelle (et donc très bonne) a émergé ; à quoi cela sert des analyses de risques projet ou des retours d’expérience ?
La réponse semblant trop évidente, je me suis permis de lui demander de préciser son idée derrière sa question.
Voici sa réponse :
» Lorsque nous faisons des analyses de risque, nous utilisons un standard comme si nos projets étaient tous similaires. De plus, nous avons une faible propension à prendre des actions pour venir couvrir les risques ou se protéger de notre expérience négative acquise.
De surcroît, les risques ou les retours d’expériences qui sont saisis sont à la fois de l’ordre de l’aléa et des évènements majeurs. Enfin, les mesures combinées que nous associons à ces risques (probabilité, impact, récurrence) semblent diluer le risque lui-même.
Est-ce que cela fait vraiment sens de ne pas traiter un risque sous prétexte que sa probabilité et sa récurrence sont faibles mais que son impact est fort ? «
Bref derrière une question en apparence anodine, il semble se cacher un vrai problème de fond.
Nous passerons dans cet article le sujet concernant le fait que l’action est définie, reconnue comme bonne mais pas réalisée. C’est en effet un problème d’exécution (ou de courage managériale). Nous allons nous intéresser aux points soulevés par ce questionnement :
- Comment identifier un problème sur un de nos projets ?
- Comment identifier que ce problème est un vrai bon gros problème ?
- Enfin, comment pouvons-nous nous assurer que les actions prises auront un impact positif sur le système ?
Pour réaliser cela, nous allons utiliser l’indicateur du Fever Chart.
Comme vous le savez, l’avancement (en horizontal) est calculé sur le reste à faire. Et la partie verticale représente la consommation du buffer.
Prenons le cas réel d’un de nos clients : remarquez-vous quelque chose dans le déroulé de ces 3 projets ?
Effectivement au début du projet, tout va toujours très bien au point que l’on va plus vite que d’habitude. Puis entre 10 et 20%, les projets partent systématiquement en vrille, puis ils se rétablissent d’un coup sec. De plus, vous remarquerez que pour les deux projets de droite, le client semble s’être rétabli plus vite. C’est tout l’intérêt de l’utilisation de cet indicateur !
Compte tenu de la nature prédictive de l’indicateur, il devient facile de répondre aux 3 questions initiales :
- Comment identifier un problème sur un de nos projets ?
- Dès que le Fever Chart bascule de couleur, vous pouvez enregistrer la nature de l’évènement l’ayant fait basculer.
- Comment identifier que ce problème est un vrai gros problème ?
- Lorsque le Fever Chart bascule dans le rouge de manière verticale, c’est que vous n’avancez plus et que vous consommez le buffer de manière massive.
- Comment pouvons-nous nous assurer que les actions prises auront un impact positif sur le système ?
- Si vous alignez ces indicateurs de projet les uns à côté des autres, vous pourrez visuellement constater un certain schéma se dessiner sur vos projets.
Pour revenir à notre cas, lorsque vous prenez le premier projet, vous constatez les 3 phénomènes au bout de 10 à 20% d’avancement : le projet bascule dans le jaune et rouge de manière violente. Puis il se rétablit tout aussi rapidement dans le jaune.
D’un point de vue du management de projet, il convient de voir ce qu’il s’est passé mais surtout de comprendre ce qui a été mis en œuvre pour revenir dans le jaune aussi rapidement. Ainsi, vous pouvez dupliquer/déployer cette action sur le reste de vos projets : dès que le pic émerge, vous pouvez prendre l’action plus rapidement et rétablir le projet sur les bons rails (cf. les courbes 2 et 3).
Et vous comment votre indicateur de suivi de projet vous permet d’alimenter vos analyses de risques et retour d’expérience ?