ABC de la gestion de projet : R comme Root Cause Analysis

S’attaquer à la racine des problèmes dans les projets

Qu’est-ce que l’analyse des causes profondes au juste ?

La Root Cause Analysis, ou analyse des causes profondes en français, est une approche structurée pour identifier la source causale d’un problème et pas seulement son impact visible.

Prenons un exemple classique :
Votre projet a pris du retard à plusieurs reprises. La cause superficielle semble être un retard de livraison de composants. Cependant, une RCA creuserait plus profondément et demanderait par exemple

• Pourquoi les composants ont-ils été livrés trop tard ?
• Pourquoi le fournisseur a-t-il prévu une capacité insuffisante ?
• Pourquoi n’y a-t-il pas eu d’évaluation des risques avant la commande ?

Vous passez ainsi des symptômes aux causes. Et ce n’est qu’une fois que vous les connaissez que vous pouvez mettre en œuvre des solutions durables afin d’éviter des problèmes similaires à l’avenir.

L’analyse des causes profondes en pratique : un exemple bien connu
L’explosion de la navette spatiale Challenger en 1986 est souvent citée comme un exemple tragique d’ACR dans le domaine de l’ingénierie. A l’origine, l’erreur a été attribuée à une « défaillance matérielle » des joints toriques à froid. Cependant, l’analyse de la cause première a montré que les décisions de gestion et le non-respect des avertissements des ingénieurs en étaient la véritable cause.

Une ACR révèle donc souvent des causes non seulement techniques, mais aussi organisationnelles et communicationnelles.

Pourquoi la RCA est-elle si importante dans la gestion de projet ?

1. Évite les problèmes récurrents et permet ainsi d’économiser du temps, de l’argent et des nerfs. Maîtriser la RCA, c’est donc cesser de jouer les « pompiers » et devenir un créateur stratégique.
2. Améliore la qualité de manière durable, car une RCA vise à une amélioration systématique plutôt qu’à des réparations ad hoc frénétiques.
3. Renforce l’esprit d’équipe, car l’ACR ne doit pas être utilisée pour trouver un coupable, mais est une méthode neutre pour apprendre ensemble.
4. Prend en charge les leçons apprises.

Méthodes typiques d’analyse des causes profondes

1. la méthode des 5 pourquoi

La méthode des 5 pourquoi est un classique parmi les outils RCA. Elle a été inventée par Sakichi Toyoda dans le cadre du célèbre Toyota Production System. L’essentiel de la méthode consiste à demander cinq fois « pourquoi ? » afin de dévoiler progressivement la chaîne de causalité d’un problème et de passer ainsi de la surface du problème à sa véritable cause. Le chiffre cinq n’est pas une loi, trois « pourquoi » suffisent parfois, mais il en faut parfois sept.
La méthode est très facile à mettre en œuvre et est donc souvent utilisée dans les ateliers. Le problème est d’abord défini avec précision. Ensuite, la question « Pourquoi ? » est posée sur l’événement qui précède directement. C’est-à-dire que l’on demande d’abord pourquoi le problème s’est produit. Ensuite, la question est posée sur la réponse précédente.

Exemple tiré de la vie quotidienne du projet :
Problème : L’avancement du projet a pris du retard
Pourquoi ? La tâche A n’a pas été achevée comme prévu
Pourquoi ? L’employé X n’a pas eu assez de temps pour réaliser les tâches
Pourquoi ? Le planning des ressources n’a pas pris en compte les congés de l’employé X
Pourquoi ? Il n’y a pas eu de rapprochement avec le planning des congés
Pourquoi ? Les plannings de congés ne sont pas intégrés dans l’outil de gestion de projet.
Cause : manque d’intégration des données RH dans la planification des projets.

Notre conseil : même si cette méthode est très simple à mettre en œuvre, il est préférable de la réaliser en équipe et non seul à son bureau. Cela vous permettra d’examiner le problème sous différents angles et d’identifier la cause réelle. Ensemble, il est également plus facile de vérifier si une réponse est réellement causale ou si elle ne fournit qu’une explication partielle.

2. diagramme d’Ishikawa (fishbone ou diagramme de cause à effet)

Le diagramme d’Isikawa est idéal pour les problèmes complexes avec plusieurs facteurs d’influence. Il permet de visualiser les relations et les causes dans des catégories telles que

• Humain (par exemple, manque de compétences)
• Machine (par exemple, erreur de logiciel)
• Méthode (par exemple, processus inefficaces)
• Matériel (par exemple, problèmes d’approvisionnement)
• Milieu (par exemple, politique d’entreprise)
• Mesure (par exemple, KPI incorrects)

Vous trouverez une explication détaillée du diagramme d’Ishikawa dans cet article.

3. analyse des arbres de défaillance (FTA)

L’analyse de l’arbre des défaillances (Fault Tree Analysis) est une technique analytique issue à l’origine de l’ingénierie de la sécurité et du risque, mais qui rend également de précieux services dans la gestion de projet. C’est surtout dans le cas de problèmes techniques ou systémiques que l’AFC montre ses atouts. Elle utilise des visualisations de portes logiques (« ET », « OU ») pour identifier les combinaisons de causes qui conduisent à un problème.

Voici comment fonctionne la méthode :

1. Commencez par l’événement principal. Il s’agit de l’événement indésirable à analyser (par ex.)
2. Identifiez ensuite toutes les causes immédiates.
3. Présentez les causes avec des liens logiques. Il existe deux possibilités pour les liens :
   • ET signifie que toutes les causes doivent se produire simultanément pour que le top event se produise.
   • OU signifie que l’une des causes peut déjà déclencher le Top Event.
4. Continuez à décomposer chaque cause jusqu’à ce que vous ne puissiez pas analyser plus profondément ou qu’une analyse plus poussée ne soit pas rentable.

Exemple tiré d’un projet de logiciel :
Top Event : Le serveur web est tombé en panne
Causes (lien OU) : Défaut matériel OU surcharge du système OU erreur de mise à jour. Le Top Event peut donc être déclenché indépendamment par chacune des trois causes identifiées.
En poursuivant l’analyse de la cause « surcharge du système », il est toutefois reconnu que les causes « trafic élevé soudain » et « pas d’équilibrage de charge activé » déclenchent le top event lorsqu’elles se produisent simultanément (lien ET). Ici, l’ALE montre donc que le trafic élevé n’est pas le seul problème, mais que l’absence d’architecture évolutive constitue le véritable point faible.

Notre conseil : l’ALE est plus complexe à créer. C’est pourquoi vous devriez l’utiliser principalement pour les risques critiques ou les problèmes liés à la sécurité et à la conformité.

Conseils sur le choix de la méthode

Meilleures pratiques

• Définissez le problème de manière claire et mesurable. « Retard du projet » est trop peu spécifique. Il vaudrait mieux dire « la livraison A dépasse le délai de 3 jours ». Pour cela, étayez le problème par des faits, par exemple depuis quand il existe, qui il affecte, quelles sont les conséquences ou les symptômes du problème. Vous obtiendrez ainsi une image complète du problème et pourrez analyser les causes plus en détail par la suite.
• Impliquez l’équipe. Les meilleures informations proviennent souvent des collaborateurs opérationnels et non du chef de projet seul. Impliquer votre équipe accélère également la recherche de solutions et aide à voir les causes dont vous pourriez être responsable.
• Séparez les causes et les responsabilités. Une ACR n’est pas un blâme, mais un outil d’amélioration continue. Si vous l’utilisez pour blâmer, l’équipe risque d’être réticente à y participer à l’avenir.
• Documentez les résultats. Les enseignements tirés ne sont utiles que s’ils peuvent être retrouvés ultérieurement et que les bonnes mesures sont prises sur cette base. L’idéal est donc de documenter les résultats de l’ACR dans votre système de gestion de projet et d’y inclure les mesures nécessaires.
• Déduisez des mesures correctives de l’ACR et veillez à les mettre en œuvre. Cela peut paraître banal, mais c’est souvent oublié au quotidien. Une analyse sans mesures est une perte de temps.
• Utilisez l’analyse des causes profondes également en cas de succès, et pas seulement en cas de problèmes. De telles analyses peuvent contribuer à la réussite de projets futurs.

Erreurs typiques de la RCA

• S’arrêter trop tôt : La première cause est rarement la racine, il est donc utile de continuer à poser des questions ou d’utiliser une méthode supplémentaire pour aller à la racine des causes réelles.
• Pas de hiérarchisation : toutes les causes n’ont pas le même niveau de criticité. Analysez le risque et l’impact des différentes causes.
• Pas de durabilité : la documentation, les sessions de leçons apprises et la gestion des connaissances en font partie.

Conclusion

L’analyse des causes profondes est une approche méthodique qui permet d’attaquer les problèmes à la racine plutôt que de se contenter de soigner les symptômes. Les chefs de projet qui appliquent l’ACR de manière cohérente évitent les problèmes récurrents, améliorent leurs processus de manière durable et renforcent leur équipe dans l’apprentissage commun.

Pour plus d’informations sur le logiciel de gestion de portefeuille de projets myPARM:

Souhaiteriez-vous découvrir myPARM lors d’une démonstration? Contactez-nous dès maintenant pour un rendez-vous!