Manager son équipe : recadrage sur un projet en crise

Tableau suivi projetReprendre 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.

couple-aeroportSauf 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

forfaitpourlesnuls
Voir ci-dessous pour télécharger le document

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 ?

65 réflexions au sujet de “Manager son équipe : recadrage sur un projet en crise”

  1. Article très intéressant! Encore plus appréciable lorsque vous précisez « surtout si comme moi, vous ne connaissez pas le projet, pas les technologies, pas le client, pas les membres de l’équipe… », ce qui me prouve un peu plus chaque jour qu’un consultant tech’ ne fait pas souvent un bon chef de projet!

    Répondre
  2. merci pour cet artcile très interessant, pourriez-vous me faire parvenir le pdf par e-mail?
    Merci d’avance
    Cordialement
    Khadija

    Répondre

Répondre à JP Annuler la réponse