Reprendre un projet en crise, ce n’est pas un exercice facile et cela demande de l’énergie. Pour être honnête, pendant longtemps je traînais les pieds pour le faire. En revanche, une fois dedans, c’est très enrichissant comme expérience : généralement on découvre plein d’erreurs à ne pas faire ..
Pour cette étude de cas, d’abord un peu de contexte au moment de la reprise : un projet de plus de 350 jours, une équipe de 4 personnes chez le client, un engagement au forfait et plus de 40% de dépassement prévu en fin de projet …
Alors oui, il y avait des tableaux excel de suivi avec des indicateurs projets, des calculs de coûts, des courbes et tout ça. Mais en donnée cruciale en entrée il y a encore et toujours le fameux reste à faire. Vous aurez beau avoir les plus beaux outils du monde pour piloter vos projets, si vous et votre équipe ne maîtrisez pas votre reste à faire, vous ne maitrisez rien.
Je ne suis pas magicien !
Quand le projet est sensé être terminé et qu’il y a encore 40% du boulot à faire, faut pas se leurrer, vous reviendrez très difficilement dans le planning et dans le budget, à moins d’avoir une re-négociation musclée avec le client (mais encore faut-il avoir de bons arguments …). Il y a généralement une inertie qui va mettre un peu de temps à se résorber. Comme le Titanic qui essaie d’éviter l’iceberg mais qui met du temps à virer ..
Et si l’équipe n’est pas sensibilisée au chiffrage de manière générale et à l’estimation du reste à faire en particulier, ne vous attendez pas à des miracles.
Donc tout ce que vous pouvez faire au niveau du budget c’est limiter la casse. Pour le reste, vous pouvez par exemple améliorer la communication et la visibilité client qui ont généralement souffert lors des dernières semaines ou bien re-vérifier les étapes de validation, vérifier le périmètre, etc. Dans cet article, je vais vous parler du recadrage de l’équipe.
L’équipe trimait depuis des semaines, soirs et parfois weekends. Sans raison apparente.
« Sans raison ? et 40% de dépassement c’est pas une bonne raison ? »
Lorsqu’une livraison est prévue dans une semaine, que vous êtes quasiment au bout, qu’il vous manque quelques jours pour finir et que la date de livraison ne peut être déplacée, pourquoi ne pas bosser le weekend (avec les coûts que ça génère) et quelques soirs dans la semaine. C’est justifiable.
Si vous faites travailler une équipe soirs et weekends pour rattraper un retard considérable (plus de 150 jours restant) mais sans objectif concrêt et proche dans le temps (livraison intermédiaire par exemple), vous allez fatiguer tout le monde au sens propre et au sens figuré … Vous devez ménager l’effort de chacun.
Prendre la température de l’équipe
Je me suis rendu sur place et j’y ai passé quelques jours. Je préconise toujours aux chefs de projets d’être nomades et mobiles aisément, donc tout sur l’ordinateur portable et zéro papier. Ca permet de bosser de n’importe où. Dans mon cas, ça me permettait d’observer comment fonctionnait l’équipe et d’apprendre à les connaître, tout en continuant à travailler sur mes autres projets en parallèle.
Quand j’ai rencontré l’équipe, elle était déjà épuisée. Ils avaient des valises sous les yeux, ils étaient tendus, sautaient des repas, … J’ai discuté un peu avec chacun pour prendre la température. Techniquement pas de problème apparemment, le problème se situait surtout au niveau de la méthodologie de travail.
Après avoir traité la communication client et repris un certain nombre de choses, j’ai rédigé 5 règles à l’attention de l’équipe en fonction de ce que j’avais observé.
J’ai imprimé le document pour chacun et j’ai réuni l’équipe dans une salle de réunion pendant 15-20 minutes pour le relire ensemble.
5 règles pour (re)-sensibiliser
★ Règle 0 : Il faut que ça marche !
Développer une fonctionnalité c’est bien mais au final ça doit marcher sinon elle ne sert à rien, on pourrait même dire qu’elle n’existe finalement pas. Vous allez trouver ça bête je sais. Pourquoi j’ai mis cette règle ? parce que je n’arrêtais pas d’entendre que des fonctionnalités étaient terminées mais qu’elles ne marchaient pas pour X ou X raison.
Le but était donc de sensibiliser sur l’objectif (que ça marche) et que chacun fasse attention à son vocabulaire : fonctionnalité terminée = ça fonctionne
★ Règle 1 : Au démarrage d’une tâche, les chiffrage et délai doivent être challengés puis tenus
C’est relativement explicite. L’idée c’est qu’ils se forcent à se poser la question avant de démarrer une nouvelle tâche. Je leur offre l’opportunité de ré-estimer une tâche pour leur redonner la responsabilité également de celle-ci. Car quand c’est quelqu’un d’autre qui vous impose le chiffrage, vous vous sentez généralement moins engagé. En échange, je demande à ce qu’ils tiennent ce chiffrage. Cela permet au final d’avoir de meilleures estimations de reste à faire.
★ Règle 2 : Une fonctionnalité terminée est une fonctionnalité sur laquelle on ne revient plus
Conforme, testée et intégrée. Là aussi c’est pour créer un cadre et marquer les étapes d’avancement car la tendance était à faire plusieurs choses à la fois sans vraiment avancer en se disant qu’on y reviendrait plus tard, faussant au passage les estimations de reste à faire.
★ Règle 3 : La correction doit suivre la logique en place
En cas de bug, souvent le développeur qui corrigeait le problème était différent du développeur qui avait développé à l’origine. Et très souvent, il en profitait pour redévelopper la fonctionnalité à sa sauce parce que ça lui convenait mieux, c’était plus élégant, plus propre, que sais-je encore ; avec, bien sûr, tout le temps que ça prenait et les risques de créer de nouvelles anomalies également.
Sauf que, quand vous avez un avion à prendre pour partir en vacances et que vous êtes en retard, vous ne passez pas l’aspirateur avant de partir, vous ne repassez vos chemises pour votre retour au travail, vous ne refaites pas non plus 3 fois votre sac de voyage. Et si vous avez oublié de vider votre frigo et que vous êtes à mi-chemin de l’aéroport, je doute que vous reveniez le vider exprès. Vous allez à l’essentiel pour prendre votre avion. Pour le reste, tant pis.
L’idée était donc de re-sensibiliser à l’urgence en place, urgence en délai et en budget …
★ Règle 4 : Chacun est responsable de ses tâches, aider les autres oui, à condition d’avoir fini les siennes
Si je garde le même exemple, vous partez en vacances avec des amis et votre avion décolle bientôt. Vous n’allez pas aider les autres à finir leurs bagages si vous n’avez pas déjà fini les vôtres. Ca paraît logique non ? Ou alors vous êtes prêt à prendre le risque que les autres partent sans vous parce que vous en retard ..
Alors bien sûr s’il s’agit d’un coup de pouce de 5 minutes, ça ne s’applique pas. Dans mon contexte, je voyais souvent une personne de l’équipe prendre sa chaise et se mettre à côté d’un autre membre et travailler ensemble pendant une heure, deux heures, trois heures sur un problème. En me disant à la fin de la journée qu’elle n’avait pas pu finir parce qu’elle a aidé telle autre personne.
L’idée ici est également d’inciter la personne qui a un problème, à l’isoler, à identifier le point précis où ça ne fonctionne pas et à demander de l’aide à ce moment-là. Pas avant !
Si votre lampe ne s’allume pas, vous ne faites pas directement appel à l’électricien. Vous vérifiez le branchement sur la prise, l’interrupteur, l’ampoule, vous changez de prise, vous changez de pièce, etc. Vous faites appel à l’expert une fois que vous avez isolé le problème.
Chaque contexte est différent

Bon, 5 règles écrites sur une feuille A4, c’est un peu réducteur, vu comme ça. C’est difficile de résumer en un article tout ce qui s’est passé mais ça peut donner des idées pour votre projet.
J’ai fait comme cela sur celui-ci et j’ai fait différemment sur d’autres. En tant que chef de projet, vous devez vous adapter au contexte bien évidemment et pour cela il faut observer, surtout si comme moi, vous ne connaissez pas le projet, pas les technologies, pas le client, pas les membres de l’équipe ..
Ce ne sont donc pas des règles absolues et il y avait des exceptions. Mais l’idée générale était de redonner une structure au travail, de redonner des habitudes plus efficaces et de re-sensibiliser chacun à l’objectif global. C’est un investissement en temps de reprendre une équipe et cela porte généralement ses fruits au bout d’un ou deux projets ensuite, rarement dans les 3 jours suivant votre arrivée. Mais sait-on jamais, vous allez retomber peut-être sur les mêmes personnes dans un ou deux projets alors autant qu’elles aient déjà de bonnes habitudes !
J’ai encore le document que je leur avais transmis, j’avais mis une touche d’humour (très personnelle … c’est à valider en amont que ça passe bien avec l’équipe) à la fin pour décrisper un peu la situation malgré l’importance des règles. je vous laisse y jeter un oeil si cela vous intéresse.
Cliquez ici pour télécharger le fichier PDF
Et vous ? qu’avez-vous rencontré comme « mauvaises » habitudes de travail pour une équipe ?
Si vous avez des difficultés avec les boutons de partage (ou que vous n’avez aucun compte sur ces réseaux sociaux), laissez-moi un commentaire et vous pourrez télécharger le document.
Bonjour,
merci beaucoup de vos efforts pour partager cette attitude avec la communauté.
En tant que responsable PMO, je suis très intéressé par votre lettre de cadrage.
D’avance, MERCI.
Très cordialement,
Georges ANDONI
Bonjour,
Je n’ai pas pu récupérer ce document. Article intéressant au demeurant prouvant oh combien la motivation d’une équipe est le facteur clef de la réussite d’un projet.
N’arrive a à accéder au pdf. Est-il possible de me l’envoyer en direct ?
Merci d’avance
Bonjour,
Article interessant.
Je suis preneur du document svp …
Merci d’avance
samuel
Tout a fait d’accord, instaurer des bonnes pratiques de travail dans l’équipe prend du temps mais cela fait une grande différence.
Pilar
Tout a fait d’accord, instaurer de bonnes pratiques de travail dans l’équipe prend du temps mais cela peut faire aussi toute la différence.
Pilar
Bonjour
Je n’ai pas pu récupérer votre document
pourriez vous me faire parvenir ce document
Cordialement
J’ai partagé sur Facebook… mais je n’ai rien pu recevoir !
Merci d’avance de l’envoi
L. Mion
Bonjour,
Très intéressant! même si cela paraît presque ‘évident’ il est assez difficile d’avoir cette ‘simplicité’ lors d’une situation de crise.
Je serais preneur de votre document SVP.
Merci d’avance.
Merci de me l’envoyer par mail.
Christine
Aller à l’essentiel et ne pas se faire plaisir différemment, problématique bien humaine qui montre le besoin que chacun s’approprie les objectifs du projet et pas seulement ceux qui lui apportent une satisfaction personnelle (better code…)
Merci de me faire passer cette fameuse lettre.
Cordialement,
Bonjour,je suis intéressée par votre document, mais je n’ai pas pu le récupérer .Pourriez vous me le faire parvenir ?
Je vous remercie,
CS
Bonjour,
Impossible de récupérer votre fiche.
Pouvez vous me l’adresser par mail.
Merci d’avance.
Bien cordialement
c’est très intéressant ce que vous avez mis ici. un grand merci
Merci à vous car nous ne cesserons de vous consulter.
Bonjour
Et merci pour cette mine d’informations et de conseils.
Je ne suis pas sur les réseaux sociaux, mais je suis intéressé par votre lettre de recadrage.
D’avance merci.
Cordialement
Gilles MICHELS
L’Européenne d’Embouteillage
84 Chateauneuf de Gadagne
France
Bonjour je serai interessé par votre lettre de recadrage aytant un future manager du équipe .
cordialement .
MR LALOUE JEROME
Bonjour,
J’ai twitté mais pas de document en vue 🙁
Bonjour,
votre adresse email n’existe apparemment pas …
JP
je suis intéressé par votre lettre de recadrage
Bonjour,
Etant ex-développeur, je faisais certains de ces mauvaises habitudes mais aucun chef projet malin m’a cadré avec telles règles en argumentant fort : ça me plait l’exemple d’avion ! Bravo Jean-Philippe 🙂
Cordialement,
Salah
Bonjour Salah,
J’aime beaucoup utiliser des exemples ou des analogies, je trouve que ça aide à prendre du recul !
JP
Bonjour,
article intéressant, montrant bien la complexité (humaine avant tout) de la fonction de chef de projet et qu’elle nécessite en particulier recul et pragmatisme.
Cordialement.
P.-S. — Je suis intéressé pour l’envoi du PDF qui n’a pas fonctionné dans mon cas (sur Safari Mac et demandé via Twitter).
Bonjour,
Merci pour ce retour.
Je suis intéressé par votre note de cadrage, si vous voulez bien me l’envoyer.
Bon courage pour la suite.
Vincent
Bonjour,
Ai pas pu récupérer ce document.
P.-S. — Je suis intéressé pour l’envoi du PDF qui n’a pas fonctionné dans mon cas
cordialement
Mnkr
Bonjour,
comme bien des lecteurs vous suivant, je n’ai pas réussi a récupérer le PDF…
je suis curieuse, je veux lire la touche d’humour … ^^
merci d’avance
Bonjour,
Je souhaite moi aussi recevoir la lettre de cadrage !
J’ai été propulsée assistante chef de projet il y a peu, en récompense de mon engagement dans ce projet, mais je n’ai jamais été formée à ce genre de tâches … Je prends donc les aides que je peux trouver.
Merci d’avance
Bonjour
Je suis moi aussi intéressée par votre lettre.
Merci bcp
Instaurer des bonnes pratiques prend du temps, avoir une équipe encore plus !!!
JP, je n’ai pas pu récupérer votre document pourriez vous me faire parvenir ce document, merci.
Bonjour,
j’ai cliqué sur un des partage réseau social, mais je n’accède pas à votre lettre, pouvez-vous me l’envoyer svp ?
Merci par avance.
Bonjour,
La fonctionnalité n’a pas été très effective en ce qui me concerne 😉
Je serai également intéressé par votre exemple de lettre.
Merci beaucoup!
Thomas
Bonjour Jean-Philippe,
Merci de partager ton expérience et tes idées, je serai intéressée par le document pdf car je souhaite mettre cette méthode en application avec mon équipe.
Merci d’avance pour ton envoi.
Schéhérazade
Bonjour Jean-Philippe,
J’ai partagé, mais n’ai pas trouvé le lien pdf…
Si tu peux m’envoyer le document ce serait sympa.
Michel
Responsable technique d’un gros bouzin, et au final chef de projet bis, je serais également intéressé par la lettre de cadrage.
Merci d’avance,
François
Bonjour,
Serait-il possible de me faire parvenir votre lettre.
merci d’avance
Matthieu
Bonjour,
Merci pour cet article.
Pourriez-vous , s’il vous plaît, me faire parvenir votre lettre de recadrage ?
Frédéric.
Bonjour,
Merci pour votre retour d’expérience. Les règles de la charte sont dans le même esprit que ce que l’on trouve dans la philosophie SCRUM.
N’ayant pas pu récupérer le PDF pourriez-vous me le communiquer par e-mail SVP.
Cordialement,
Bonsoir,
clic Google validé mais pas de fichier pdf proposé.
Merci de revenir vers moi.
Slts
Bonjour
N’ayant pas pu récupérer le PDF pourriez-vous me le communiquer par e-mail ?
En vous en remerciant par avance
Bien cordialement
bonjour
très intéressant votre site, je suis preneur du fichier pdf proposé pour sensibiliser les chefs de projets avec qui je travaille
Merci d’avance
Merci pour ce bon article.
Intéressé par le PDF. Merci
des reles comme ça nous en avo s vraiment besoin au quotidiem.
Merci pour le conseil
je suis preneur de votre PDF Merci par avance