10 leçons tirées de mes pires expériences en gestion de projet

Table des matières

Quand je regarde mes expériences passées en pilotage de projet, je me dis : « Fiuuuu, ça a pas été de tout repos mon loulou. Et des erreurs t’en as fait quelques unes quand même »

J’ai eu mon lot de projets conflictuels, de crises à gérer, d’incendies à éteindre. Ce n’était pas de tout repos. Particulièrement lorsqu’un projet majeur s’est mis à partir en vrille. ça m’a mangé 1 an et demi de ma vie.

Honnêtement, cette période était vraiment compliquée. Mais comme on dit, il y a toujours du positif à tirer, même des pires situations.

Je vous livre donc les 10 leçons que j’ai appris de mes erreurs et de mes échecs. Et je vous encourage vivement à mettre en place ces conseils pour que vous puisiez éviter de tomber dans les pièges dans lesquels moi je suis tombé.

10 leçons tirées de mes erreurs en gestion de projet

1 ) Le client n’est pas le roi. Fixez des limites

Cette leçon, je l’ai appris à la dure, avec un client qui changeait d’avis comme de chemise, et nous reprochait tous les jours à 08h du matin de ne pas comprendre ce qu’il souhaite et d’accumuler du retard.

Je peux vous dire que plus d’une fois j’ai eu envie de le rembarrer. Mais je n’ai pas osé. Et j’aurais dû mettre les points sur les i, car la relation s’est empirée par la suite, et le projet avec.

On va être clair sur le sujet : Agile ou pas, changer d’avis et de priorité tous les jours c’est le meilleur moyen pour planter le projet, démotiver l’équipe projet et faire fuir les talents.

Le client n’est pas le roi. C’est à vous de fixer des limites, en tant que chef de projet. Ou de les lui rappeler. Alors oui, bien sûr que le besoin client peut évoluer, bien sûr que le périmètre du projet peut être revu. Mais pas tous les jours. Pas toutes les heures. Et pas n’importe comment.

2 ) Rédigez toujours les compte-rendu, même quand vous manquez de temps

Vous sortez d’un comité de pilotage projet, pour enchaîner sur d’autres réunions et point de synchronisation avec l’équipe projet et les parties prenantes. Résultat ? Vous zappez de rédiger les comptes-rendu. parce que ça vous demande trop de temps. Et que de toute façon ça ne sert pas à grand chose.

Cette erreur, je l’ai fait, exactement pour les mêmes raisons. Et ça a été la plus grosse boulette sur ce projet. La situation est rapidement devenue conflictuelle. Le client a changé totalement sa vision des choses et son besoin, ce qui a remis en cause la migration informatique telle qu’on lui avait vendu.

Je me suis retrouvé du jour au lendemain avec une infrastructure informatique à moitié migrée (donc bancale, et deux directions qui s’affrontent par avocats interposés. 

Le problème, c’est que j’avais zappé la rédaction du compte-rendu de réunion qui était probablement le plus important. Sans ça, je ne pouvais pas justifier que le client avait dit A avant de revenir sur sa décision pour dire B.

J’ai pensé gagner du temps en zappant ce compte-rendu. Au final, le combat a duré 1 an et demi pour faire entendre raison au client et enfin être payé… Tout ça pour un compte-rendu qui m’aurait pris 30 minutes à rédiger. Vous voyez le problème…

3 ) Ne faites jamais une action « à la place de », même si ça sauve le projet

ça y est, le planning détaillé est enfin sorti, toutes les tâches sont listées, on sait qui doit faire quoi, quand et comment. J’organise une réunion d’équipe pour le présenter, rappeler à chacun ce qu’il doit faire et quelles sont les implications sur le travail des autres s’ils n’arrivent pas terminer le travail à temps.

Sur le papier tout le monde sait ce qu’il a à faire et repart de la réunion d’équipe avec sa liste de tâches. Une affaire rondement menée, me direz-vous !

Et bien, pas si sûr… Car quelques jours plus tard, je me rends compte que même si l’ingénieur système de l’équipe avait pris un engagement sur la réalisation de ses tâches, il a travaillé pour d’autres clients et n’a pas avancé d’un iota sur mon projet. Problème : sans ses actions, le reste du projet était bloqué.

J’ai donc dû me résigner à faire les actions « à la place de » pour éviter de mettre en péril le projet.

Laissez-moi vous expliquer pourquoi c’est un gros souci :

  • Déjà parce que vous vous ajoutez des tâches à un calendrier déjà bien rempli.
    Je pense que vous n’avez pas envie de finir tous les jours à 21h ou d’exploser en plein vol et de faire un burnout.
  • Deuxio, en réalisant ces tâches, vous en prenez la responsabilité.
    Même si vous avez les connaissances et l’expérience pour cela, si vous vous lancez là-dedans, ce sera au détriment de votre pilotage projet. Vous tomberez dans l’opérationnel et perdrez la vision d’ensemble du projet.
  • Tertio, cela ne responsabilise absolument pas les collaborateurs.
    « Pourquoi est-ce que je ferais ce sur quoi je me suis engagé, puisque de toute façon Thibault est là pour rattraper le tir ? » Vous voyez la logique ? 

Si vous vous retrouvez dans cette situation, voici mon conseil : Ne faites pas « à la place de ».

Rappelez à cette personne les engagements pris. Rappelez lui les impacts de sa décision pour le travail des autres personnes et pour le projet (retard, coûts supplémentaires, pénalités à payer au client, etc).

Et si malgré cela, cette personne ne fait pas ce qui est attendu, laissez-là prendre ses responsabilités et en accepter les conséquences derrière.

4 ) Peaufinez votre préparation projet

La préparation, c’est la clé de la réussite d’un projet. Foncer tête baissée, c’est le meilleur moyen d’aller droit dans le mur.

On a tous tendance à vouloir aller vite, et à bâcler la phase de préparation pour passer à la mise en œuvre du projet et ainsi respect les coûts et les délais du projet. je le sais, je l’ai fait aussi.

Grave erreur !

Car vous pouvez passer à côté de plein de choses : risques non identifiés, difficultés techniques et imprévus, etc. Peut-être même que le plan d’action que vous avez choisi n’est pas le meilleur, pas le plus adapté et le plus rapide. 

Généralement, les projets où la phase de préparation est rapidement expédiée se terminent dans la douleur et les larmes. Ce n’est d’ailleurs pas rare d’entendre ensuite en cours de projet : « De toute façon, ce projet doit être drivé par les délais et les plannings, pas par la qualité ».

Si si, je vous assure, j’ai réellement entendu ça…

Alors oui, on a livré dans les temps. Mais du caca reste du caca. Et comme la qualité était en berne, le client n’était pas du tout (mais vraiment pas du tout) satisfait. Bah oui, forcément.

Mon conseil ?

Travaillez notamment les plannings, et si vous vous rendez compte que vous êtes sur le chemin critique et que le moindre écart peut vous faire faire une sortie de route, alors c’est probablement le signe qu’il faut négocier avec le commanditaire pour rallonger un peu le délai.

5 ) Ne faites aucun traitement de faveur

Un chef de projet est un manager. Et à ce titre, il doit être exemplaire et faire attention à sa manière d’interagir avec l’équipe. Et ça, je ne l’ai compris qu’après mon premier projet.

J’étais en mission à Dunkerque pour réaliser une migration de parc informatique, j’avais avec moi une équipe de technicien, et on est resté là-bas 1 bon mois, le temps de tout réaliser.

j’étais jeune et innocent à ce moment-là, et je cherchais avant tout à sympathiser avec mes collègues, histoire d’avoir une bonne ambiance de travail. Le truc, c’est que je n’ai pas réussi à embarquer toute l’équipe et très rapidement il s’est créé deux clans, qui ont commencé à mutuellement critiquer le travail des autres voir à les accuser.

Avec le recul, c’est entièrement ma faute. Je me suis laissé porté par mes affinités personnelles, j’ai commencer à dîner plus souvent avec certains que d’autres, ce qui m’a amené à moins échanger avec certaines personnes au travail. Le groupe a rapidement mis de côté les outsiders, et je me suis retrouvé avec 2 clans en pleine guerre civile sur les bras.

Moi qui voulait une bonne ambiance de travail sur ce premier projet, j’ai été servi !

Faire ami-ami avec certaines personnes paraît plutôt logique : on le fait tous au travail. C’est une question d’affinité. Oui mais voilà : un chef de projet doit faire en sorte de souder l’équipe et de la fédérer autour d’un objectif commun.

Vous avez donc un devoir de réserve, comme les managers.

Et si vos collègues ne savent pas faire la différence entre ce qui se passe au boulot et ce qui se passe en dehors, alors le mieux reste de poser des limites bien précises, et de montrer que vous êtes là pour l’équipe, sans favoritisme.

6 ) Impliquez régulièrement le client et les utilisateurs finaux dans le projet

Même si je ne suis pas développeur à la base, j’ai pu piloter quelques projets de développement informatique. Et cela a été très instructif. Même si ça ne s’est pas vraiment bien passé.

Le développement accumulait du retard, le planning communiqué au client n’était pas respecté, et au bout de 6 mois, les développeurs ont enfin eu quelque chose à montrer au client.

Showtime baby ! C’est parti pour la démo.

Résultat ? Le produit développé ne répondait absolument pas au besoin du client, qui a commencé à s’énerver.

« A quoi ça sert de faire des spécifications techniques si vous n’en faites qu’à votre tête derrière ? Vous n’avez rien compris à ce que j’ai demandé. Ce n’est pas du tout ça. »

Pourtant on aurait pu éviter cet écueil. Vous savez comment ? En impliquant le client régulièrement dans le développement. En lui montrant des démos plusieurs fois par mois pour recueillir son feedback.

On aurait pu éviter d’attendre 6 mois pour se rendre compte qu’on a fait fausse route.

Ne pas impliquer le client dans le projet, c’est synonyme d’un projet voué à l’échec.

Mon conseil ? Privilégiez les cycles courts comme le décrit le manifeste agile, et n’attendez pas 6 mois ou plus pour montrer le résultat de votre travail à votre client. 

Vous récupérerez ainsi un feedback précieux qui vous permettra d’améliorer le produit et/ou de rectifier le tir avant qu’il ne soit trop tard.

7 ) Assurez-vous que tout le monde parle le même langage

 Sur un projet de développement informatique (développement de l’application d’un côté, et déploiement de cette application de l’autre), je me suis retrouvé à jouer les négociateurs traducteurs.

D’un côté, les développeurs, ces « geeks » qui alignent des lignes de code à longueur de journée. De l’autre, les administrateurs système, qui adorent bidouiller dans les serveurs mais sont allergiques au code.

Vous voyez venir le problème ? Chacun parle son langage, personne ne se comprend.

Les admins systèmes accusent les développeurs de fournir des procédures incomplètes et du code qui ne fonctionne pas.

Les développeurs ne comprennent pas pourquoi les admins systèmes mettent autant de mauvaise foi à réaliser leurs actions. C’est pourtant simple.

Et moi, au milieu, à compter les points.

Après des semaines à avoir essayé de jouer les négociateurs, j’ai fini par adopter une mesure plus extrême : j’ai pris les leaders de chaque équipe, je les ai mis dans une salle de réunion avec moi, avec un mot d’ordre simple : vous ne partirez pas de cette salle tant que vous ne vous serez pas compris et que vous ne serez pas d’accord.

Ce problème n’arrive pas qu’en informatique. Il suffit de mettre un profil expert en face d’un client qui n’y pipe rien pour observer un dialogue de sourd.

Assurez-vous toujours que tout le monde parle le même langage. Demandez des précisions, encouragez les autres à poser des questions, faites un tour de table pour vous assurer que tout est clair pour tout le monde.

8 ) Apprenez à lâcher prise, même dans les moments de crise

 Aucun travail n’est plus important que votre bien-être. 

ça vous paraît peut-être évident, mais je l’ai appris à la dure, dans les tranchées.

Un projet de 4 mois qui s’étale sur 1 an et demi, avec des départs à répétition, des conflits latents, de la politique, et des combats entre avocats par lettres recommandées interposées, ça vous change un homme…

Vous vous en doutez, je gérais situation de crise sur situation de crise chaque jour. Tout était important, prioritaire, les tâches commençaient à s’empiler, et je ne voyais à l’époque que deux options :

  • Faire mes 35 heures et laisser partir le projet en vrille.
  • Ne plus compter mes heures pour essayer de sauver le projet.

J’ai choisi la seconde option, comme la plupart d’entre vous. Et je me suis retrouvé à travailler de 08h du matin à minuit. Je mangeais devant mon écran, et je ne me déconnectais que quand mes yeux étaient tellement secs que je ne supportais plus l’écran.

Dans mon lit, je rêvais de mon projet. Et je me réveillais tant bien que mal à 07h55 pour prendre un café avant de me connecter sur le point quotidien de 08 heures avec le client.

Dur ! Je n’avais plus de vie. Littéralement.

Et ça n’a pas aidé le projet à se remettre sur les rails.

En fait, avec le recul, je me rends compte que la situation aurait été la même si j’avais fait beaucoup moins d’heures. J’ai travaillé dans le vide, mais j’ai grignoté sur ma santé, mon sommeil, mon temps personnel.

ça m’a servi de leçon ! 🙂

Peu importe la criticité de la situation dans laquelle vous vous trouvez, prenez cinq minutes pour souffler, prendre un peu de hauteur et analyser la situation. 

Vous vous rendrez compte que ce qu’on prend pour critique est en fait rarement le cas. 

Fixez-vous des limites à ne pas dépasser, crise ou pas crise. Prenez du temps pour vous, pour votre famille et pour vos loisirs. Ne négligez pas votre temps de sommeil, et apprenez à lâcher prise.

9 ) Arrêtez d’essayer de tout contrôler et de tout micro-gérer

La micro-gestion tue l’innovation et la créativité de votre équipe projet.

Voilà, c’est dit.

Lorsqu’on m’a confié mon premier projet, j’ai voulu montrer que j’en étais capable, que j’étais digne de la tâche qu’on m’a confié.

Alors j’ai voulu tout prévoir, et tout gérer. AU détriment de l’équipe.

Rapidement, on m’a reproché d’être un « control freak », de ne pas savoir faire confiance, de vouloir tout faire et tout gérer à la place des autres.

L’équipe s’est braquée contre moi et les collaborateurs se sont activement désengagés.

« Après tout, puisque Thibault veut tout faire à notre place et que ce qu’on fait n’est pas assez bien, laissons-le faire. »

J’ai pu mener au bout ce projet, mais ça s’est fait dans la douleur. J’ai voulu tout contrôler, tout micro-gérer.

J’ai compris mon erreur. J’aurais dû expliquer les objectifs à atteindre, donner le cap, et faire confiance à mon équipe. J’aurais dû les laisser faire ce qu’ils savent faire le mieux, et me cantonner à programmer des points d’avancement avec eux pour suivre l’avancée du projet.

Peu importe l’énergie dépensée, vous ne pouvez pas tout contrôler. C’est impossible. 

Rappelez-vous que vous êtes chef de projet, et pas expert technique. Il y a des personnes bien mieux placées que vous pour réalisez les tâches du projet, avec une plus grande expérience, une meilleure expertise, et qui le feront en moins de temps que vous.

Si vous souhaitez vraiment suivre l’état d’avancement de votre projet, maintenez à tout prix une vision d’ensemble, ne rentrez pas dans les détails, donc évitez la micro-gestion.

10 ) Tenez à tout prix les engagements pris

« Promis, je vous envoie le compte-rendu de réunion sans faute d’ici ce soir. »

Arggggh! Encore un engagement pris sans réfléchir en comité de pilotage, que je n’arriverais pas à tenir.

ça vous parle sûrement. En tout cas, ça a été mon quotidien pendant de nombreuses années.

Je pensais bien faire, je me disais que cela rassurait le client de savoir que j’allais être réactif face à ses demandes.

Mais en fait, ce n’est pas ce qu’il demandait. Ce que le client souhaitait c’est que les choses avancent. Qu’on s’engage sur ce que l’on dise. Et que l’on respecte nos engagements.

Au final, s’engager sur quelque chose que l’on sait ne pas pouvoir tenir, c’est perdre la confiance et la crédibilité que le client nous avait accordé.

Quand j’ai compris ça, j’ai fait un grand pas en avant sur la gestion de projet.

Tenez vos engagements à tout prix. Et ne prenez pas d’engagements à la légère.

Simple à dire, difficile à tenir. Au détour d’une discussion ou d’une réunion, on peut vite se laisser avoir.

Mon conseil ? Fixez avec le client en début de projet des délais acceptables pour l’envoi de documents, de comptes-rendus, ou encore pour revenir vers lui lors de l’ajout de fonctionnalités au périmètre du projet.

Pour aller + loin : Voici la liste des 19 plus grands défis de la gestion de projet, et la manière de les résoudre. Consultez l’article pour en savoir +.

Image de Thibault Baheux

Thibault Baheux

Tour à tour chef de projet puis manager d'équipe depuis 2008, je suis aujourd'hui directeur de projet indépendant. J'ai décidé via ce site de démocratiser la gestion de projets et de la rendre accessible à tous. Mes certifications : Prince2 Foundation, CompTIA Project+ certified, PSM1, PSPO1, Lean Six Sigma Black Belt.

Devenez un chef de projet performant

Et recevez dans votre boîte mail un exemplaire du guide « 15 facteurs-clés pour réussir vos projets ».

Ce guide est un condensé de conseils pratiques, tirés de mes 14 années d’expérience en pilotage de projets.