Le retour d'expérience, aussi appelé REX ou RETEX, est un principe permettant de capitaliser sur les enseignements tirés des expériences vécues, qu'elles soient positives ou négatives.
Pour les projets IT, s'appuyer sur les leçons apprises est une formidable opportunité pour favoriser l'atteinte des objectifs recherchés.
Cet article va se pencher sur les avantages d'une approche de retour d'expérience projet. Vous y trouverez des exemples de REX projet pour vous aider comprendre et mettre en place cette démarche.
Cet article s'appuie fortement sur les bonnes pratiques de Prince2. Pour l'anecdote, cette méthode est elle-même construite et améliorée grâce à des retours d'expériences de nombreux projets, réussis ou non.
Sommaire
- Qu'est-ce qu'un REX projet ?
- Exemples de retours d'expérience qui aident un projet informatique
- Les bénéfices du retour d'expérience
- Quand et comment collecter et consolider l'expérience ?
- Exemple de REX projet : quand la NASA tire les leçons d'un programme spatial
- Conclusion
Qu'est-ce qu'un REX projet ?
À la différence des opérations courantes, un projet est constitué d'un ensemble d'activités uniques et temporaires.
De par sa nature exceptionnelle, un projet se confronte inévitablement à des situations inhabituelles voire totalement nouvelles. Une démarche de REX projet permet de profiter des leçons tirées par les projets menés dans l'entreprise, pour améliorer la performance des projets en cours et à venir.
A l'échelle de l'entreprise, une approche de retour d'expérience projet favorise une culture de capitalisation et d'apprentissage au sein de l'organisation. Les projets deviennent à la fois source d'information et bénéficiaires des processus d'amélioration continue de l'entreprise.
Exemples de retours d'expérience qui aident un projet informatique
Pour mieux comprendre l'intérêt de cette démarche sur des projets, imaginons quelques recommandations fictives qui pourraient être mises en place au lancement d'un nouveau projet qui décide de s'appuyer sur les expériences précédentes :
- Mise en place d'une matrice de responsabilités projet qui a déjà démontré son efficacité pour la prise de décision et l'implication des parties prenantes, adaptée à la culture de l'entreprise.
- Choix de pratiques ayant obtenu une adhésion par le passé pour assurer la traçabilité et le suivi des tâches d'un projet, en s'intégrant au outils et processus déjà en place dans les différentes équipes contributrices.
- Mise en place d'un reporting projet avec une fréquence et un niveau de détail adapté à la disponibilité de la direction de l'entreprise.
- Adoption d'une méthode déjà utilisée pour la spécification des besoins utilisateurs lorsque ceux-ci sont d'un corps de métiers en particulier.
Les bénéfices du retour d'expérience
Dans une démarche de retour d'expérience, les projets en cours tirent parti des leçons apprises, et partageant leurs propres expériences au profit de l'entreprise. Win-win !
Bénéfices pour l'équipe projet
- Gain d'efficacité et de temps.
- Réduction des risques les plus courants.
- Améliore la collaboration et l'engagement des contributeurs.
- Valorise les efforts réalisés par l'équipe projet en mettant en lumière les solutions trouvées.
Bénéfices pour l'entreprise
- Participe à alimenter et à faire vivre les efforts d'amélioration continue dans l'entreprise.
- Participe à la capitalisation des connaissances dans l'entreprise.
- Participe à la réduction des coûts, en gagnant du temps et anticipant les difficultés.
- Réduit le nombre de décisions pour la gouvernance du projet.
- Accélère l'intégration de nouveaux chefs de projet dans l'entreprise (internes ou externes).
- Participe à créer et maintenir une méthode de gestion projet uniforme dans l'entreprise, maintenant ainsi les équipes projet dans un environnement qu'ils connaissent et maitrisent (outils, vocabulaire, communication uniforme d'un projet à l'autre).
Quand et comment collecter et consolider l'expérience ?
Deux documents simples suffisent
Mauvaise nouvelle : pour capitaliser, il faut documenter. Sans écrit, il est impossible de pérenniser et faire circuler le savoir.
Mais bonne nouvelle : des documents simples peuvent faire l'affaire.
Dans une démarche de partage d'expérience, il peut être intéressant de distinguer deux documents qui s'adressent à deux publics et situations différentes. Ils font partie de l'ensemble des documents de management de projet recommandés par Prince2. Ils entrent dans le cadre du principe des "leçons tirées de l'expérience" qui vise à systématiser cette pratique quel que soit le projet.
Le journal des retours d'expérience du projet
Finalité : Recueil des leçons, bonnes ou mauvaises, apprises susceptibles de s’appliquer à ce projet ou à des projets futurs.
Composition selon Prince2 :
- Type de retour d'expérience (pour ce projet, pour l'entreprise, ou pour les deux).
- Détail du retour d'expérience (évènement, effet, déclencheur, recommandations …).
- Date et auteur de l'enregistrement.
- Priorité
Format à privilégier selon Prince2 : un tableur, une page wiki, un document texte, une entrée dans l'outil de gestion de projet ...
Exemple de journal des retours d'expérience sous Excel
Le rapport des retours d'expérience
Finalité : Sortir une leçon du projet pour qu'elle soit avantageusement utilisée par les projets futurs. Ce rapport doit encourager la mise en place d'actions pour intégrer les leçons positives et pour éviter les expériences négatives.
Composition et format selon Prince2 : libres.
Exemple de rapport des retours d'expérience sous Word
Les bonnes pratiques pour documenter les retours d'expérience
Voyons plus en détail les recommandations de Prince2 quant à l'usage de ces deux documents.
Au début du projet : s'appuyer sur l'expérience des autres
Durant la phase d'élaboration du projet (parfois appelé initialisation), un certain nombre de décisions structurantes sont prises pour définir une organisation projet adaptée.
À ce stade du projet, le chef de projet doit récupérer les retours d'expérience déjà documentés pour s'en inspirer. Ce sujet peut par exemple être abordé pendant la réunion de cadrage du projet.
En cours de projet : collecter et documenter les retours d'expérience
Une fois lancé, un projet doit alimenter son journal des retours d'expérience avec les observations et enseignements qui pourraient être profitables à de futurs travaux.
En s'adaptant aux pratiques en place, ce recueil des retours d'expérience peut se faire de façon spontanée et/ou lors d'ateliers (dédiés ou non).
Parce que la capitalisation déchaîne rarement les foules, le chef de projet doit être le moteur principal des retours d'expérience sur le projet qu'il conduit :
- Il doit détecter par lui-même les expériences et leçons à partager.
- Il doit encourager les contributeurs du projet exprimer leurs avis pour les impliquer et être sûr de ne rater aucun fait marquant.
- Il doit veiller au bon niveau de détail consigné dans les documents (ni trop, ni trop peu) pour que les leçons soient exploitables à postériori. Autrement dit, il peut être préférable que le chef de projet se charge de compléter lui-même ces documents de management.
A la clôture du projet
C'est dans la phase finale d'un projet qu'un enseignement sort du journal de retours d'expérience. Un rapport des retours d'expérience permet de transmettre les enseignements pouvant être appliqués à d’autres projets.
Il est à noter qu'un rapport des retours d'expérience peut être envisagé à d'autres étapes du projet. Par exemple à la fin d'une séquence de management si un projet est long et met en lumière un enseignement profitable à d'autres projets démarrant prochainement.
Que devient ce rapport ? Ses recommandations peuvent alimenter les processus, méthodes ou consignes d'entreprise.
La roue de l'amélioration continue d'une entreprise est un sujet à part entière qui ne pourra être traité dans cet article. Pour donner un ordre d'idée, ITIL v3 consacre un tome entier de 230 pages à la seule amélioration continue des services IT ...
Exemple de REX projet : quand la NASA tire les leçons d'un programme spatial
Pour illustrer cet article, je vous propose ce qui ne représente qu'une ligne dans toute l'histoire de l'ingénierie spatiale. Mais en fin de paragraphe, nul doute que vous y verrez un parallèle évident avec les projets informatiques !
SpaceX n'est pas à l'origine du lanceur non habité, monoétage, réutilisable, à vol autonome, à décollage et atterrissage vertical.
Ce concept a été développé et testé par McDonnell Douglas dans les années 90, avec des ambitions d'abord militaires (guerre froide) puis civiles (enjeux économiques). Nom du programme : Delta Clipper.
Au cahier des charges : allers-retours dans l'espace, réduction des coûts, simplification de la maintenance, faible nombre d'opérateurs nécessaires, réutilisable sous 3 jours à peine.
Bien que doté d'un budget limité, d'une équipe réduite et de plannings serrés, le projet a réussi la prouesse de concevoir, assembler et faire voler un prototype avec quelques mois d'avance sur le planning prévisionnel.
Delta Clipper Experimental (DC-X), le prototype à l'échelle 1/3 du lanceur final, a réalisé plusieurs vols d'essai. Ceux-ci ont permis de faire monter le lanceur jusqu'à plus de 3000 mètres d'altitude, réalisant des manœuvres de translation, de roulis, d'inclinaison, de mise à l'horizontale puis redressement (simulant le retour sur terre), en se posant comme une feuille à l'endroit prévu.
Le 12ème vol du DC-X fut le dernier. En phase d'approche, le prototype déploya seulement 3 de ses 4 pieds d'atterrissage. Une fois posé, le lanceur bascula lentement jusqu’à se coucher au sol et exploser. Le seul et unique prototype du programme est alors détruit.
Ce crash sonna le glas du programme, la NASA décidant de stopper son financement. Aucun autre prototype ne sera construit. Le lanceur échelle 1 ne verra jamais le jour.
Une enquête et analyse fut alors diligentée par la NASA.
Je vous présente le rapport des retours d'expérience de la NASA sur l'incident du DC-X : https://llis.nasa.gov/lesson/638
Un rapport de deux pages, en sources ouvertes, accessible à un public non expert, qui présente le contexte, les évènements, les leçons apprises et les recommandations. Bref, un modèle à montrer dans toutes les écoles :)
Pour terminer l'histoire du DC-X, une synthèse du rapport :
- Leçons apprises : Tuyau du pied d’atterrissage n°2 non connecté. Erreur humaine liée aux interruptions des opérateurs et au manque de procédures. Aggravé par une conception inadaptée aux contrôles qualité. Absence d'automatismes de vérifications qualité. Risque pour le programme si crash de l'unique prototype. Stratégie motivée par une priorité donnée au développement rapide en sacrifiant la qualité et la fiabilité.
- Recommandations : Renfort de l'analyse des risques. Renfort des contrôles qualités. Efforts à mener sur les documentations opérationnelles. Remise en question du principe de prototypage rapide.
Je suis sûr que bien des lecteurs, même loin du spatial, auront trouvé dans ces conclusions des similitudes avec des situations déjà rencontrées dans leurs entreprises respectives.
Conclusion
Ce dernier exemple illustre que des choses incroyables peuvent être réalisées grâce à l'intelligence humaine et la collaboration. L'organisation prend alors une place critique tant dans le succès que dans l'échec de ces travaux.
Le principe des "leçons tirées de l'expérience" est un des fondamentaux pour éviter de reproduire les erreurs du passé et améliorer l'efficacité des futurs projets.
Chaque projet offre des opportunités d'apprentissage qui représentent de réelles sources de valeur pour l'entreprise. Même sans disposer des moyens d'une agence d'état, la démarche de retour d'expérience devrait être considérée par toutes les entreprises qui cherchent à progresser.
Sources :