- Speaker #0
Focus Projet
- Speaker #1
Bienvenue sur Focus Projet, le podcast du management de projet. Le management de projet, qu'est-ce que c'est ? Ça va être les différentes techniques et outils qui vont nous permettre de mener à bien nos projets. Planning, coût, risque, gestion d'équipe, changement, communication, définition du besoin. Au fil des épisodes, on va voir tout cela ensemble. Alors que tu sois le directeur de projet de la prochaine Gigafactory ou que tu te retrouves à t'occuper des projets de ton entreprise en plus de ton travail, abonne-toi. Ce podcast va simplifier la réussite de tes projets. Lorsqu'on part de zéro, mettre en place le management par projet au sein de sa structure est un challenge. On ne sait pas forcément par où commencer pour que ces équipes adoptent progressivement cette manière de travailler. Quels sont les sujets prioritaires sur lesquels se focaliser pour faire monter en compétence les équipes et faire adopter les nouvelles pratiques nécessaires à la bonne gestion des projets ? Pour en discuter aujourd'hui, je reçois Renaud Chaunet. Bonjour Renaud, comment ça va ?
- Speaker #0
Bonjour Tanguy.
- Speaker #1
Tu peux peut-être commencer par te présenter ?
- Speaker #0
Oui, je suis Renaud Chaunet, je suis fondateur de la société Time Performance qui propose un logiciel SaaS de gestion de portefeuille de projet. On est vraiment dans le thème, sachant qu'en effet, dans la partie gestion de portefeuille de projet, on intègre la gestion de projet, mais aussi le hors-projet, la gestion des ressources. J'ai créé cet outil-là parce que je me suis aperçu Beaucoup de gens utilisaient Excel pour gérer leurs projets et ça va quand c'est simple, mais très rapidement on envoie ses limites. Donc l'objectif c'est de proposer un outil qui soit simple, qui ne soit pas une usine à gaz, mais qui quand même apporte une vraie solution plutôt que de se déployer avec Excel.
- Speaker #1
Quelles sont les difficultés à rencontrer quand on souhaite mettre en place un processus de gestion par projet ?
- Speaker #0
C'est une très très bonne question parce que je pense que tout le monde la rencontre, surtout quand on est en début de carrière. Alors déjà, pourquoi on veut mettre en place un processus de gestion par projet, voire même une gestion de projet ? C'est bon de le rappeler parce que ce n'est pas du tout évident. C'est-à-dire que tout le monde fait de la gestion de projet. Je ne suis pas sûr qu'on soit tous d'accord sur ce que c'est qu'un projet. C'est tout bête, hein ? Et en fait, c'est là le cœur du problème. parce que avant de mettre en place la gestion de quelque chose il faut savoir de quoi on parle et moi dans mon expérience et surtout avec mon expérience où j'accompagne beaucoup de sociétés dans la mise en place d'un outil de gestion de projet de gestion de projet on se rend compte que dans les structures il y a différents types de projets et avec différentes problématiques et que forcément derrière il ne faut pas les mêmes outils et pas les mêmes processus, il faut les adapter vous avez des tout petits projets et puis vous avez des projets qui sont très très gros et donc de parler de la gestion de projet
- Speaker #1
c'est très très vague et c'est très dangereux de vouloir imposer une seule chose il faut peut-être plutôt parler de la gestion des projets d'une manière plus générale plutôt que la gestion de projet moi je dirais même les gestions de projet un peu plus loin les gestions de projet alors
- Speaker #0
moi déjà dans le terme projet je prends le terme la définition du PMI mais qui est beaucoup plus générale que ce que les gens ont compris c'est à dire que dans le PMI il y a des Qu'est-ce qu'un projet ? Un projet, c'est une entreprise temporaire dans le but de créer un produit et un service unique. Donc, grosso modo, un projet, c'est tout ce que l'on fait qu'on ne fait pas d'habitude. Donc, en fait, il y a le projet et le récurrent, le hors-projet. Et tout ça rentre dans un projet. Alors après, pourquoi je dis que j'ai un sens qui est beaucoup plus général ? C'est que quand les gens entendent entreprise temporaire, ils s'imaginent qu'un projet, ça doit forcément avoir un budget fixe, un scope fixe. une date fixe, une date terminée. Non, non, ce n'est pas le cas. Moi, je prends le projet dans le terme courant que l'on utilise, c'est-à-dire, par exemple, une entreprise a le projet de lancer une nouvelle offre. Eh bien, le projet, quand le projet démarre, on ne sait pas quand est-ce que l'offre va être lancée, à quelle date, etc. Donc, c'est très, très grave.
- Speaker #1
C'est le cas de tous les projets. Quand on démarre, on ne sait pas, à moins d'avoir réellement des contraintes précises. Je ne sais pas, je prends par exemple, un exemple qui vient bien, c'est les JO, où on sait qu'à telle date, il faut que tout soit prêt. Dans les autres cas... Quand on est marre, on ne sait pas forcément ce qu'on va faire et le temps que ça va prendre.
- Speaker #0
Exactement. Et donc, il y a plein de projets comme ça. Mais tu trouveras plein de gens qui sont des détracteurs, notamment de la gestion de projet, qui diront oui, nommer un projet, ça doit avoir une date fixe, etc. Mais dans la vie réelle, ce n'est jamais comme ça. Non, en fait, projet, c'est le terme général. Et donc, la question, c'est de se dire maintenant les entreprises, pourquoi mettre en place un processus de gestion ? Quand tu dis par projet, c'est déjà un signe, parce que quand on dit gestion de projet, par projet, il y a déjà quelque chose là. Mais disons, pourquoi le faire ? Tout simplement parce qu'aujourd'hui, les entreprises sont amenées à s'adapter en permanence. Les technologies évoluent vite, les réglementations... évolue très vite. Et donc, en permanence, il faut innover, il faut créer des nouvelles choses. Et donc, aujourd'hui, les entreprises sont débordées par le nombre de projets. Évidemment, on peut faire des projets sans les gérer. mais c'est très casse gueule c'est très dangereux je dirais pour les entreprises surtout au niveau de l'entreprise ça marche moins bien en général c'est à dire qu'en fait justement c'est là que c'est intéressant de revenir un peu au rôle quel est le rôle d'un chef de projet je dirais c'est un peu comme un chef d'orchestre en fait on peut jouer de la musique sans chef d'orchestre d'accord ça marche très bien à 2 ou 3 on a un groupe de musicos dans sa cave on a pas besoin de chef d'orchestre mais quand on est 60 ou 80 ça commence à devenir beaucoup plus compliqué son chef d'orchestre. Pourtant, le chef d'orchestre, justement, en fait, c'est le métier de la gestion de projet, les gens comprennent mal, c'est que chef de projet, ce n'est pas quelqu'un qui réalise le projet. Lui, il fait tout le reste, c'est-à-dire, il s'occupe de l'organisation du projet qui n'est pas en réalisation. Le chef d'orchestre, il ne joue pas de la musique. Donc, à la limite, on pourrait dire, mais finalement, il ne sert à rien. Nous, on veut entendre que c'est de la musique, ça ne sert à rien. Si on met un chef d'orchestre, c'est parce qu'on sait très bien que ça se passe mieux quand il est là. La musique est plus jolie quand il est là que quand il n'est pas là. Et maintenant, le chef de projet, c'est la même chose. Et c'est pour ça aussi, cette raison que le chef de projet n'est pas quelqu'un qui réalise, c'est pour ça qu'aujourd'hui, il y a pas mal, surtout dans l'informatique, chez les développeurs, les chefs de projet, ça ne sert à rien. La gestion de projet, ça ne sert à rien. Parce qu'en fait, ça ne fait pas avancer le projet. Oui, voilà. En fait, il y a un travail de fond. Quand la gestion de projet est bien faite, ça ne se voit pas que ça a été bien fait. c'est quand il n'y en a pas que là il y a plein de problèmes de tous les côtés et qu'on se dit ah ben finalement on aurait peut-être bien fait d'avoir quelqu'un qui anticipe et qui empêche tous ces problèmes d'arriver voilà c'est ça la gestion de projet et ça c'est dans tous les types de projet
- Speaker #1
Comment procéder du coup pour le mettre en place ?
- Speaker #0
Comment procéder ? C'est vrai que ce n'est pas simple. C'est vrai qu'il existe dans la littérature un tas de méthodologies de gestion de projet qui sont très bien documentées parce que des projets, on en fait depuis très longtemps et finalement, les choses n'ont assez que changé. Il faut réaliser des choses avec des moyens, avec des compétences, des choses comme ça. Donc ça, ça a assez peu changé. Donc les méthodologies existent. Moi, celle que j'ai le plus étudiée… c'est celle du PMI, le PMBOK, le Project Management Book of Knowledge, qui est plus un référentiel méthodologique, qui va faire la liste de toutes les techniques que l'on peut avoir en termes de gestion de produits. Ça, c'est la plus connue quand on suit une certification, généralement c'est une certification PMI. Moi, il y a une autre méthode qui est plus méthode, pour le coup, qui est moins référentielle, et quelque chose d'assez intéressant, c'est Prince2. Prince2 parce que déjà c'est plus adapté au domaine que je maîtrise le mieux, c'est-à-dire tout ce qui est informatique et IT. Et puis il y en a une autre qui s'appelle le CMMI. Ce n'est pas une méthode de gestion de projet, c'était pour évaluer la maturité des entreprises en termes de gestion de projet. Je trouve que cette approche est très intéressante. et toutes ces méthodologies sont super intéressantes donc on peut se former à ça avoir cette culture là, c'est très complet je dirais même que quelque part c'est un peu séduisant intellectuellement on se fait un peu plaisir on pense que du coup c'est génial on va pouvoir tout organiser comme ça et puis ça donne un guide ça permet de savoir tout ce qu'il y a à faire alors le gros inconvénient de ces méthodes de ces approches c'est que d'abord ça a été conçu pour les gros projets. En fait, ce sont les gens qui avaient la problématique sur les gros projets qu'on dit, bon, maintenant, il nous faut une méthode, il faut qu'on définisse un certain nombre de choses et qu'on les mette en place parce que nos projets, là, on ne peut plus les gérer comme ça. Du coup, elles sont difficiles à mettre en œuvre. Évidemment, si vous avez un formateur, tous vont vous dire, oui, oui, non, mais la méthode, elle est complète, mais vous pouvez l'adapter à votre besoin. Et là, moi, je dis, mais oui, sauf que ça ne marche pas comme ça. parce que si vous démarrez vous ne connaissez pas la méthode vous n'allez pas commencer par adapter une méthode que l'on ne connait pas donc ça devient très difficile pour quelqu'un qui démarre de rentrer avec ces méthodes qui sont très riches je ne sais plus dans le PMBOK, dans le référentiel il y a 9 processus 40 activités 10 processus je crois après ça a été un peu simplifié je crois avec la dernière version il y a de quoi submerger n'importe quel chef de projet débutant toutes ces méthodes sont assez intéressantes, maintenant ça, ça existe, mais par quoi je commence ? Et donc, c'est vraiment l'objectif du petit framework que j'ai présenté pour aider les chefs de projet qui démarrent en disant, oui, parmi les X processus, les X tâches, finalement, quelles sont celles par lesquelles je commence ?
- Speaker #1
Qu'est-ce que tu conseilles pour commencer et quelles démarches peut-on adopter justement pour éviter de se confronter à ces frameworks déjà très complets et complexes ? Comment éviter ça ?
- Speaker #0
Tout à fait. Alors, la première chose à faire, je dis, c'est qu'on peut s'intéresser à ces biens de lire. C'est bien de s'intéresser, de savoir ce qui existe, de se former, c'est important. D'un point de vue pratico-pratique, il faut prendre du recul par rapport à la théorie, mais aussi par rapport aux outils. Il y a aussi beaucoup de gens qui rentrent dans la gestion de projet en disant tiens, on a tel outil, tu prends tel outil Il faut savoir que tous les outils, généralement, ont un biais, ils sont plus forts sur certains sujets plutôt que d'autres, et ce ne sont pas les bons juges. Donc, il faut adapter, il faut choisir l'outil en fonction. aussi de son besoin.
- Speaker #1
Toujours.
- Speaker #0
Donc, prendre du recul par rapport à ça et se poser des bonnes questions. Et donc, c'est pour ça que j'ai fait un petit post sur mon blog pour dire, je vais vous présenter en fait quatre niveaux progressifs pour lesquels il faut mettre en place différentes choses. Dans ces niveaux, l'objectif, c'est de dire il y a des choses qui ont besoin d'être formalisées. Et petit à petit, plus on va vers des projets complexes, plus on a besoin de formaliser des choses. Donc, par exemple, on va voir que la gestion de risque, c'est quelque chose qui arrive au troisième niveau. C'est-à-dire que moi, je recommande de ne formaliser la gestion de risque qu'au niveau 3. Mais quand on commence un projet, même sur un petit projet qui va rester au niveau 1, ça ne veut pas dire qu'on ne l'aura pas en tête. Mais ce que je présente dans les niveaux, c'est de dire à partir de quel moment il faut formaliser un certain nombre de choses, les mettre par écrit, plutôt que de les avoir dans la tête. Le niveau zéro, c'est j'ai un projet, j'ai un chef de projet, il a tout dans la tête. C'est lui qui connaît tout son projet, il n'a rien noté, et à chaque fois qu'on doit lui poser la question tiens, où est-ce que t'en es ? il va faire un vide calcul dans sa tête, il va sortir un chiffre comme ça, du chapeau, en disant ben voilà, voilà, oui,
- Speaker #1
oui, oui, oui
- Speaker #0
qu'est-ce que vous faites en ce moment ? Alors, il va réfléchir un petit peu, il va dire, on fait ça, ça, ça. Donc voilà, tout est dans la tête du chef de projet, donc ça, c'est le niveau zéro. D'accord ? Ça, c'est n'importe qui qui va à ce niveau-là. Donc, ces quatre niveaux, je parle d'une gestion vraiment minimale. Vraiment, je pars de la base. Après, je parle d'une gestion standard, une gestion avancée, une gestion renforcée. La première chose à formaliser, c'est ce que j'appelle la liste des livrables. Donc la liste des livrables, c'est le périmètre du projet, c'est-à-dire les résultats que l'on veut. C'est de définir vers quoi on va, quels sont nos objectifs. Voilà, c'est tout bête. Et c'est de les mettre par écrit, histoire de ne pas en oublier, qu'on se mette d'accord. Voilà, c'est la première chose à faire, c'est de faire simplement une liste des livres. Et après, une fois qu'on a cette liste des livrables, de savoir, ça c'est fait, ça c'est pas fait. Et puis un petit peu plus loin, on va dire, ça c'est fait à moitié, ça c'est fait à 70%, 80%, etc. Donc là, je dirais, c'est une gestion toute bête, qualitative, principalement qualitative, c'est juste une liste qui va définir le périmètre du projet des attendus. Et ça, ça fonctionne, c'est suffisant pour des tout petits projets. Il y a deux, trois personnes qui travaillent comme ça dans un coin, ça peut suffire. Et pour faire ça, on n'a pas besoin d'outils. On va utiliser de l'Excel, du Trello, du Notion. Voilà, c'est typiquement, ce n'est pas des outils de gestion de projet, mais ça suffit pour gérer comme ça une liste de choses à faire et puis de savoir est-ce que c'est fait, c'est pas fait. Donc ça, c'est vraiment le niveau. commence par ce qu'on veut comme résultat. Donc ça, c'est la gestion minimale.
- Speaker #1
Premier niveau du coup.
- Speaker #0
Du coup, c'est le premier niveau. Alors après, on va passer au deuxième niveau. Et là, on va vraiment rentrer dans la gestion de projet et dans la gestion. Donc là, on va passer du qualitatif. Une fois qu'on a identifié tout ce qu'on avait à faire, on va mettre des chiffres derrière. Donc des chiffres, ça va être des estimations, ça va être d'avoir des délais. Donc une fois qu'on a des estimations, on peut déterminer les délais. Parce qu'aujourd'hui, il y a quand même pas mal d'entreprises qui fixent des délais à leurs projets sans estimation. Je ne sais pas comment ils font. C'est assez courant, c'est typique, c'est le commercial qui arrive en disant j'ai le client, voici le cahier des charges Donc il y a un chiffrage qui a été fait comme ça, et des délais, et débrouillez-vous avec. Alors, en fait, tout ça se soutient. Donc là, moi, je parle de gestion de standard parce que c'est vraiment là, on rentre dans la gestion de projet, on va gérer le projet. Il faut savoir qu'un chef de projet, ça a deux rôles, celui de chef et celui de gestionnaire. Il ne faut pas oublier ce rôle de gestionnaire. D'ailleurs, ce n'est pas pour rien que les Québécois, quand ils traduisent le rôle de project manager, ils disent gestionnaire de projet, pas chef de projet. En France, on garde le côté chef de projet, le décideur, le chef. Non, non. Le chef, si on veut que ce soit un chef éclairé, il faut qu'il ait des chiffres. Il faut qu'il y ait de la gestion, etc. Donc ça, c'est la gestion de temps d'accueil. Là, on rentre vraiment dans la gestion du projet. Donc, c'est d'avoir des estimations, de gérer des délais, donc d'avoir un planning et de suivre le planning, savoir si on est en retard ou pas. C'est la même chose en termes de coûts, avoir un budget et avoir des coûts. Et puis, il y a un quatrième niveau, c'est l'organisation de l'équipe. Donc ça c'est vraiment une gestion de projet. qui est focalisé sur ce qui se passe à l'intérieur du projet. Et on met en place un certain nombre d'informations chiffrées. Donc, le premier niveau, on fait simplement un inventaire. Le deuxième niveau, là, on chiffre tout, on gère. donc du coup deuxième niveau on gère l'idée c'est de suivre les estimations les délais du coup avec un planning le suivi des coûts aussi pour s'assurer qu'on est dans les clous et gérer le travail de l'équipe voilà et tout ça ça se tient c'est à dire que évidemment si vous n'avez pas d'estimation définir des délais définir vous ne pouvez pas avoir de budget quand on fait un planning ça veut dire faire un planning ça veut dire le suivre aussi donc c'est ça la gestion on se définit des objectifs cette fois quantitatif, on va mesurer les choses et on va suivre que tout se passe bien. Donc ça, c'est le deuxième niveau et là on parle vraiment d'une gestion de projet et là je dirais, il est hors de question d'y aller avec le FFMXL. très sincèrement il existe tellement d'outils sur le marché non faire des calculs là c'est de la gestion c'est à dire c'est comme quelqu'un qui vous dit moi dans mon entreprise je fais ma comptabilité sous excel ouais ça marche quand on est auto entrepreneur mais bon on s'admire un peu plus costauds bon pour arrêter et en plus c'est vraiment une perte de temps pour le chef de projet j'irai celui qui encore a perdu du temps à tuner sa feuille excel à faire ses calculs à réinventer la roue mais Je crois qu'il ne sera pas point du coup que ça représente, parce que ça prend du temps. Donc là, il y a vraiment besoin de s'outiller parce qu'il faut faire de la comptabilité. Donc ça, c'est vraiment la version standard. Alors là, on a besoin de faire ça à partir du moment où le projet est assez significatif. Il commence à y avoir un certain nombre de personnes, ça va durer du temps. Et à ce moment-là, évidemment, il faut mettre en place ce genre de choses. On ne peut pas y aller comme ça à la fleur ou au fusil en disant on verra bien.
- Speaker #1
Le prochain jour.
- Speaker #0
Au niveau 0, au niveau 1, c'est le niveau quoi qu'il en coûte. Et le niveau 2, on dit, le quoi qu'il en coûte, ça marche pour des petites choses. Mais bon, là, ça suffit. Le truc, là, ça va commencer à nous coûter des centaines de milliers d'euros. Donc, il est hors de question de faire du quoi qu'il en coûte.
- Speaker #1
On veut savoir en 20, quoi.
- Speaker #0
Voilà. Donc, ça, c'est la gestion standard. La gestion standard, c'est-à-dire le projet devient géré comme un gestionnaire avec des chiffres, avec des informations de ce type. Après, il y a le niveau suivant. Le niveau suivant, c'est la gestion avancée. Alors là, qu'est-ce qu'on va commencer par mettre par écrit ? On va mettre en place, on va mettre par écrit la justification du projet. Qu'est-ce que c'est que la justification du projet ? C'est pourquoi on fait le projet. Alors, d'où ça sort ça ? Ça peut te dire quelque chose ? C'est la méthode Prince 2. Pourquoi la méthode Prince 2 a été créée ? Parce qu'il y avait des projets gouvernementaux, donc ça a été créé par le gouvernement anglais, qui a dit, on a des projets, on les a lancés il y a 2-3 ans, mais on ne sait plus.
- Speaker #1
pourquoi on le ferme ?
- Speaker #0
Mais on continue à le faire parce que personne n'ose l'arrêter. D'accord ? Donc,
- Speaker #1
ils se sont dit,
- Speaker #0
nous, on voudrait avoir une revue régulière où on remet en cause la justification du projet, de savoir s'il faut le continuer ou pas. Et ça, il faut le faire, en effet, quand on a le camp, c'est-à-dire des gros projets, des grosses organisations qui durent longtemps. Et donc, à ce moment-là, en effet, de mettre en place, de formaliser une justification de projet et d'avoir des revues, des processus associés de revues, de la justification. pour vérifier que c'est toujours valide, etc. Ça devient intéressant. Mais ça, il faut le mettre en place au niveau 3.
- Speaker #1
Et aussi, quand on développe le projet dans le bon sens, c'est qu'en cours de route, on ne s'est pas un peu trop éloigné de l'objectif initial.
- Speaker #0
Exactement. Il se trouve que la justification du projet, il y a deux ans, était basée sur certaines hypothèses qui sont plus valides, etc. Donc là, moi je parle d'un niveau 3 parce que ça, il faut le mettre par écrit, formaliser, mettre en place des processus de contrôle. Ça ne veut pas dire qu'au niveau 1 et au niveau 2, on ne sache pas la justification du projet. La justification du projet, elle est tellement évidente, on sait, etc. Ça peut rester de tête. Mais au niveau 3, là, on a des gros projets qui durent depuis des années, donc on va dire, moi j'aimerais bien parler de la justification du projet. Et même dans les entreprises, des fois c'est un peu classique, c'est bien de commencer à le mettre en place. Mais je dirais que c'est qu'au niveau 3 qu'on a besoin avant de le mettre en place. Mais avant de mettre tout ça en place, il faut d'abord mettre le niveau 2 et le niveau 3. De la même façon, dans la gestion avancée, il y a la gestion des ressources. Ça, je dirais qu'il faut très rapidement le mettre en place quand on commence à avoir beaucoup de projets. Parce que moi, c'est le constat que j'ai fait tout au long de ces années, c'est que les entreprises, en fait, la plupart des projets dans les entreprises sont en retard. Pas parce que pour des problématiques d'estimation, c'est simplement parce que les gens n'ont pas le temps de travailler sur les projets. Parce qu'ils font autre chose. Et ça, c'est la gestion de ressources qui va rendre ça. Donc ça je dirais, il faut mettre ça en place assez rapidement dès qu'on a des problématiques de multi-projets. Donc ça c'est important. Et puis dedans aussi on va mettre de la gestion de risque. Donc là on a des projets qui sont un peu plus importants, sur lesquels il peut y avoir des risques réglementaires, etc. Et donc on va formaliser une gestion de risque. Mais ça peut être des choses très simples. Nous dans notre outil, on a fait juste une liste de risques, tout bête, tout simple, mais ça permet de le formaliser et de le visualiser.
- Speaker #1
Je vais revenir dessus de manière régulière aussi, les risques on ne les fait pas au début et on les oublie jusqu'à la fin.
- Speaker #0
Si il y a besoin, si le projet vraiment c'est un projet à risque avec des risques réglementaires, des choses comme ça assez importantes, à ce moment-là il faut formaliser un peu plus et mettre des procédures associées, avec des revues et des copies. donc ça c'est la gestion avancée autant la gestion standard se focalisait sur le projet en lui-même les estimations, les délais du projet etc. Là dans la gestion avancée on va dire mon projet il s'insère dans quelque chose qui est plus vaste dans une entreprise et donc dans lequel le projet on va pouvoir le justifier vis-à-vis des demandeurs on va faire de la gestion de ressources parce qu'il y a d'autres projets en parallèle et donc il faut gérer ces interactions les interdépendances et l'interdépendance se fait naturellement autour des ressources Et puis, il y a la gestion des risques, c'est-à-dire que mon projet est influencé par des facteurs externes qui peuvent remettre en cause mon projet. Donc, les risques peuvent être internes, mais c'est surtout les risques externes qui sont intéressants à gérer. Et ça, je mets ça dans le niveau 3. Pourquoi ? Parce qu'il y a des gens qui me parlent de la gestion des risques et qui n'ont pas d'estimation, qui n'ont pas de gestion de coûts, qui ne font pas de suivi de l'avançant, etc. Je dis mais arrêtez de calculer les risques. Le premier risque, il est là, c'est que votre projet n'est pas géré. Si vous ne savez pas où vous en êtes dans votre projet, la gestion des risques n'a pas de sens. Oui, c'est ça. Voilà, donc c'est pour ça qu'il faut formaliser les choses au fur et à mesure.
- Speaker #1
Pour résumer peut-être un peu ce niveau de gestion avancée, le but c'est, si je comprends bien, de l'intégrer d'une manière plus globale dans l'entreprise et dans un portefeuille de projet, en prenant en compte la justification du projet, savoir que le projet va toujours bien dans le bon sens, il répond toujours bien à ses objectifs, la gestion des ressources qui vont être disponibles pour mener à bien le projet, et la gestion des risques qui peuvent influer sur la réussite du projet.
- Speaker #0
Exactement, c'est tout à fait ça. Et puis, il y a le dernier niveau que j'appelle la gestion renforcée. Alors ça, on va retrouver ça dans les manuels justement, dans les méthodologies. Mais je dirais qu'au début, il ne faut pas se préoccuper de ça. Alors ça va être gestion de la qualité, gestion des parties prenantes, gestion des fournisseurs. Donc voilà, gestion des contrats, ce genre de choses. Donc là, on se rend compte que c'est pour des projets qui sont très costauds ou des projets qui sont très politiques ou sur lesquels on va faire de la gestion de la qualité, on va formaliser la qualité par exemple. Quand c'est un projet contractuel, on est prestataire, on est incluant. Et voilà, c'est un projet assez important. Donc là, il va falloir vraiment consolider les choses, blinder le projet, je dirais, d'une manière globale. La gestion des parties prenantes. Moi, personnellement, je n'en ai jamais fait. Je ne suis jamais arrivé à des projets de ce type-là. Mais de gérer quels sont les détracteurs du projet, ceux qui vont au contraire le pousser en interne, ce côté politique, moi, je n'aime pas trop ça. s'il y a besoin, il faut le faire.
- Speaker #1
Après, ça dépend aussi, je pense, des typologies de projets. Pour avoir pas mal bossé dans l'industrie, c'est des choses qu'il faut arriver à penser pas trop tard et qui peuvent devenir des spécialistes.
- Speaker #0
Exactement, parce que c'est un gros projet. Mais dans l'industrie, tu apprenneras, ce ne sont pas des débutants qui viennent faire des projets.
- Speaker #1
Non,
- Speaker #0
en général. Ce sont des gens de 20 ans, 30 ans de métier. En effet, ce sont des gens avec d'autres compétences. Parce que, autant les chefs de projet qui restent au niveau 1, ce sont souvent des gens qui sont très techniques. Au niveau 3, ça va être des gens où il va falloir qu'ils aient une carrière un peu plus politique dans l'entreprise et le manager.
- Speaker #1
Tu peux nous en faire un bref résumé ?
- Speaker #0
Première chose à mettre en place, c'est de faire la liste de toutes les choses qu'on a prévu de réaliser, c'est-à-dire la liste des livrables et de suivre l'avancement. C'est vraiment le minimum, le zéro, et on peut faire ça dans n'importe quel outil, c'est très simple. Le deuxième niveau, c'est quand on commence à devenir un peu plus sérieux, que le projet a quand même un peu plus d'importance, qu'on doit s'engager sur des dates, qu'on doit avoir de la visibilité sur des coûts et des délais, qu'on n'ait plus d'emploi qui n'en coûte. Là, c'est la gestion standard, donc c'est de bien gérer son projet en interne. donc ça, ça s'applique dès que le projet commence à devenir un projet. Mais très rapidement, une fois qu'on a bien mis ça en place, on sait bien gérer son projet, on maîtrise bien le projet en interne, après on peut passer au niveau supérieur, donc la gestion avancée avec la justification de projet, la gestion des ressources, la gestion des risques, donc c'est comme tu l'as dit, c'est le projet dans son contexte dans l'entreprise, c'est-à-dire dans le portefeuille de projet et dans l'entreprise. Et puis après, il y a des projets avec le côté contractuel tellement fort, avec le côté politique tellement fort, et là, il s'agit de blinder le projet. D'accord ? Là, c'est l'armure. C'est l'armure du chevalier. Voilà, c'est vraiment le carpent. Là, on peut dire adieu à l'agilité. Là, on est vraiment dans le truc où on le blinde au maximum. On a fait appel à des avocats. Voilà, on est vraiment dans du pur contractuel. Et donc, ça, c'est la gestion renforcée qui s'est passée. et donc tous les gros projets sur lesquels il y a des millions, des dizaines de millions en jeu. Là, évidemment, on met en place ce genre de choses parce que les dégâts peuvent être...
- Speaker #1
Comme tu l'as dit, en renforçant cette gestion de projet, on devient plus rigide, cela prend plus de temps. Qu'est-ce que tu peux répondre à cette critique ?
- Speaker #0
Ce qui est important de savoir, c'est que la gestion de projet, ça doit être quelque chose qui doit prendre très peu de temps. Il y a des métiers dans lesquels la gestion de projet... ça peut être très important parce que les projets ont des problématiques de planification qui sont complexes. Moi, je pense par exemple sur un chantier de BTP, typiquement, le travail de planification doit être hyper rigoureux parce qu'il y a plusieurs acteurs qui vont intervenir, plusieurs équipes. qui vont enchaîner du travail. Et il faut organiser tout ça, mais d'une manière très précise. Il faut être pointilleux. Et donc là, on a des techniques de planification qui permettent de le faire. Par contre, quand on est dans le développement logiciel, je dirais qu'il faut oublier des techniques comme le PERT, le chemin critique. Ce n'est pas du tout adapté à ce contexte. Donc, même quand on fait de la gestion des délais, quand on fait de la planification, il faut dire, dans le PMBOK, j'ai entendu parler du PERT, du chemin critique, c'est génial, c'est super. Ce n'est pas une bonne idée. Vous faites du PERT, du chemin critique, que dans des métiers sur lesquels les tâches, il y a une problématique de séquencement très rigoureuse, très importante.
- Speaker #1
Voilà, tout ce qui est chemin de critique, ça marche, enfin, le PERT qui est lié à ça, ça marche quand on a vraiment des choses qui s'enchaînent avec des contraintes qui font qu'on ne peut pas faire l'une avant l'autre,
- Speaker #0
Exactement.
- Speaker #1
Ou très difficilement, ou que ça remet la stratégie de réalisation complète dans le projet,
- Speaker #0
quoi. Moi, c'est l'exemple que je donne souvent, c'est par exemple, si vous êtes dans un métier comme dans le DTP, où il est hors de question de... de monter un mur avant que la dalle de béton soit coulée et sèche, on voit bien que là, on ne peut pas y déroger. C'est-à-dire que si on commence à monter le mur avant la dalle de béton, le mur, on peut le mettre à la poubelle, ça ne sert à rien. dans l'informatique par exemple on va vous dire en théorie parce qu'il y a toujours le côté théorique il faut finir la conception pour coder ou même il faut finir les spécifications pour commencer à implémenter ça c'est juste une contrainte que ça pose volontairement mais dans les faits c'est pas du tout comme ça que ça marche il y a beaucoup de sociétés qui le cahier des charges il est encore en cours de rédaction que les gens commencent à coder et ça pose pas de problème parce qu'on est pas dans le même monde on a pas les mêmes contraintes Donc il y a des métiers dans lesquels le travail de planification sera beaucoup plus rigoureux, sur lesquels il faut utiliser des techniques avancées. Par contre, il y a des métiers sur lesquels la planification doit rester adaptée à ces macros. Par exemple, dans le monde, moi je connais bien le monde du développement logiciel, les choses bougent beaucoup et on a cette souplesse-là. On a la souplesse de se dire, finalement, mon logiciel, je vais le changer, je vais ajouter des modules, etc.
- Speaker #1
C'est sûr que ce n'est pas la même chose que quand on a coulé une dalle de béton de 30 cm. Ah mais voilà, si tu veux.
- Speaker #0
Si le client, en plein milieu du chantier, dit finalement je voudrais rajouter une tour à gauche, une tour à droite, les gens vont dire non, ce n'est pas possible. Alors que dans le logiciel, c'est ce qui se passe régulièrement. Le client a la possibilité de changer d'avis et le logiciel permet. Il est malléable, il permet de le faire, surtout si on utilise des approches agiles, on conçoit bien les choses.
- Speaker #1
Du coup, pour toi, quels sont les avantages de procéder de cette manière par rapport à d'autres méthodologies que tu as évoquées précédemment ?
- Speaker #0
L'avantage, c'est que tu ne mets pas une usine à gaz en place. C'est-à-dire que si tu essayes d'implémenter le PMBOK sur ton petit projet où il y a 2-3 développeurs pendant 3 mois, et là, tu vas être complètement paumé. Tu ne vas pas écrire un project chapter pour un projet de 2-3 mois. Ce n'est pas vrai, ce n'est pas réaliste. Donc, cette approche-là, elle est progressive. elle guide les gens à ce qu'il faut mettre en place petit à petit. Et encore une fois, je parle de la formalisation, et ce qu'il faut formaliser. Et c'est bien de savoir, moi j'en suis resté au niveau 1 parce que c'est adapté, je suis passé au niveau 2. ça permet une montée en compétences naturelles parce que du coup on met en place le niveau 1, une fois qu'on est à l'aise au niveau 1, on se dit bah ouais le niveau 2 j'aimerais bien et puis on met en place le niveau 2 et puis ça va naturellement avec je dirais la carrière des personnes. Quand tu commences, tu vas commencer sur un tout petit projet, tu vas être tout seul, tu vas être 2 puis 3 donc tu vas rester au niveau 1, tu vas mettre en place le niveau 2 et puis au fur et à mesure si tu réussis tes projets tu vas grimper. et tu auras des projets de plus en plus importants, donc tu vas monter comme ça petit à petit. Donc tu n'as pas ce côté, tiens, je te confie le PMBOK, tu le lis, puis tu le débrouilles avec. Là, c'est naturel et tu mets les choses en place. En plus, ça guide vraiment les personnes qui démarrent dans les choses à mettre en place dans quel ordre. Ne faites pas de la gestion de risque. Si vous n'êtes pas capable, si vous n'avez pas de suite de l'avancement sur votre projet, si vous n'avez pas d'estimation, etc., ça ne sert à rien de gérer les risques. Il ne faut pas vous focaliser là-dessus. Mettez en place. on place les choses dans le bon ordre. Donc là, c'est un exemple avec la gestion de risque. Et d'une manière générale, il y a beaucoup d'organisations qui mettent en place de la gestion de projet, qui au début ont des grosses ambitions. et ils veulent tout faire. Ah ouais, très bien, on va certifier tout le monde, on va leur mettre toute la gestion de projet et puis on va leur prendre leur outil. On a un super outil qu'on nous a recommandé, le truc super compliqué, et puis on les met. Conclusion, les gens sont complètement paumés, ils essayent, ils mettent beaucoup d'efforts, ils se découragent, et six mois plus tard, ils en reviennent à la feuille Excel où ils abandonnent la gestion de projet et ils ne sont dégoûtés pas. Quand on met une approche progressive, on monte les marches petit à petit, on voit les résultats, et on s'arrête au niveau où on a des résultats. Parce que ça ne sert à rien de mettre en place des choses où on ne voit pas de valeur ajoutée. Les gens vont abandonner. Donc, et dans une entreprise, il y aura des projets qui seront gérés au niveau 1, d'autres au niveau 2, d'autres au niveau 3, d'autres au niveau 4. Ça ne pose pas de problème. Et ça, c'est le défaut de toutes les entreprises qui veulent passer comme ça, en disant on va mettre tout le monde au même niveau, avec les mêmes outils, ce qui est complètement aberrant. Il faut pouvoir s'adapter. Donc, j'espère que ce petit... c'est très court c'est ça mais ça rappelle en fait comment petit à petit il faut formaliser les choses encore une fois je parle de formalisation ça ne veut pas dire que c'est pas parce qu'au niveau 1 on ne connait pas les risques mais au niveau 1 on les connait de tête au niveau 3 on les formalise, on les voit ils sont revus, ils sont suivis donc on a un processus qui est formalisé et il y a un registre des risques qui est écrit c'est la différence au niveau 1 on peut avoir un planning On va dire, ouais, j'ai eu le deadline, c'était le date, on a une release pour fin mai. Sauf que c'est juste une date qui a été balancée comme ça, que le mec a sorti de tête parce qu'au final, il se dit, fin mai,
- Speaker #1
on devrait être bon. Ça devrait être bon, quoi.
- Speaker #0
Au niveau 2, on a fait les calculs, on a fait les estimations, et on se dit, avec les estimations que j'ai, les nombres de ressources disponibles, fin mai, ça rentre. Mais j'ai des chiffres derrière qui permettent de le justifier. Ou au contraire, les chiffres vont dire, maintenant, finalement, en fait, ça ne rentre pas. Donc, l'intuition que j'avais que c'était fin mai, en fait, je me rends compte que c'est fin juin. ou alors il faut qu'on décale des choses. Donc, c'est toujours le côté de mettre en place des choses progressives et pas le côté Big Bang.
- Speaker #1
De faire en sorte que la méthodologie qu'on met en place corresponde aux besoins des projets.
- Speaker #0
Et surtout, évitez l'usine à gaz, sinon vous allez dégoûter les gens de la gestion. Et là, aujourd'hui, il n'y a pas plus d'attente en compte. Il y a beaucoup de gens qui sont en rejet de la gestion de projet parce qu'on leur met en place des procédures, des processus. La PAP, c'est complètement bureaucratique. On leur demande de créer du project charter pour un projet des fois c'est un projet de 15 jours il y a 15 jours de travail on leur demande écrivez moi du papier non ne mettez pas ça en place pour ce type de projet il faut le faire de manière très simplifiée mais même encore je reconnais 15 jours tu mets ton place de simplifier on essaie toujours de dire je prends le project charter mais je le simplifie pour 15 jours c'est pas si tu fais un project charter personne ne le lit même la version simplifiée je me bats contre le côté papier dans la gestion de projet de faire des paperasses sur des projets simples t'as pas besoin de tout écrire et plus ça devient compliqué plus ça devient contractuel plus t'as besoin de mettre des choses par écrit pour pouvoir les ressortir le cas échéant mais concrètement qui est-ce qui lit des comptes rendus de réunion c'est sûr que c'est pas forcément très souvent éventuellement ceux qui n'étaient pas là et encore donc je dirais un project charter pour un project de 15 jours moi je le fais pas moi je dis non on en discute ensemble dans la réunion on peut garder tout ça ça peut être deux têtes tu peux le faire quand même mais bon est-ce que ça l'objectif de la gestion de projet c'est pas de faire de la gestion de projet pour faire de la gestion de projet pour dire on le fait la gestion de projet ça doit servir à quelque chose et justement l'idée des niveaux là c'est de dire bon Faites pas de la gestion de risque sur un projet sur lequel c'est en interne, il n'y a pas de risque, etc. C'est trois fois rien. Faites pas de justification de projet avec une revue de justification de projet pour un projet de six mois. Si le projet n'est plus justifié en moins de six mois, il ne fallait même pas le lancer. C'est vraiment un cas extrême.
- Speaker #1
Rester simple.
- Speaker #0
Faites quelque chose d'adapté, faites quelque chose d'utile. Donnez vraiment à la gestion de projet de l'inverse. Faites pas de la gestion de projet en disant, ah ouais, mais dans les méthodes, ils disent ça. Ah ouais, j'ai été formé par un formateur, il m'a dit, ah, on a vu ça, c'était super intéressant. Voilà, prenez du recul. et un sens critique. Soyez pragmatiques en disant dans la gestion de projet, il y a plein de choses utiles, mais dans la globalité de l'ensemble de la gestion de projet qui a été prévue pour gérer des projets très complexes, si vous êtes sur un cas beaucoup plus simple, il faut picorer dans les référentiels, dans les méthodes, prendre vraiment ce que vous pensez être utile. Project charter, vous pensez que ça va vous être utile, vous le faites. Si vous pensez que ça ne va pas être utile, vous le faites. Moi, ce que je rencontre, c'est que dans les entreprises, souvent, on rencontre des gens qui sont assez méthodologiques, assez dogmatiques et qui voudraient, par exemple, et un project charter. J'ai des clients dont les projets, c'est trois jours. Ils appellent ça un projet.
- Speaker #1
on ne peut pas dire aux gens vos projets ne sont pas des projets parce que ça ne dure que 3 jours d'accord mais c'est sûr que s'il faut passer une demi journée pour faire un project charter ça m'énerve mais
- Speaker #0
même je dirais un quart d'heure demander à un mec qui va mettre en place un serveur un nouveau routeur qui considère que pour lui c'est un projet de lui demander de remplir un papier qui va prendre quelques quarts d'heure mais que personne ne valide pour lui c'est très frustrant et en plus le management qui va lui demander ça il va dire non mais celui-là il ne sert à rien il ne sert finalement qu'à faire de la paperasse et de la bourdonce donc il faut bien comprendre aussi qu'en imposant des méthodes aux personnes dont ils ne comprennent pas le sens ils ne voient pas l'utilité et bien c'est le management qui perd de sa crédibilité et donc c'est pour ça moi je considère qu'il faut vraiment laisser déjà aux chefs de projet les responsabiliser donner de l'autonomie de leur faire confiance et pas leur imposer une méthode à leur imposer des papiers, de la paperasse, etc. Il faut qu'ils en comprennent le sens pour pouvoir le faire.
- Speaker #1
Du coup, comment tu vois dans tout cela la place du chef de projet ?
- Speaker #0
Le chef de projet, pour moi, c'est un capitaine de bateau. Il est maître à bord. Il est seul maître à bord. On ne doit pas lui imposer telle méthodologie, etc. On peut lui imposer des livres à main. C'est-à-dire, on dit, en tant que chef de projet, dans ta gestion de projet, je veux qu'on ait une revue régulière de l'avancement. Je veux que je connaisse les budgets, les délais. Je veux avoir un projet de chartage qui peut leur profiter de l'économie. Mais leur imposer une méthode, un processus, etc., je trouve ça toujours problématique. Je pense qu'un chef de projet doit avoir un certain degré de liberté.
- Speaker #1
Un certain degré de liberté et une certaine faculté d'adapter les processus et ces choses-là aux besoins réels des projets qui sont menés.
- Speaker #0
Voilà. S'il est responsable, un chef de projet, c'est quelqu'un à qui on a confié, donné un mandat, comme on dit, il est responsable, il faut qu'il ait les mains sur les manettes. Il ne peut pas être responsable, mais en même temps, on décide tout pour lui. Donc, il faut qu'il puisse décider, notamment sur le processus. Je ne veux plus l'imposer, certaines... certaines règles, certains livrables, ça fait partie des livrables. Pour moi, dans un projet, tu as les livrables techniques demandés par le client, mais des fois, tu as des livrables méthodologiques. Par exemple, il faut un guide utilisateur ou par exemple, un document de mise en production. On va imposer ça. Et puis, il y a des livrables qui sont demandés par le management. Par exemple, c'est toute la partie gestion de projet. Je veux un copil tous les mois. Et pour moi, c'est un livre. un résultat qu'on nous demande à produire dans le projet. C'est-à-dire qu'à un moment, il faut produire cette gestion. La gestion de projet, en fait,
- Speaker #1
devient livrable. question, quelque chose à rajouter avant de finir ?
- Speaker #0
Oui, parce que tu aurais pu me dire, oui, mais l'agilité dans tout ça, est-ce que c'est compatible ? Alors, je te dirais, la réponse courte, c'est oui, c'est compatible, bien sûr. Par contre, on n'a pas le temps d'en discuter.
- Speaker #1
Oui, c'est ça, on peut parler dans un autre épisode.
- Speaker #0
Oui, en tout cas, bien sûr, c'est compatible. C'est vrai que la gestion de projet n'est pas traitée par les frameworks agiles. Les frameworks agiles ne font pas de la gestion de projet. évidemment ces problématiques de gestion de l'ivrable, gestion de l'avancement, délai, etc., budget et compagnie, ça s'applique à tous les projets. Tous les projets ont besoin d'être gérés, après il y a des adaptations, les rôles vont changer, etc.
- Speaker #1
Oui, je suis un peu du même avis, cette partie-là de gestion de projet, elle est d'une certaine manière un peu indépendante de la manière dont on développe le projet en lui-même, et c'est là où les méthodes agiles vont plus rentrer dans... Dans la manière de faire et dans le développement du projet en lui-même, mais il ne couvre pas, comme tu le disais, ces aspects de coût, de délai, de... Voilà, au final,
- Speaker #0
le plus simple à dire, c'est que même si vous êtes dans un développement agile, etc., vous avez un coût. À la fin du mois, il y a des salaires à payer, et ça ne se fait pas dans une entreprise. L'argent, voilà, ça... Il n'y a pas une source naturelle d'euros dans le bureau du DAF qui jaillit. Donc voilà, ça se gère. Et la réponse est, dans tous les cas, ça se gère et ça se fait très bien en suivant ce type de framework.
- Speaker #1
Très bien. Merci beaucoup, Renaud, d'avoir exposé ce framework qui donne une idée de comment mettre en place la gestion par projet dans l'entreprise.
- Speaker #0
Je suis surpris. Je suis surpris. À très bientôt,
- Speaker #1
Tanguy. À bientôt. Au Merci Renaud d'avoir partagé ta méthode pour facilement implémenter la gestion par projet de manière progressive. Vous savez maintenant par où commencer si vous souhaitez faire évoluer la manière dont les projets sont faits dans votre structure. Vous avez d'autres techniques pour mettre en place la gestion par projet ? Des questions sur ce qui a été présenté ? Venez en discuter avec nous sur LinkedIn. Cet épisode vous a plu ? Abonnez-vous à Focusprojet sur votre plateforme préférée et parlez-en autour de vous. A la semaine prochaine.
