Il a échoué. Pourquoi ?

Nous sommes dans six mois et le projet a échoué. Rédigez chaque raison comme si c'était déjà arrivé.

Nous nous sommes fiés à la sandbox du prestataire de paiement sans jamais tester les limites de production. Le jour du lancement, le trafic a fait tomber le paiement.
Seule Priya comprenait les scripts de migration des données. Elle est partie en congé au troisième mois et tout s'est arrêté.
Le service juridique a relu les CGU deux semaines avant le lancement et nous avons dû refaire le parcours de consentement.
Signaux d'alerte

Que remarquerions-nous en premier si cela commençait à arriver ?

Les tickets de support du fournisseur mettent plus de deux jours à obtenir une réponse.
La même personne est sollicitée pour la revue de chaque pull request de migration.
De nouveaux tickets apparaissent en milieu de sprint avec « petite demande des commerciaux » dans la description.
Comment l'éviter

Que pouvons-nous faire dès maintenant pour empêcher cela ?

Faire un test de charge sur l'environnement de production du fournisseur au sprint deux, avant de construire dessus.
Mettre quelqu'un en binôme avec Priya sur les scripts de migration et documenter le runbook d'ici la fin du mois.
Programmer une revue juridique du parcours de consentement pendant la conception, pas après le développement.
Responsables et prochaines étapes

Qui est responsable de chaque risque majeur, et pour quand ?

Marco est responsable du test de charge du fournisseur, à terminer d'ici la fin du sprint deux.
Je vais travailler en binôme avec Priya sur la migration et nous publierons le runbook d'ici le 15.
Dana programmera la revue juridique du parcours de consentement avant la validation de la conception vendredi prochain.

Qu'est-ce qu'une rétrospective pré-mortem ?

Un pré-mortem est une séance consacrée aux risques, organisée au lancement d'un projet, avant que le périmètre, les dates et les budgets ne soient figés. L'équipe se projette dans un futur précis : nous sommes dans six mois et le projet a échoué. Chacun note ensuite pourquoi il a échoué, comme si l'échec avait déjà eu lieu. Le psychologue Gary Klein a mis au point cette technique et l'a décrite en 2007 dans son article de la Harvard Business Review, « Performing a Project Premortem ». Elle s'appuie sur des recherches sur la « rétrospection prospective » (prospective hindsight), selon lesquelles imaginer qu'un événement s'est déjà produit aide à en trouver des causes plus précises. C'est le cadrage qui fait toute la différence. Demandez à une équipe « qu'est-ce qui pourrait mal tourner ? » et vous obtiendrez des réponses polies et génériques comme « dérive du périmètre » ou « problèmes de communication ». Demandez « pourquoi a-t-il échoué ? » et les gens citent de vraies causes : l'API du fournisseur qui n'a jamais été testée en charge, la partie prenante qu'on n'a pas consultée, l'unique ingénieur qui détenait tout le savoir. Considérer l'échec comme acquis permet aussi d'exprimer sans crainte des doutes qui, lors d'un lancement plein d'optimisme, paraîtraient négatifs ou déloyaux. Ce modèle de pré-mortem se déroule en quatre étapes dans TeamRetro. D'abord, listez les raisons de l'échec du projet. Identifiez ensuite les signaux d'alerte, convenez de mesures de prévention, puis terminez en attribuant à chaque risque majeur un responsable et une échéance. Cette dernière étape est la plus importante. Un risque sans responsable ni échéance est généralement oublié dès la fin de la première semaine. Utilisez des idées anonymes pour que la hiérarchie n'influence pas ce que chacun écrit et, pour les équipes distribuées, collectez les idées en asynchrone sur une journée, puis réunissez-vous uniquement pour voter et désigner les responsables.

Format de rétrospective pré-mortem

Il a échoué. Pourquoi ?

Nous sommes dans six mois et le projet a échoué. Rédigez chaque raison comme si c'était déjà arrivé.

Cette colonne est le cœur du pré-mortem. Plantez clairement le décor : le projet est terminé, il a échoué et tout le monde le sait. Demandez aux participants d'écrire au passé (« Nous avons raté le lancement parce que... »), car ce cadrage fait émerger des causes plus concrètes que des spéculations sur ce qui pourrait mal tourner. Gardez les idées anonymes pour que les voix les plus seniors ne donnent pas le ton. Prévoyez 8 à 10 minutes d'écriture en silence, encouragez une raison par idée, puis regroupez les idées similaires et votez pour dégager les principaux risques à traiter dans la suite.

Signaux d'alerte

Que remarquerions-nous en premier si cela commençait à arriver ?

Les signaux d'alerte transforment des craintes vagues en éléments que l'équipe peut surveiller. Pour chaque risque majeur issu de la première colonne, demandez quel serait le premier signal observable : un indicateur, un jalon manqué, une tendance dans les daily. Insistez pour obtenir des signaux précis et mesurables. « Le moral baisse » est difficile à suivre. « Deux sprints d'affilée avec plus de 30 % de reliquat » se repère facilement. Ces signaux deviennent les déclencheurs que surveillent les responsables des risques.

Comment l'éviter

Que pouvons-nous faire dès maintenant pour empêcher cela ?

C'est ici que l'équipe passe de l'inquiétude à l'action. Concentrez-vous uniquement sur les risques qui ont reçu le plus de votes, généralement trois à cinq. Pour chacun, demandez ce que l'équipe peut faire cette semaine ou ce mois-ci pour en réduire la probabilité ou l'impact. Privilégiez de petites étapes concrètes plutôt que de grands changements de processus. Si une idée de prévention nécessite une validation ou un budget, notez à qui il faut s'adresser. Restez pragmatique : l'objectif est une liste plus courte d'actions que les gens réaliseront vraiment.

Responsables et prochaines étapes

Qui est responsable de chaque risque majeur, et pour quand ?

Cette colonne est la raison d'être de toute la séance. Chaque risque majeur a besoin d'un responsable nommé et d'une échéance, sinon les craintes recueillies aujourd'hui s'estomperont avant la fin de la première semaine. Les responsables n'ont pas à traiter le risque seuls : ils sont chargés de surveiller les signaux d'alerte et de s'assurer que la mesure de prévention est bien appliquée. Enregistrez chacune comme action dans TeamRetro pour qu'elle soit reprise dans les rétrospectives suivantes, et prévoyez un point rapide au premier jalon pour faire le bilan.

Dans quels cas recourir à cette étude rétrospective ?

  • Au démarrage d'un nouveau projet, d'un lancement de produit ou d'une initiative majeure, avant que le périmètre, les dates et le budget ne soient arrêtés.
  • Avant un jalon à fort enjeu, comme une migration, une mise en production ou la signature d'un contrat, où une mauvaise surprise de dernière minute coûterait cher.
  • Quand une équipe se montre particulièrement optimiste à propos d'un plan et que les membres plus discrets gardent peut-être leurs doutes pour eux.
  • Au début d'une collaboration avec un nouveau fournisseur, un partenaire ou un groupe transverse dont les dépendances sont encore mal comprises.
  • Au début d'un nouveau trimestre ou d'un program increment (PI), pour mettre le plan à l'épreuve avant que l'équipe ne s'y engage.

Exemples de questions pour brise-glace

  • Quel est le plan le plus mémorable que vous ayez vu mal tourner, au travail ou dans la vie, et quel en a été le premier signal d'alerte ?
  • Si ce projet était un film, à quel genre appartiendrait la version où il échoue ?

Vous souhaitez un exercice d'échauffement que votre équipe puisse pratiquer, et pas seulement répondre à voix haute ? Découvrez des brise-glaces gratuits →

Idées et conseils pour votre réunion de rétrospective

  • Organisez le pré-mortem au lancement du projet, avant que les engagements ne soient figés. Ne le faites jamais en pleine crise, quand l'équipe doit résoudre des problèmes et qu'imaginer l'échec ne ferait qu'ajouter de l'anxiété.
  • Gardez les idées anonymes. Si les noms sont visibles, les craintes de la personne la plus senior donnent le ton et les autres se contentent d'acquiescer mollement.
  • Imposez la formulation au passé dans la première colonne. « Pourquoi a-t-il échoué ? » fait émerger des risques plus précis et réalistes que « Qu'est-ce qui pourrait mal tourner ? », alors reformulez avec tact les idées qui glissent vers l'hypothétique.
  • Votez pour ne retenir que trois à cinq risques majeurs avant de parler de prévention. Vouloir traiter chaque idée disperse l'équipe et rien n'aboutit.
  • Ne terminez pas la séance tant que chaque risque majeur n'a pas un responsable et une échéance. Sans eux, les risques recueillis sont oubliés avant la fin de la première semaine.
  • Pour les équipes distribuées, passez en asynchrone : collectez les idées sur une journée, quels que soient les fuseaux horaires, puis réunissez-vous 30 minutes uniquement pour regrouper, voter et désigner les responsables.

Foire aux questions

Quelle est la différence entre un pré-mortem et un post-mortem ?
Un post-mortem a lieu après la fin ou l'échec d'un projet et revient sur ce qui s'est réellement mal passé. Un pré-mortem a lieu avant le début du travail et imagine l'échec à l'avance, pour que l'équipe puisse l'éviter tant qu'il est encore temps d'agir.
Qui a créé la technique du pré-mortem ?
Le psychologue Gary Klein a inventé le pré-mortem et l'a décrit en 2007 dans son article de la Harvard Business Review, « Performing a Project Premortem ». La technique s'appuie sur des recherches montrant qu'imaginer qu'un résultat s'est déjà produit aide à en identifier des causes plus précises.
Combien de temps dure un pré-mortem ?
La plupart des pré-mortems durent 45 à 60 minutes pour une équipe de cinq à dix personnes. Avec l'option asynchrone, la réunion en direct peut être réduite à une trentaine de minutes, car les idées sont déjà recueillies avant l'appel.
Quand faut-il organiser un pré-mortem ?
Organisez-le au lancement du projet, avant que les engagements comme le périmètre, les échéances et les budgets ne soient figés. Évitez de le faire en pleine crise, quand l'équipe doit se concentrer sur la résolution de problèmes réels.
Pourquoi les idées du pré-mortem doivent-elles être anonymes ?
Quand les noms sont visibles, les participants ont tendance à reprendre les préoccupations de la personne la plus haut placée. Les idées anonymes font émerger les risques qui inquiètent vraiment les gens, y compris ceux qui mettent en cause des décisions de la direction.
Peut-on organiser un pré-mortem en asynchrone ?
Oui. Les équipes distribuées peuvent recueillir les idées dans TeamRetro sur une journée, puis se réunir uniquement pour les regrouper, voter sur les principaux risques et désigner des responsables avec des échéances.
Êtes-vous prêt à mener cette rétrospective ?Essayez ce concert rétrospectif