Prémortem de projet : déroulé de réunion et exemple rempli

Un prémortem est une réunion où l'équipe imagine qu'un projet a déjà échoué et cherche à expliquer ce résultat. Il utilise l'inversion : partir de l'échec pour étudier les conditions qui pourraient le produire avant d'exécuter le plan.

Une entreprise fictive va changer de plateforme d'assistance. La démonstration a fonctionné, la formation a eu lieu et la date est annoncée. Il reste à vérifier si les demandes ouvertes conserveront leur historique, leur responsable et leur prochaine action après le changement.

Choisir un échec que l'on peut examiner

L'AHRQ décrit le prémortem comme un moyen d'anticiper les obstacles à la mise en œuvre. Les causes proposées restent des hypothèses à vérifier.

Définissez le résultat indésirable examiné. Pour le changement de plateforme, ce pourrait être une perte de continuité des demandes ouvertes. Dire simplement que le changement a été un désastre laisse place à des craintes portant sur des problèmes différents.

Convenez aussi de la période. Une interruption le premier jour demande d'autres questions qu'une difficulté apparue après des mois d'utilisation. Si les deux comptent, gardez des notes séparées pour éviter de mélanger causes et mesures.

Un déroulé proposé pour une réunion de 45 minutes

Invitez les personnes qui assistent les clients, configurent le système et décident de la transition. Envoyez le plan et le critère d'échec à l'avance. Cette répartition du temps est une proposition d'animation pour ce cas, et non une durée imposée par la technique.

Si la discussion révèle que personne ne sait décrire le parcours d'une demande, arrêtez la sélection des risques et reconstituez ce parcours. Voter sur une liste mal comprise ne fait qu'organiser l'incertitude.

Écrire individuellement avant la discussion peut faire place à une observation qui ne surgirait pas après avoir entendu la direction. Pour cela, la personne qui anime doit accueillir les doutes sans exiger que leur auteur prouve immédiatement toute l'hypothèse.

Remplacer les craintes générales par des mécanismes

« L'équipe va résister » attribue une disposition générale aux personnes. Une formulation plus utile serait : la personne qui reçoit une demande ne saura pas dans quel système la mettre à jour, car les règles de transition n'ont pas été définies.

Demandez quelle condition relie la cause proposée à l'échec. L'outil présente-t-il une limite ? Manque-t-il une décision ? Le problème dépend-il d'un cas exceptionnel ou peut-il survenir dans l'usage courant ? Cherchez des dossiers, des démonstrations et des personnes pour vérifier la relation.

Une longue liste de risques n'indique ni leur fréquence ni leur gravité. Distinguez éléments probants et possibilités, et notez les incertitudes. La technique peut rendre une crainte plus visible sans la rendre plus probable.

Choisir des vérifications qui changent le plan

L'entreprise pourrait migrer un ensemble de demandes ouvertes, puis vérifier l'historique, le responsable et l'action suivante. Elle pourrait aussi simuler un message reçu pendant la transition et suivre son parcours jusqu'à l'assistance.

Chaque vérification demande un responsable et une conséquence pour le plan. Si l'historique essentiel n'est pas conservé, l'équipe pourrait reporter le changement ou maintenir un accès sécurisé en consultation à l'ancien système. La suite dépend de ce qui sera découvert.

Comparez le coût de ces mesures aux autres options. Garder deux systèmes peut préserver l'accès et produire des mises à jour contradictoires. Comme pour le choix des outils, suivez le processus complet et l'effort nécessaire pour quitter chaque option.

Une fiche remplie pour le changement de plateforme

Le dernier risque distingue la présence de données de la possibilité de poursuivre le travail. Un fichier exporté peut exister tout en imposant une recherche manuelle que l'activité ne peut soutenir.

Pour prioriser, commencez par les défaillances empêchant de traiter une demande essentielle et sans récupération démontrée. Examinez ensuite les conséquences importantes vérifiables avant le changement avec peu d'effort. Les désagréments réversibles peuvent rester sous surveillance, avec un responsable désigné. Cet ordre est un critère de travail pour l'exemple, pas une échelle de probabilité validée.

Pour adapter la fiche à votre projet, gardez quatre champs : échec observable ; vérification manquante ; responsable et délai ; décision si le test échoue. La fiche d'enquête peut conserver les observations et distinguer faits et interprétations.

Noter ce que l'exercice n'a pas résolu

Un prémortem dépend des connaissances et de la volonté de participer des personnes présentes. Il peut oublier des problèmes, répéter les croyances du groupe ou focaliser l'attention sur un récit marquant. Invitez quelqu'un à chercher une autre explication du même résultat.

Après avoir corrigé une fragilité, examinez ce que la correction ajoute. Une approbation supplémentaire peut réduire une erreur et créer un délai. Le plan révisé demande lui aussi des responsables, des limites et des conditions de suivi.

À la fin de la réunion, chaque élément bloquant la transition doit avoir une vérification programmée. Si la réponse n'arrive pas avant la date de bascule, quelqu'un devra décider explicitement de reporter ou d'accepter l'exposition restante. Une liste de craintes sans cette conséquence ne donne pas de critère pour autoriser la bascule.