Pourquoi les retours d'expérience changent rarement le projet suivant

Chaque projet se termine par une liste. Ce qui a bien fonctionné, ce qui a échoué, ce que nous ferions différemment. La liste est archivée. Le projet suivant commence, et plus souvent que les équipes ne veulent l'admettre, il commet les mêmes erreurs.

Le problème est rarement la saisie. C'est la distance entre une leçon identifiée et une leçon appliquée. L'un des programmes de retours d'expérience les plus documentés au monde, celui de la NASA, a mesuré cette distance. Ses constats arrivent en premier. Une petite boucle permettant de combler cette distance vient ensuite.

Identifiée ne signifie pas apprise

Une leçon est identifiée lorsqu'on l'écrit. Elle est apprise lorsque l'organisation se comporte différemment grâce à elle. Entre les deux se trouve une charge de travail que la plupart des processus de retours d'expérience n'attribuent jamais à personne.

La recherche sur les organisations de projet nomme directement ce schéma. Dans l'International Journal of Project Management, Duffield et Whitty ont découvert que les processus de retours d'expérience sont rares, et quand ils ont lieu, ils se concentrent sur « l'identification des leçons plutôt que sur l'apprentissage organisationnel ». Le résultat est un document. Le résultat escompté est un changement dans la manière de travailler de la prochaine équipe. Ce sont deux choses différentes, et une seule d'entre elles est facile à produire.

Ce que les propres audits de la NASA ont révélé

La NASA prend les leçons au sérieux. Elle gère le Lessons Learned Information System (LLIS), et son exigence procédurale NPR 7120.6, le Lessons Learned Process, définit comment les leçons sont collectées, validées, évaluées et codifiées. Cela fait de ses audits un cas d'étude utile. Si les leçons stagnent là, la cause n'est pas un manque de volonté.

En 2001, l'U.S. General Accounting Office (devenu le Government Accountability Office) a interrogé les responsables de programmes et de projets de la NASA. Sur les 115 répondants :

• 27 % n'avaient pas connaissance du LLIS avant l'enquête.
• 17,5 % avaient appliqué une leçon trouvée via le LLIS.
• 58 % ont déclaré que les systèmes actuels ne leur permettaient pas de retrouver les bonnes leçons au bon moment.

Le GAO a conclu que « les leçons ne sont pas systématiquement identifiées, collectées ou partagées ». L'apprentissage existait, mais principalement via des revues et des discussions avec des collègues, et non via le système conçu à cet effet.

En 2012, l'Office of Inspector General de la NASA est revenu sur la question. Il a interrogé 28 projets de science et de vol spatial lancés entre 2005 et 2011. Seize chefs de projet ont déclaré utiliser le LLIS, et seulement six d'entre eux l'ont trouvé utile. Douze avaient contribué à des leçons. Seuls dix connaissaient l'obligation de contribuer. Les managers ont décrit le système comme obsolète et difficile à explorer, et beaucoup considéraient leurs propres projets comme trop uniques pour que les leçons passées s'appliquent. L'OIG a également constaté que seuls deux centres de la NASA respectaient pleinement la norme NPR 7120.6 dans la gestion de leur propre processus.

Le schéma est constant sur onze ans. Les leçons étaient stockées. Peu étaient consultées. Encore moins changeaient le travail.

Pourquoi les leçons stagnent

Lisez attentivement les audits : trois causes reviennent sans cesse. Elles s'appliquent bien au-delà du vol spatial.

• Les leçons sont écrites comme des récits, pas comme des instructions. Un paragraphe sur ce qui s'est passé est difficile à mettre en œuvre. Il ne précise pas quel document, quelle étape ou quelle décision doit désormais changer.
• Les leçons vivent à l'écart du travail. Une base de données séparée demande à des personnes occupées d'aller chercher l'information. La plupart ne le feront pas, surtout sous la pression des délais. Le GAO a constaté que les managers apprenaient davantage de leurs collègues et des revues que du système.
• Personne ne vérifie. La saisie est comptabilisée. L'application ne l'est pas. Quand la seule mesure est le nombre de leçons enregistrées, les équipes deviennent très douées pour l'enregistrement.

Aucun de ces points n'est un simple problème technologique. Chacun est un maillon manquant : entre la leçon et l'élément qu'elle doit modifier, et entre ce changement et les preuves qu'il a bien eu lieu.

Pause and Learn : apprendre pendant que le projet est encore en cours

Le centre de vol spatial NASA Goddard a répondu en partie à cela avec une pratique appelée Pause and Learn. Au lieu d'attendre une revue de clôture, l'équipe projet s'arrête à des moments clés du cycle de vie pour mener une réflexion commune.

Selon Edward Rogers et Barbara Fillip, une session standard réunit 10 à 20 personnes d'une même équipe projet pendant environ 90 minutes. Elle traite quatre ou cinq sujets choisis à l'avance et s'articule autour de trois questions : qu'est-ce qui a bien fonctionné, qu'est-ce qui n'a pas fonctionné, et que ferions-nous différemment ? Les règles de base sont lues à chaque session. La discussion est consignée sous forme de carte de connaissances, revue avec le chef de projet, puis partagée lors d'ateliers ultérieurs. Les sessions sont planifiées dans le plan de retour d'expérience du projet, et non pas uniquement lorsqu'un problème survient.

"Pause and Learn" repose sur deux principes justes. Il capture les enseignements tant que la mémoire est fraîche. Et il maintient la conversation au sein de l'équipe qui devra agir. Ce qu'il ne fait pas de lui-même, c'est garantir que le projet suivant exploitera la leçon apprise. Pour cela, une étape supplémentaire est nécessaire.

Un processus de retour d'expérience qui boucle la boucle

La norme internationale pour les systèmes de gestion des connaissances, ISO 30401, définit les exigences pour établir, mettre en œuvre, maintenir, réviser et améliorer un système de gestion des connaissances. Le cadre d'excellence NIST Baldrige demande, dans l'article 4.2, comment vous construisez et gérez la connaissance organisationnelle, comment vous partagez les meilleures pratiques et comment vous utilisez vos connaissances pour ancrer l'apprentissage dans le fonctionnement de votre organisation. Les deux convergent vers la même idée : la connaissance a un cycle de vie, et la capture n'en est que la première étape.

En pratique, une boucle de travail comporte trois étapes.

1. Capturez dans quatre champs. Pour chaque leçon, notez ce que vous attendiez, ce qui s'est réellement passé, pourquoi l'écart s'est produit et ce que vous allez changer. Le dernier champ est le plus important. Si une équipe ne peut pas nommer un changement, il s'agit d'une observation, pas d'une leçon.

2. Liez la leçon à sa cible. Chaque leçon doit pointer vers la procédure, la checklist, le modèle ou la décision qu'elle modifie. Mettez à jour ce document et enregistrez le lien. Désormais, la leçon vit là où la prochaine équipe travaillera, et non dans un dossier qu'elle devrait penser à ouvrir.

3. Vérifiez que le projet suivant l'a appliquée. Lorsqu'un projet ultérieur atteint l'étape concernée par la leçon, confirmez que la procédure mise à jour a été utilisée. Si c'est le cas, la leçon est appliquée. Sinon, cherchez pourquoi. Peut-être que le changement n'était pas clair ou que l'étape a été sautée. Ce constat est en soi une leçon, qui revient à la première étape.

Chez Roadyom, notre règle est : la preuve avant l'affirmation. Pour les leçons, cela signifie que rien n'est considéré comme appris tant qu'un travail ultérieur ne le démontre pas. Mesurez donc la boucle par sa dernière étape. Un indicateur simple : parmi les leçons capturées l'année dernière, combien sont liées à une procédure, et combien d'entre elles ont été appliquées par un projet ultérieur ? Ce chiffre est plus difficile à faire progresser qu'un simple décompte de leçons enregistrées. C'est aussi le seul qui vous indique si vous apprenez réellement.

Une leçon qui ne nomme aucun changement est une observation. Un changement qu'aucune étape ultérieure n'utilise est un brouillon.

Comment Prism gère cette boucle

Prism intègre les décisions et les connaissances d'une organisation directement dans les étapes du travail. Une équipe peut ouvrir un enregistrement "Pause and Learn" à n'importe quelle étape, noter ce qui était attendu, ce qui s'est passé, pourquoi, et quels changements effectuer, puis lier chaque leçon à la procédure qu'elle doit mettre à jour. Prism ne considère une leçon comme intégrée que lorsqu'elle est liée à une procédure et qu'une étape ultérieure l'a appliquée. D'ici là, elle reste visible comme "ouverte". Les collaborateurs décident de ce qu'il faut changer ; Prism garde la trace de la pérennité de ce changement.

Sources

1. Étude du processus de retour d'expérience de la NASA (GAO-01-1015R). U.S. General Accounting Office (devenu Government Accountability Office), 2001.
2. Examen du système d'information sur le retour d'expérience de la NASA (IG-12-012). NASA Office of Inspector General, 2012.
3. Mapping des leçons apprises pour améliorer l'apprentissage contextuel à la NASA. NASA Goddard Space Flight Center (E. W. Rogers, B. Fillip), NASA Technical Reports Server, 2016.
4. Développement d'un modèle de connaissance systémique des leçons apprises pour l'apprentissage organisationnel par les projets. International Journal of Project Management 33(2) (S. Duffield, S. J. Whitty), 2015.
5. ISO 30401:2018 Systèmes de gestion des connaissances — Exigences. International Organization for Standardization, 2018.
6. Baldrige Excellence Builder 2021–2022 (Article 4.2, Gestion de l'information et des connaissances). NIST Baldrige Performance Excellence Program, 2021.

Commentaires

Votre nomVotre commentaire

Les commentaires s'affichent après lecture par notre équipe. Merci de ne pas inclure de données personnelles concernant des patients ou des collègues.

Publier le commentaire