Project Rescue

Diagnostique un projet en difficulté et construit un plan de redressement honnête – sépare les symptômes des causes profondes à l'aide des documents du projet, évalue l'écart de temps, de coût et de périmètre, expose les vraies options (redresser, réduire le périmètre, ajouter du temps ou de l'argent, faire une pause et replanifier, arrêter) et rédige une note d'une page pour le sponsor, en anglais ou en arabe.

Qu'est-ce que Project Rescue ?

Ce Skill guide un utilisateur – chef de projet, sponsor ou toute personne responsable d'un projet en difficulté – à travers un processus de diagnostic structuré et de planification du redressement. Il est conçu pour les projets en retard, en dépassement de budget, bloqués, en échec, « rouges », hors de contrôle, ou qui perdent la confiance du client ou du sponsor. Le Skill fonctionne en cinq étapes : (1) recueillir le contexte via le récit du porteur de projet et ses documents (plan initial, rapports d'avancement, etc.) ; (2) diagnostiquer en listant les symptômes, en quantifiant l'écart et en traçant chaque symptôme jusqu'à ses causes racines (supported ou hypothesis) ; (3) présenter les options réalistes (récupération, réduction de périmètre, ajout de temps/argent, pause, arrêt) avec leur impact ; (4) élaborer un plan de redressement (stabilisation, replanification, changements des causes, signaux d'alerte précoce, rythme de suivi) ; (5) rédiger une note concise pour le sponsor. Le Skill met l'accent sur les preuves (pas d'opinions), la distinction causes/symptômes, et l'honnêteté, y compris sur les options inconfortables. Il prend en charge l'anglais et l'arabe (arabe standard moderne). Il ne convient pas pour la planification initiale, les rapports de routine ou les conflits personnels. Les utilisateurs sont invités à fournir des documents ; sinon, le diagnostic fonctionne avec ce qui est disponible et signale les lacunes.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/CreativityHouse2025/pm-skills-for-claude/tree/HEAD/skills/project-rescue

Installed? Explore more Productivité et collaboration skills: steipete/gemini, steipete/gh-issues, steipete/skill-creator · View all 6 →

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Que fait Project Rescue ?

Aidez quelqu'un à comprendre pourquoi son projet est en difficulté, quelles sont les vraies options et comment le dire clairement aux personnes qui doivent décider.

Les projets en difficulté reçoivent généralement l'une des deux mauvaises réponses : l'optimisme ("on va rattraper") ou une liste générique de bonnes pratiques. Ni l'une ni l'autre n'aide. Ce Skill repose sur trois engagements :

  1. Les preuves avant l'opinion. Chaque constat se réfère à quelque chose dans les documents du projet ou le récit de la personne. Lorsque la preuve manque, le constat est étiqueté comme une hypothèse, avec ce qui la confirmerait.
  2. Les causes, pas les symptômes. "Nous avons six semaines de retard" est un symptôme. Le plan doit agir sur le pourquoi.
  3. Des options honnêtes, y compris les inconfortables. Réduire le périmètre et arrêter sont de vraies options et sont toujours envisagées.

1. Recueillir le tableau

Demandez ce qui existe ; travaillez avec ce qui est disponible et dites ce qui manque.

Documents utiles : le plan ou la charte initiale, le dernier rapport d'avancement, le calendrier et le budget par rapport au réel, les registres des risques et des problèmes, la liste des modifications apportées depuis le début.

Posez au maximum six questions dans un seul message, uniquement celles auxquelles il n'a pas déjà été répondu :

  1. Que devait livrer le projet, pour quand et pour combien ?
  2. Où en est-il maintenant : qu'est-ce qui est fait, qu'est-ce qui a été dépensé, quelle date est réaliste aujourd'hui ?
  3. Quand a-t-il commencé à aller mal, et qu'est-ce qui a changé à ce moment-là ?
  4. Qu'a-t-on déjà essayé pour le réparer ?
  5. Qui est le sponsor, que sait-il et qu'est-ce qui lui importe le plus : la date, le coût ou ce qui est livré ?
  6. Qu'est-ce qui peut bouger et qu'est-ce qui ne peut pas bouger (une date fixe, un plafond budgétaire, un engagement contractuel) ?

Si la personne est sous pression et en a dit assez pour commencer, lancez le diagnostic et listez les informations manquantes à la fin plutôt que de tout bloquer en attendant les réponses.

2. Diagnostiquer

Lisez references/diagnostic.md pour les domaines de causes et leurs signes.

  1. Listez les symptômes tels que la personne et les documents les énoncent, avec des chiffres.
  2. Évaluez l'écart. Calculez la variance de temps, de coût et de périmètre à partir des chiffres fournis, et montrez le calcul. N'estimez pas un chiffre qui n'a pas été fourni ; dites qu'il est inconnu.
  3. Tracez chaque symptôme jusqu'aux causes. Demandez "pourquoi" jusqu'à atteindre quelque chose qui pourrait être changé. Un symptôme a souvent plusieurs causes, et une cause explique souvent plusieurs symptômes.
  4. Marquez chaque cause comme Supported (indiquez la preuve) ou Hypothesis (indiquez ce qui la confirmerait ou l'infirmerait).
  5. Choisissez celles qui comptent. Deux ou trois causes expliquent généralement la majeure partie du problème. Nommez-les et dites pourquoi celles-ci.
  6. Vérifiez si le plan a jamais été réalisable. Un projet sous-estimé dès le départ a besoin d'une nouvelle base de référence, pas de plus d'efforts sur l'ancienne.

Décrivez les causes en termes de travail, de décisions et de conditions. Ne blâmez pas des personnes nommément : c'est rarement toute la vérité et cela rend le plan plus difficile à adopter.

3. Options

Exposez toujours les options réalistes, pas seulement celle préférée :

OptionQuand elle convient
Récupérer dans le plan actuelL'écart est faible et les causes sont suppressibles
Réduire le périmètreLa date ou le budget est fixe et certains livrables sont moins importants
Ajouter du temps ou de l'argentLe périmètre complet est nécessaire et le sponsor peut le financer
Faire une pause et replanifierLes causes sont floues ou le plan n'a jamais été réaliste
ArrêterLe coût restant dépasse le bénéfice restant, ou le besoin a disparu

Pour chaque option qui s'applique : ce qu'elle nécessite, l'effet sur la date, le coût et le périmètre (calculé lorsque les chiffres le permettent), le risque principal, et ce qui doit être vrai pour qu'elle fonctionne. L'argent déjà dépensé n'est pas une raison pour continuer ; dites-le quand cela motive clairement la réflexion.

Ensuite, donnez une recommandation, étiquetée comme telle, avec le raisonnement. La décision appartient au sponsor.

4. Plan de redressement

Pour l'option recommandée :

  • Stabiliser (les deux premières semaines) : arrêter l'aggravation des dégâts. Actions typiques : geler les nouvelles modifications, confirmer le statut réel de chaque tâche ouverte, fiabiliser le reporting pour que les chiffres soient dignes de confiance, régler les une ou deux décisions qui bloquent le travail.
  • Replanifier : un périmètre, un calendrier et un budget révisés auxquels l'équipe croit, avec les hypothèses notées. Marquez-le comme une nouvelle base de référence proposée nécessitant l'approbation du sponsor.
  • Changer ce qui en est la cause : un changement concret pour chaque cause principale (une règle de décision, une revue, un rôle, une clause fournisseur).
  • Signaux d'alerte précoce : trois à cinq signaux mesurables qui montreraient que le redressement dérape, avec le niveau déclencheur d'action et qui surveille chacun.
  • Rythme de suivi : à quelle fréquence l'avancement est revu avec le sponsor jusqu'à ce que le projet soit stable.

Chaque action a un responsable et une date. Là où la personne n'en a pas nommé, écrivez Responsable : à attribuer plutôt que d'inventer un nom.

5. Note au sponsor

Une page, dans cet ordre : où nous en sommes (l'écart en chiffres) ; pourquoi (les deux ou trois causes principales) ; options avec leur effet sur la date, le coût et le périmètre ; recommandation ; la décision nécessaire et pour quand ; ce qui se passe ensuite.

Rédigez-la clairement. N'adoucissez pas les chiffres, n'enterrez pas la demande et ne promettez pas une date de redressement qui dépend de choses pas encore acceptées. Proposez une version orale (quoi dire dans les deux premières minutes) si la personne doit la présenter en réunion.

6. Langue et ton

Rédigez dans la langue de la personne. Pour l'arabe, écrivez de droite à gauche en arabe standard moderne clair avec le terme anglais entre parenthèses à sa première utilisation. Adaptez-vous à la personne : des mots simples pour quelqu'un sans formation en gestion de projet, des termes standards pour un praticien. Une personne qui gère un projet en échec est généralement stressée ; soyez direct à propos du projet et correct avec la personne.

7. Limites

  • Un diagnostic basé sur des documents et le récit d'une seule personne est un point de départ. Dites ce que vous n'avez pas pu voir.
  • Les litiges contractuels, pénalités, licenciements de fournisseurs ou de personnel, et les risques juridiques nécessitent les services juridiques, commerciaux ou RH de l'organisation. Signalez-les ; ne donnez pas de conseil à leur sujet.
  • N'aidez pas à présenter l'état d'un projet comme meilleur que ce que les preuves montrent. Aidez à dire la vérité correctement.

Skills associés