La plupart des équipes organisent un post-mortem quand un projet tourne mal. Bien moins nombreuses sont celles qui tiennent la réunion qui aurait pu le sauver : un pre-mortem, avant que le travail ne commence. Les deux sont le reflet l’un de l’autre. Le pre-mortem imagine que le projet a déjà échoué et se demande pourquoi. Le post-mortem examine un projet terminé et se demande ce qui s’est réellement passé.
Ce guide couvre les deux : ce qu’est chacun, comment le mener et les vingt questions que nous utilisons dans l’un comme dans l’autre. Poser les mêmes questions au début et à la fin, c’est tout l’intérêt. Une fois le projet terminé, vous voyez quels problèmes vous aviez vus venir, lesquels vous aviez vus venir sans les éviter pour autant, et lesquels personne n’avait imaginés.
Pre-mortem et post-mortem en un coup d’œil
| Pre‑mortem | Post‑mortem | |
|---|---|---|
| Quand | Une fois le plan rédigé, avant le début du travail | Après la livraison, ou après un jalon ou un incident important |
| Point de départ | « Nous sommes un mois après l’échéance, et le projet a échoué. » | Le projet tel qu’il s’est réellement déroulé |
| La question | Pourquoi a-t-il échoué ? | Que s’est-il passé, et pourquoi ? |
| Participants | Les personnes qui feront le travail, et le responsable du plan | L’équipe, plus les parties prenantes qui ont dû composer avec le résultat |
| Ce que vous obtenez | Une liste de risques classés, et des changements au plan | Des leçons, et des actions pour le prochain projet |
| Durée | Environ une heure | Une à deux heures, plus le temps de rassembler les faits |
Qu’est-ce qu’un pre-mortem ?
Un pre-mortem est une réunion de planification au cours de laquelle l’équipe part du principe que le projet a déjà échoué et cherche pourquoi. Le psychologue Gary Klein l’a décrit dans « Performing a Project Premortem » (en anglais), dans le numéro de septembre 2007 de la Harvard Business Review.
Tout tient dans la formulation. Demander « qu’est-ce qui pourrait mal tourner ? » ne produit que quelques réserves polies, parce que personne ne veut paraître négatif face à un plan que l’équipe vient d’approuver. Dire « c’est un échec, dites-moi pourquoi » fait de la recherche des problèmes la mission de chacun, et ceux qui avaient des doutes ont enfin une raison de les exprimer. Klein cite une étude de 1989 de Deborah Mitchell, Jay Russo et Nancy Pennington, selon laquelle imaginer qu’un événement s’est déjà produit, ce qu’ils ont appelé prospective hindsight (rétrospection prospective), augmente de 30 % la capacité à identifier correctement les raisons de résultats futurs.
Comment mener un pre-mortem
- Choisissez le moment. Organisez-le une fois le plan rédigé mais avant le début du travail : assez tard pour avoir quelque chose de concret à décortiquer, assez tôt pour pouvoir le changer.
- Invitez les personnes qui feront le travail. Elles savent où le plan est fragile. Si un client ou un autre service peut faire couler le projet, faites venir quelqu’un qui le connaît bien.
- Plantez le décor. Choisissez une date après l’échéance et décrivez l’échec sans détour : « Nous sommes en mars. Le nouveau site a été lancé avec six semaines de retard et hors budget, et le client discute avec d’autres agences. »
- D’abord, chacun de son côté. Donnez à chacun cinq minutes pour lister, en silence, toutes les raisons qui lui viennent. Écrire avant de parler empêche la première personne qui parle, ou la plus haut placée, d’imposer l’ordre du jour.
- Faites un tour de table. Chacun lit une raison à la fois, jusqu’à ce que toutes figurent sur la liste commune. Ne les débattez pas encore : notez-les, simplement.
- Classez et choisissez. En groupe, marquez les raisons à la fois probables et dommageables. La plupart des équipes en retiennent trois à cinq qui justifient d’agir.
- Modifiez le plan. Chaque risque retenu devient un changement, avec un responsable et une date : une échéance plus précoce pour les textes, un second valideur, un point d’étape avec le client. Gardez la liste là où vous la reverrez à chaque jalon.
Qu’est-ce qu’un post-mortem de projet ?
Un post-mortem est une revue organisée à la fin d’un projet, pour comprendre ce qui s’est passé et ce qu’il faut changer la prochaine fois. Selon les équipes, on parle aussi de rétrospective ou de retour d’expérience (RetEx ou Rex). Il n’est pas réservé aux échecs : un projet réussi a aussi ses leçons, et il est plus facile d’en parler.
Ce qui fait fonctionner un post-mortem, c’est qu’il ne cherche pas de coupable. Le livre Site Reliability Engineering de Google (en anglais), qui fait du post-mortem une pratique centrale, explique que pour être vraiment sans reproche, un post-mortem doit se concentrer sur l’identification des causes qui ont contribué à l’incident, sans mettre en cause aucune personne ni aucune équipe. Il rappelle aussi que cette culture sans reproche est née dans la santé et l’aéronautique, où les erreurs peuvent être fatales. Si les gens s’attendent à être blâmés, ils défendent leurs décisions au lieu de les expliquer, et personne ne tire de leçon de la réunion.
Comment mener un post-mortem
- Organisez-le vite. Dans la semaine ou les deux semaines qui suivent la livraison, tant que chacun se souvient encore des raisons de ses choix.
- Rassemblez d’abord les faits. Avant la réunion, reconstituez la chronologie : dates prévues et dates réelles, budget et dépenses, et les décisions qui ont changé le cap. Si le projet a été mené dans Redbooth, ses listes de tâches, ses dates d’échéance et ses fils de commentaires contiennent déjà l’essentiel de cet historique.
- Posez d’entrée la règle du jeu. Dites à voix haute que l’objectif est de corriger le processus, pas de trouver un coupable.
- Commencez par la liste du pre-mortem. Passez-la en revue en premier : les risques évités, ceux qui se sont produits quand même, et ce que personne n’avait prévu. Cette comparaison est la mesure la plus honnête qui soit de la qualité de planification de l’équipe.
- Parcourez les quatre catégories ci-dessous, en couvrant ce qui a bien fonctionné autant que ce qui a échoué.
- Terminez par des actions, pas par des constats. Chacune reçoit un responsable et une place où le prochain projet la trouvera, comme son plan ou son pre-mortem.
Les 20 questions à poser dans les deux réunions
Nous regroupons les questions en quatre catégories : planification, exécution, résultats et communication. Ce sont les mêmes questions dans les deux réunions ; seul le temps des verbes change. Dans le pre-mortem, vous demandez pourquoi vous allez manquer votre objectif principal, et dans le post-mortem, pourquoi vous l’avez manqué.
Planification
- Plan du projet : Que manque-t-il au plan ? Quelles parties sont floues ?
- Ressources : Avons-nous évalué et réparti correctement les personnes, le budget et les outils ?
- Calendrier : Les échéances sont-elles réalistes et liées à des objectifs précis ? Y a-t-il de la marge pour les retards imprévus ?
- Tâches : Toutes les tâches nécessaires sont-elles prévues, avec des dépendances et des livrables clairement définis ?
- Documentation : Notre façon de documenter les décisions et le travail est-elle suffisante ?
Exécution
- Retards : Comment mieux gérer les retards imprévus ?
- Flux de travail : Où sont les points faibles dans la façon dont le travail passe d’une personne à l’autre ?
- Personnes : Comment rendre les rôles et les responsabilités clairs et cohérents ?
- Tâches : Qu’est-ce qui rend les tâches difficiles à mener à bien au quotidien ?
- Management : En quoi le management gêne-t-il le travail ?
Résultats
- Objectif principal : Pourquoi allons-nous manquer (avons-nous manqué) notre objectif principal ?
- Objectifs secondaires : Pourquoi allons-nous manquer (avons-nous manqué) les autres ?
- Qualité : En quoi notre travail sera-t-il (a-t-il été) en deçà de la qualité promise ?
- Performance externe : Pourquoi le client est-il mécontent ? Qu’est-ce qui ne va pas dans notre façon de mesurer le succès avec lui ?
- Performance interne : Qu’est-ce qui ne va pas dans notre façon de mesurer le succès en interne ?
Communication
- Canaux : Quels sont les inconvénients de nos principaux moyens de communication ?
- Équipe : En quoi les membres de l’équipe auront-ils (ont-ils eu) du mal à communiquer ?
- Managers : En quoi les managers auront-ils (ont-ils eu) du mal à communiquer ?
- Réunions : Qu’est-ce qui ne va pas dans notre façon de tenir les réunions ?
- Parties prenantes : Où notre communication avec les parties prenantes va-t-elle se rompre (s’est-elle rompue) ?
Répondez avec des faits, pas avec des verdicts. « Le plan était mauvais » n’aide personne. « Le plan ne prévoyait pas de temps pour la relecture juridique du client, qui a pris neuf jours », si.
Exemple : la refonte d’un site web, avant et après
Voici comment les deux réunions s’articulent, avec un projet inventé : une équipe marketing qui refond le site web de son entreprise et dispose de huit semaines jusqu’au lancement.
Le pre-mortem. Au démarrage, l’équipe imagine que c’est le jour du lancement et que le nouveau site n’est pas en ligne. Parmi les raisons qu’elle liste :
- Les pages produit attendaient des textes de trois services, et ils sont arrivés tard.
- Le juridique a relu la nouvelle page de confidentialité la dernière semaine et a demandé des modifications.
- Personne ne gérait les redirections des anciennes URL, et le trafic issu des moteurs de recherche a chuté après le lancement.
- Le PDG a vu la maquette pour la première fois en semaine 7.
Chacune entre dans le plan sous forme de tâche avec un responsable : les textes à livrer deux semaines avant le gel du code, la relecture juridique planifiée en semaine 4, un plan de redirection des anciennes URL pour le développeur, et une revue de maquette de quinze minutes avec le PDG en semaine 2.
Le post-mortem. Le site est lancé avec une semaine de retard. En reprenant d’abord la liste du pre-mortem, l’équipe constate :
- Évité : les redirections étaient en place le jour du lancement, la relecture juridique s’est tenue en semaine 4 comme prévu, et les retours du PDG sont arrivés assez tôt pour être pris en compte.
- Prévu, mais arrivé quand même : un service a tout de même livré ses textes en retard, parce que le responsable des textes était en congé et que personne d’autre n’avait été désigné.
- Personne ne l’a prévu : les licences des photos de la nouvelle page d’accueil n’ont été validées que la semaine du lancement.
Les actions en découlent : chaque livrable reçoit un suppléant, et « visuels et licences » devient un point permanent du prochain pre-mortem.
Menez les deux dans Redbooth avec le modèle gratuit
Notre modèle Project Post-mortem Analysis place les vingt questions dans un espace de travail Redbooth : une liste de tâches par catégorie, et une tâche par question. Le modèle est en anglais.
Voici une façon de l’utiliser tout au long d’un projet :
- Au démarrage, ouvrez le modèle, cliquez sur Create Workspace et menez le pre-mortem dans le nouvel espace de travail. Vous devez être connecté à Redbooth ; si vous n’avez pas encore de compte, créez-en un d’abord. Notez chaque raison comme sous-tâche de la question à laquelle elle répond, et ajoutez les risques que vous décidez de traiter à l’espace de travail du projet, sous forme de tâches avec un responsable et une date d’échéance.
- Pendant le projet, conservez l’espace de travail. Un coup d’œil à chaque jalon montre si les risques que vous avez classés en tête sont sous contrôle.
- À la fin, rouvrez-le pour le post-mortem. À côté de chaque réponse du pre-mortem, ajoutez ce qui s’est réellement passé, puis les actions pour le prochain projet.
Comme l’espace de travail reste, le pre-mortem du projet suivant peut partir des leçons du précédent plutôt que d’une page blanche.
Les erreurs qui rendent les deux réunions inutiles
- Tenir le pre-mortem une fois le plan figé. Si rien ne peut changer, les gens cessent de signaler les problèmes.
- Laisser parler en premier la personne la plus haut placée. Tous les autres alignent leur liste sur la sienne. Écrivez d’abord chacun de son côté.
- Chercher un coupable. Le prochain post-mortem sera plus court, plus poli et plus creux.
- Des actions sans responsable. « Nous devrions mieux communiquer » n’est pas une action.
- Ne jamais relire le dernier post-mortem. Des leçons que personne ne relit au démarrage suivant ne sont pas des leçons. Faites du dernier post-mortem le premier point à l’ordre du jour du prochain pre-mortem.
Questions fréquentes
Un pre-mortem, est-ce la même chose qu’une analyse des risques ?
Non, même s’il l’alimente. Un registre des risques recense et suit les risques connus tout au long d’un projet. Un pre-mortem est une réunion unique, conçue pour faire émerger les risques que personne n’a encore notés, en particulier ceux que les gens hésitent à soulever. Ce qu’il révèle peut ensuite rejoindre le registre.
Quelle différence entre un post-mortem et une rétrospective ?
Surtout la portée. Les équipes agiles tiennent une rétrospective à la fin de chaque sprint, pour ajuster leur façon de travailler en cours de route. Un post-mortem revient sur un projet entier, ou sur un incident précis, une fois celui-ci terminé. Les questions sont proches.
Combien de temps doit durer chaque réunion ?
Environ une heure suffit pour la plupart des pre-mortems. Un post-mortem demande en général une à deux heures, plus le temps de reconstituer la chronologie en amont.
Faut-il faire un post-mortem quand un projet réussit ?
Oui. Un succès a lui aussi des causes, et savoir lesquelles reproduire est tout aussi utile que savoir quoi éviter. C’est en outre le moyen le plus simple de faire des post-mortems une habitude plutôt qu’une punition.
Commencez par le prochain projet de votre liste : réservez une heure avant le démarrage, et copiez le modèle dans un espace de travail pour y consigner les réponses.