Télécharger le Book

Qu'est-ce qu'un projet zombie ?

Un projet zombie, c'est un projet qui n'est pas mort mais qui n'est plus vraiment vivant. Il consomme de la capacité, il apparaît dans les reportings, il mobilise des ressources — mais il n'avance plus vers un objectif clair.

Officiellement 'en cours'

Il n'a jamais été arrêté formellement. Dans l'outil PPM, son statut est toujours actif.

Pratiquement en pause

Les équipes ne travaillent plus dessus, ou seulement par intermittence. Les réunions sont annulées ou reportées.

Sans sponsor visible

Le sponsor initial a changé de poste, ou ne répond plus. Personne ne défend vraiment le projet.

Objectifs flous ou obsolètes

Le business case initial n'est plus valide. Les conditions ont changé. Mais personne n'a actualisé.

Un projet zombie, c'est un projet dont tout le monde sait qu'il devrait être arrêté — mais que personne n'a le pouvoir (ou le courage) d'enterrer.

Pourquoi les projets ne meurent jamais

Dans une organisation normale, arrêter un projet devrait être une décision rationnelle. Un projet qui ne délivre plus de valeur devrait s'arrêter. Pourtant, les projets zombies prolifèrent. Pourquoi ?

Personne n'a l'autorité

Lancer un projet nécessite une validation. L'arrêter... qui peut décider ? Souvent, personne n'a ce mandat explicite. Alors le projet continue par défaut.

L'effet 'coût irrécupérable'

On a déjà investi 18 mois et 500K€. Arrêter maintenant, c'est 'perdre' cet investissement. Alors on continue, en espérant que ça finira par aboutir.

La peur du blame

Arrêter un projet, c'est admettre un échec. Celui qui décide l'arrêt prend le risque d'être associé à cet échec — même s'il n'en est pas responsable.

Le sponsor est encore là

Le DG métier qui a poussé ce projet est toujours en poste. L'arrêter, c'est le désavouer. On préfère laisser mourir lentement que de créer un conflit.

L'espoir du 'pivot'

On se dit qu'avec quelques ajustements, le projet pourrait repartir. Cette illusion peut durer des années.

Le résultat : des dizaines de projets en état de mort clinique, qui consomment de la capacité fantôme et démoralisent les équipes.

Le coût caché des projets zombies

Un projet zombie ne coûte pas 'rien' sous prétexte qu'il n'avance pas. Il coûte cher — mais de façon invisible.

10-20%

Capacité fantôme

de la capacité IT immobilisée par des projets zombies. Des ressources 'affectées' qui ne peuvent pas être réallouées officiellement.

45 min/sem

Coût cognitif

par personne impliquée : réunions de suivi, mises à jour de statut, réponses aux questions. Multiplié par 10 personnes × 12 mois = 400 heures perdues.

-25%

Impact moral

d'engagement sur les équipes qui travaillent sur des projets sans avenir. Ils le savent. Management le sait. Personne n'agit.

×2

Effet d'encombrement

temps de décision dans les comités. Plus il y a de projets 'en cours', plus il est difficile de prioriser les vrais enjeux.

Exemple chiffré

Une ETI avec 60 projets 'en cours' avait en réalité 15 projets zombies. Après nettoyage : 8 ETP libérés, 3 projets prioritaires accélérés de 40%, satisfaction des équipes IT en hausse de 15 points.

Les 5 signes qu'un projet est zombie

Comment distinguer un projet en difficulté (récupérable) d'un projet zombie (à arrêter) ? Voici les 5 signaux d'alerte.

1

Le sponsor ne répond plus

Les emails restent sans réponse. Les réunions sont décalées. Quand vous le croisez, il change de sujet.

Red flag : Si le sponsor n'est pas capable de défendre le projet en CODIR, c'est un zombie.
2

Le business case n'est plus valide

Les hypothèses initiales ont changé. Le marché a évolué. Le ROI annoncé n'est plus atteignable.

Red flag : Si personne ne peut expliquer pourquoi ce projet est encore prioritaire, c'est un zombie.
3

L'équipe projet s'est dispersée

Le chef de projet a été réaffecté. Les développeurs sont sur d'autres sujets. Les experts ne sont plus disponibles.

Red flag : Si reconstituer l'équipe prendrait plus de 3 mois, c'est un zombie.
4

Les livrables n'évoluent plus

Le dernier commit date de 6 mois. La documentation n'a pas bougé. Les user stories sont les mêmes depuis 4 sprints.

Red flag : Si le projet n'a rien livré de tangible depuis 2 trimestres, c'est un zombie.
5

On évite d'en parler

En comité, le sujet est survolé. Les questions précises génèrent des malaises. Tout le monde sait, personne ne dit.

Red flag : Si mentionner le projet crée un silence gêné, c'est un zombie.

Score rapide

0-1 signe Projet en difficulté — plan de recovery possible
2-3 signes Zone grise — audit approfondi nécessaire
4-5 signes Zombie confirmé — décision d'arrêt à prendre

Comment tuer un projet proprement

Arrêter un projet n'est pas un acte de destruction. C'est un acte de management responsable. Voici le process en 4 étapes.

1

Documenter l'état réel

1 semaine
  • Faire un état des lieux factuel : dépenses, livrables, reste à faire
  • Identifier les assets récupérables : code, documentation, apprentissages
  • Calculer le coût de continuation vs arrêt
  • Préparer une note de synthèse d'une page maximum
Output : Dossier factuel pour prise de décision
2

Obtenir la décision formelle

2 semaines
  • Présenter le dossier au comité d'arbitrage (pas en bilatéral)
  • Proposer explicitement l'arrêt avec arguments
  • Laisser le sponsor s'exprimer (dernière chance de défense)
  • Obtenir une décision écrite et datée
Output : Décision d'arrêt validée par le comité
3

Clôturer proprement

2-4 semaines
  • Communiquer la décision à toutes les parties prenantes
  • Libérer officiellement les ressources
  • Archiver la documentation et le code
  • Clôturer les contrats fournisseurs si applicable
  • Mettre à jour l'outil PPM
Output : Projet officiellement fermé, capacité libérée
4

Capitaliser

1 semaine
  • Organiser une rétrospective courte (1h max)
  • Documenter les 3 enseignements clés
  • Identifier ce qui aurait pu déclencher l'arrêt plus tôt
  • Partager (brièvement) avec les autres chefs de projet
Output : Amélioration du processus de détection

Attention : Ne pas bâcler l'étape 3. Un projet mal clôturé devient un 'projet fantôme' : officiellement mort, mais des gens continuent à y travailler 'au cas où'.

Comment communiquer l'arrêt (sans blâmer)

La communication de l'arrêt est souvent ce qui fait peur. On craint les réactions du sponsor, des équipes, de la direction. Voici comment bien le faire.

Faire

Parler de la décision, pas des personnes

Eviter

Chercher un responsable de l'échec

Exemple : "Le contexte a changé et ce projet n'est plus prioritaire" — pas "Le sponsor n'a pas assuré"
Faire

Reconnaître le travail accompli

Eviter

Minimiser ce qui a été fait

Exemple : "L'équipe a livré X et Y qui seront réutilisés" — pas "C'était une perte de temps"
Faire

Expliquer le 'pourquoi maintenant'

Eviter

Laisser planer le doute

Exemple : "La revue trimestrielle a montré que..." — pas "On a décidé comme ça"
Faire

Annoncer la suite pour les équipes

Eviter

Laisser les gens dans l'incertitude

Exemple : "Sophie et Marc rejoignent le projet Alpha dès lundi" — pas "On verra"

Templates de communication

Email au sponsor Lui permettre de 'sauver la face' en participant à la communication
Annonce à l'équipe Remercier, expliquer, rassurer sur la suite
Communication CODIR Factuel, court, centré sur la réallocation de capacité
Note dans l'outil PPM Raison de clôture + assets récupérables

L'approche Quarter Plan : le mécanisme naturel d'arrêt

Le meilleur moyen de ne pas avoir à 'tuer' des projets zombies, c'est d'avoir un système qui les empêche de naître — ou qui les détecte très tôt.

Dans une approche Quarter Plan, un projet qui n'est pas dans le Quarter Plan n'existe pas. C'est aussi simple que ça.

Revue trimestrielle obligatoire

Chaque trimestre, chaque projet doit 'candidater' pour rester dans le Quarter Plan. Pas de droit acquis. Si le business case ne tient plus, le projet sort.

Capacité limitée

Le Quarter Plan a une limite de capacité. Pour qu'un projet entre, un autre doit sortir. Cela force la décision d'arrêt.

Sponsor engagé

Un projet sans sponsor présent au comité d'arbitrage ne peut pas entrer dans le Quarter Plan. Sponsor parti = projet suspendu automatiquement.

Livrables tangibles

Chaque trimestre, le projet doit avoir livré quelque chose de démontrable. Deux trimestres sans livrable = signal d'alerte automatique.

Résultat : les projets zombies sont détectés en 3 mois maximum — avant d'avoir consommé des années de capacité.

Prévenir plutôt que guérir

Les meilleurs DG ne passent pas leur temps à tuer des zombies. Ils mettent en place des mécanismes qui empêchent les zombies d'apparaître.

Règle d'entrée claire

Aucun projet ne démarre sans business case validé ET sponsor identifié ET capacité confirmée

Revue de santé mensuelle

Un indicateur simple (rouge/orange/vert) par projet, revu en 15 minutes en comité

Critères d'arrêt prédéfinis

Avant le lancement : 'Ce projet s'arrête si X, Y ou Z se produit'

Limite de WIP

Pas plus de N projets actifs par équipe. Force l'arbitrage permanent

Droit à l'échec assumé

La culture valorise l'arrêt rapide ('fail fast') plutôt que l'entêtement

Prêt à passer de l'intention à l'exécution ?

18 pages · PDF gratuit · Envoi immédiat