La gestion de projet est un domaine souvent mal compris en entreprise, ce qui est étonnant puisque cette manière de travailler est aujourd’hui très largement répandue, à tous les coins du globe.
On entend tout et n’importe quoi sur la gestion de projets, et des mythes persistent chez les dirigeants, et mêmes les chefs de projet, malgré des dizaines d’études et d’ouvrages sérieux sur le sujet, et malgré des retours d’expérience des experts du milieu.
Dans cet article, je vais casser ces grands mythes un à un, qui ont la vie dure, même chez certains chefs de projet expérimentés.
Les 20 plus grands mythes de la gestion de projet… Et pourquoi ils sont faux
1 ) Le chef de projet est le seul responsable de la réussite du projet
Oui, le chef de projet est le garant de la réussite du projet. Mais non, il n’est pas le seul responsable de sa réussite.
Je m’explique.
Être garant de la réussite du projet, cela signifie mettre tout en œuvre pour maximiser les chances de réussite.
Le chef de projet prend pleinement part à cela, en tant que facilitateur. Il œuvre au quotidien pour favoriser les échanges, la communication, la coopération et la collaboration au sein de l’équipe projet et plus globalement avec l’ensemble des parties prenantes.
C’est une sacré responsabilité. Mais c’est un engagement de moyens, pas de résultats.
La réussite d’un projet dépend de nombreux autres facteurs : l’implication des experts de l’équipe projet, l’engagement des parties prenantes clés, la prise de décision éclairée du sponsor ou du client, etc.
Toutes ces personnes sont également responsables de la réussite du projet, chacune à son niveau.
Prenons les membres de l’équipe projet, par exemple. Un expert technique se voit confier une tâche à réaliser dans le cadre du projet. Il est en charge de ces tâches, et il en est le responsable, d’après la matrice de responsabilité RACI.
Le chef de projet, lui, est responsable du suivi de la progression du projet, et donc du suivi de cette tâche. Il est l’approbateur, c’est à dire qu’il valide que le travail réalisé correspond bien à ce qu’on attendait en terme de qualité, et que l’ensemble des besoins ont bien été traités.
Dans ce cas, le responsable de la tâche, et le responsable du travail livré n’est pas le chef de projet, mais bien la personne qui a réalisé la tâche. Donc l’expert technique.
2 ) La gestion de projet, ce n’est rien d’autre que de la planification
On croit souvent à tord que gérer un projet revient à faire un rétroplanning en liste à puces dans un mail, et à suivre une liste de tâches dans un fichier Excel, et les cocher quand celles-ci sont réalisées.
On ne peut pas être plus loin de la vérité.
Ce que je viens de décrire s’apparente à de la gestion des tâches, via une todolist, et à la planification « macro » d’un projet.
Le management de projets va bien au-delà, et couvre les 10 domaines de compétences suivants :
- La gestion de l’intégration.
La gestion de l’intégration du projet consiste à élaborer puis mettre en œuvre le plan du projet, ainsi qu’à contrôler les changements pouvant survenir en cours de route. - La gestion de la portée.
La gestion de la portée, anciennement appelée la gestion du périmètre, consiste à cadrer le projet tant en terme d’objectifs, que de travail à réaliser ou de livrables à fournir. - La gestion de l’échéancier.
La gestion de l’échéancier consiste à élaborer puis à maîtriser le planning du projet. Ce domaine de connaissances s’appuie pour cela sur des techniques d’estimation de durée, des outils de planification tels quel que le macro-planning, le rétroplanning ou encore le diagramme de Gantt, ainsi que sur l’organisation du travail en séquences, marquées par des jalons. - La gestion des coûts.
La gestion des coûts consiste à déterminer le budget prévisionnel du projet, à estimer les coûts, à les planifier et à les suivre dans le temps. - La gestion de la qualité.
La gestion de la qualité consiste à s’assurer que le standard de qualité des livrables fournis aux clients est conforme à leurs attentes et exigences. En bref, faire de la qualité, c’est bien faire le travail dès la première fois. - La gestion des ressources.
La gestion des ressources consiste à constituer l’équipe projet et à manager les ressources humaines, ainsi qu’à gérer les ressources logicielles, intellectuelles et matérielles mises à disposition du projet. Bien que je n’aime pas l’idée qu’un collaborateur soit une ressource au même titre qu’un ordinateur (ressource humaine vs ressource matérielle), on parle bien des ressources humaines en entreprise. Donc ça se tient. - La gestion des communications.
La gestion des communications consiste à gérer et suivre l’ensemble des communications sur le projet. Cela englobe les communications au sein de l’équipe projet, les communications officielles à destination des parties prenantes, les échanges informels, mais également l’envoi des rapports d’avancement du projet. - La gestion des risques.
La gestion des risques consiste à identifier les menaces pour le projet, ainsi que les opportunités. On va donc identifier un risque, puis l’analyser afin de connaître son impact et sa probabilité de survenance, et enfin mettre en place un plan d’action pour le contrer. - La gestion des approvisionnements.
La gestion des approvisionnements consiste à gérer sa structure de coûts, ses commandes, et ses fournisseurs.
Plutôt que de penser juste en relation contractuelle et financière entre un acheteur et un fournisseur externe, je vous invite à voir cela comme un accord ou un partenariat entre deux parties prenantes du projet, l’une interne et l’autre externe. - La gestion des parties prenantes.
La gestion des parties prenantes consiste à identifier les parties prenantes, à communiquer avec elles au quotidien, et à répondre à leurs attentes et besoins.
Ces domaines de connaissances ne sont pas autonomes, et se nourrissent l’un l’autre tout au long du projet. Le chef de projet doit donc maîtriser l’ensemble de ces compétences, et avoir où et quand porter son attention en fonction de l’avancée du projet.
Pour aller + loin : Si vous souhaitez détailler ce concept des 10 domaines de compétences, je vous invite à consulter cet article complet sur les domaines de connaissances en gestion de projet.
3 ) Le chef de projet est le boss
Voilà une erreur que je rencontre encore bien trop souvent. On croit à tord que le chef de projet est LE boss de l’équipe, et la personne qui a le maître mot sur le projet. C’est faux.
Déjà, un chef de projet n’a aucun lien hiérarchique avec l’équipe projet. D’ailleurs, cette équipe est montée spécifiquement pour les besoins du projet, et n’a aucune existence au sein de l’organigramme de l’entreprise, pour la simple et bonne raison qu’il s’agit d’une équipe pluri-disciplinaire.
Autrement dit, ses membres font partie de différents services de l’entreprise, et dispose de compétences complémentaires permettant de mener à bien le projet.
Un projet, c’est avant tout l’affaire de collaboration. Il n’y a pas d’un côté le chef de projet et de l’autre l’équipe. Le chef de projet fait partie de l’équipe.
Ce n’est pas au chef de projet de décider des actions à réaliser, de l’ordre dans lequel les réaliser, et de qui fait quoi.
Pour déterminer cela, il est nécessaire de travailler de façon collaborative. Ce sont les experts qui déterminent le meilleur scénario pour atteindre les objectifs du projet, les tâches à réaliser et l’ordre dans lequel le faire.
Le chef de projet est là pour rappeler les objectifs à atteindre, pour challenger les experts, consolider les informations, et s’assurer que l’ensemble des informations remontées est bien cohérent.
Il n’est absolument pas là pour jouer au chefaillon et dicter aux autres quoi faire. Il n’en a ni le temps, ni les capacités, ni l’autorité, ni l’expertise.
4 ) Le changement est toujours mauvais, il faut l’éviter
Le changement, surtout en cours de route, est source d’incertitude. Et l’incertitude, en gestion de projet, est synonyme de risques, de problèmes et d’imprévus.
Le premier réflexe est donc de vouloir éviter le changement à tout prix, et de faire en sorte de se conformer coûte que coûte au plan d’action préalablement défini.
Oui mais voilà… Si vous faites ça, vous vous tirez une balle dans le pied. Car les besoins peuvent évoluer, tout comme le marché, ou les attentes des utilisateurs finaux.
Un concurrent peut débarquer et forcer l’entreprise à s’adapter pour rester compétitive.
Une nouvelle réglementation locale ou nationale peut être votée et appliquée, vous forçant à vous adapter. Les premiers retours suite au test de votre produit prototype peut vous forcer à revoir votre copie et à vous adapter.
Bref, vous avez compris, en gestion de projet le maître mot est l’adaptation.
Vous devez embrasser le changement, et l’accepter, car il est inévitable. Pour rester efficace et compétitif, il n’y a pas d’autres choix que de s’adapter.
Mais ne me faites pas dire ce que je n’ai pas dit : accepter le changement et s’adapter ne veut pas dire oui à tout.
Sinon c’est la porte ouverte à tout un tas de dérive, en prenant le risque que votre projet soit une histoire sans fin.
5 ) La gestion de projets c’est seulement pour les gros projets en multinationales
Dans les TPE et PME, les chefs de projet sont souvent officieux, et doivent gérer leurs projets en plus de leurs autres missions.
Et j’entends souvent les directeurs de ces structures dire que la gestion de projet, les méthodologies et autres processus indiquant comment piloter un projet, sont trop lourds et sont pensés pour les grosses boîtes et les multinationales.
D’après eux, une petite entreprise a besoin de flexibilité et d’agilité, et les processus de gestion de projet ne le permettent pas.
Ok, j’entends les critiques. Mais quelle est l’alternative ? La gestion à l’arrache ? Je ne suis pas certain que ça fonctionne réellement…
Les personnes qui tiennent ce discours ont raison dans le raisonnement, mais se plantent sur la conclusion.
Effectivement, appliquer une méthodologie comme celle préconisée par le PMI (Project Management Institute) et ses 49 processus, c’est très lourd pour une TPE / PME, et totalement inadapté.
Mais justement, ces méthodologies (PMI, Prince2, etc.) sont avant tout fondées sur l’adaptation et la flexibilité. Si les processus sont trop lourds pour votre structure, vous pouvez les simplifier.
De la même manière, si certains sont inutiles, vous pouvez les supprimer.
Pourquoi s’encombrer de quelque chose qui va vous consommer du temps et de l’argent pour alourdir le processus et ralentir le projet ? Ça n’a aucun sens.
Être chef de projet, c’est avant tout savoir choisir la bonne méthodologie et les bons outils, en fonction du projet, de la situation et du contexte.
Dans certains cas, cela signifie mettre en place des gardes-fous assez complexes, ainsi que des processus lourds et structurés. Dans d’autres cas, au contraire, on va privilégier une approche beaucoup plus agile, permettant de s’adapter rapidement aux aléas et aux évolutions du marché.
Au final, la gestion de projets est adaptée aux entreprises de toutes tailles, tous secteurs d’activité confondus. Il faut juste adapter les modèles proposées par ces méthodologies, et ne pas les appliquer à la lettre, sans réflexion.
6 ) Le client a toujours raison
Lorsqu’on gère un projet, on va avant tout chercher à résoudre un problème particulier, à atteindre les objectifs fixés et à répondre aux différentes attentes et besoins. En bref, on cherche à satisfaire le client.
Un client satisfait, c’est le succès d’un projet.
Le corolaire que certains font de cette affirmation est logique, mais néanmoins faux : Si le client demande des modifications au projet, il faut l’accepter pour satisfaire le client.
En bref, puisque c’est lui qui paye, le client est roi et a toujours raison.
Sauf que…. Non. Désolé, ça ne marche pas comme ça.
Une modification sur un projet n’est jamais anodine, et l’accepter sans évaluer ses impacts sur le projet, l’équipe, ou l’entreprise, c’est un peu suicidaire.
Vous vous voyez accepter un nouveau job, sans savoir à l’avance quand et où vous allez travaillez, combien vous allez être payé, et ce qu’on attend de vous ? Je ne crois pas, non. Et vous avez bien raison.
Et bien, pour le projet, c’est pareil. Ce n’est pas parce que le client souhaite modifier une partie du projet qu’il faut s’empresser de lui dérouler le tapis rouge et lui baiser les pieds.
C’est d’ailleurs pour cela qu’un processus de gestion des demandes de changements est proposée avec toute bonne méthodologie qui se respecte. Pour évaluer le changement, évaluer son impact, et voir s’il va mettre en danger le projet (ou non).
Le client n’a pas toujours raison, et vous avez tout à fait le droit de lui dire non. A condition d’expliquer et d’argumenter votre refus.
Cela me fait penser à une citation d’Henry Ford, qui illustre bien la situation :
Si j’avais demandé aux gens ce qu’ils voulaient, ils m’auraient répondu des chevaux plus rapides.
Henry Ford
7 ) Les réunions sont une perte de temps
Ce mythe est tenace, notamment auprès des experts.
Ils ne voient pas l’intérêt
de participer à une réunion de synchronisation avec le reste de l’équipe projet, ni à un atelier de travail avec le client.
« C’est pas leur job », qu’ils me diraient.
On ne peut pas leur en vouloir. Des réunions inutiles, ils en ont sûrement subi des tas grâce à leur manager ou leur direction. Ça peut se compter en dizaines par mois.
Mais là où ils font fausse route, c’est sur les réunions projet. C’est même le meilleur moyen de se coordonner et de collaborer. A condition de bien s’y prendre.
Une réunion projet peut servir :
- A se coordonner.
Cela permet aux différents experts de faire le point, et de se coordonner sur les tâches, notamment dans le cas de dépendances entre ces tâches, ou d’impacts sur le travail de l’autre. - A collecter de l’information.
Organiser un atelier de travail avec les utilisateurs finaux d’un produit peut permettre de collecter des besoins et attentes, de mieux comprendre l’utilisation d’un produit, de collecter des retours d’utilisation, etc. - A transmettre de l’information.
Dans ce cas, je vous invite avant de vous précipiter sur l’envoi de l’invitation, à réfléchir s’il n’existe pas de meilleur moyen de transmettre cette information que de réunir une dizaine de personnes autour d’une table. C’est d’ailleurs souvent le cas. Vous pouvez planifier ce type de réunion si et seulement si c’est vraiment nécessaire et qu’il n’existe aucun autre moyen fiable. - A réaliser un brainstorming.
Particulièrement utile pour trouver des solutions à un problème, réfléchir aux différents scénarios qui s’offrent à vous, identifier des risques et les évaluer, ou concevoir une solution technique de zéro. - A prendre une décision.
Une réunion peut enfin permettre de réaliser un arbitrage, c’est à dire peser le pour et le contre de chaque option, et choisir la meilleure possible par rapport aux informations dont vous disposez à un instant t.
Par contre, là où je suis d’accord, il ne faut pas en abuser. Une réunion doit avoir un but précis, un ordre du jour, et doit déboucher sur une avancée pour le projet, une prise de décision, la mise à jour du planning ou d’une documentation, une liste de tâches à réaliser, etc.
Si ce n’est pas le cas, où si l’équipe juge à la fin de la réunion qu’elle n’avait aucun intérêt, je suggère de l’arrêter, purement et simplement, et de voir si ça fonctionne mieux sans.
8 ) Il existe une bonne et une mauvaise manière de gérer des projets
Je vois souvent passer sur LinkedIn des postes de « coach agile » et d’« experts projet », nous vantant les mérites de telle méthodologie, de tel framework ou encore de tel outil.
Selon eux, il existerait une bonne manière de gérer de projet, et 1001 manières de mal le faire. Chacun prêche pour sa paroisse. Et chacun va dire que l’autre à tord.
Aux risques d’en décevoir certains, non il n’existe pas de méthodes miracles permettant de gérer ses projets à coup sûr.
Si c’était le cas, on ne vivrait plus de difficultés, et on n’aurait plus d’échecs projet. Pourtant, c’est toujours le cas. Malgré des études de cas prouvant que la méthodologie ou le framework fonctionne.
La vérité, c’est qu’une méthode peut très bien fonctionner pour un projet particulier, dans un secteur d’activité bien ciblé, pour une entreprise précise, et surtout dans un contexte unique.
Mais transposez cette méthode sur un autre projet, et ça ne fonctionne pas. Idem si vous la déployez chez un autre client, dans un autre secteur d’activité, etc.
Ce qui fonctionne dans un cas ne fonctionne pas dans l’autre. C’est ce qui est frustrant en gestion de projet. Mais aussi ce qui est passionnant.
A la question « Quelle est la meilleure méthodologie de gestion de projet ? », je réponds toujours :« ça dépend ».
Dans certains cas, des frameworks agiles tels que Scrum sont particulièrement adaptés.
Dans d’autres, je vais préférer l’utilisation de Prince2, ou de PMI-PMP. Dans d’autres encore, je vais m’appuyer sur une méthodologie maison.
Tout est question de contexte.
9 ) Il faut éviter le conflit à tout prix
Le conflit, c’est mal. Il faut tout faire pour éviter d’en arriver là.
L’écrasante majorité des chefs de projet sont d’accord avec cette affirmation. Elle n’en est pas moins erronée.
L’origine de ce mythe vient d’une incompréhension profonde de ce qu’est un conflit. On s’imagine souvent que des personnes en conflit s’invectivent, n’arrivent plus à se parler sans s’insulter et sont prêtes à en venir aux mains.
C’est vrai, c’est un conflit. Mais celui-ci est hors de contrôle. C’est trop tard pour agir.
Prenons un autre exemple. Lorsque deux experts ne sont pas d’accord et recommandent deux solutions différentes pour atteindre les objectifs du projet, n’est-ce pas un conflit ?
Vous ne pouvez pas choisir les deux options. Vous êtes obligé de trancher. C’est la solution A ou la solution B. Ces personnes sont en désaccord. Et vous devez trancher.
Ça m’a tout l’air d’un conflit.
En réalité, les conflits sont quasi quotidiens. Décisions à prendre, incompréhensions, désaccord sur les attentes client, problèmes à régler, …
Avoir des conflits au sein de son équipe projet ou avec les parties prenantes est sain. Cela permet d’expliciter les zones de flou, de clarifier les objectifs et les attendus, mais aussi de lever les non-dits.
C’est de ne pas en avoir qui devrait vous inquiéter.
10 ) Un projet réussi est un projet livré dans les temps et le budget
On entend souvent qu’un bon projet, c’est un projet réalisé dans les temps et dans le budget. Mais c’est une mauvaise interprétation de la notion du triangle d’or, vu en chapitre 6. L’aspect qualité est totalement passé sous silence.
En réalité, un projet réussi, c’est un projet qui répond avant tout aux besoins et attentes du client, et pour lequel un client est satisfait.
Je m’explique.
Pour un projet événementiel, si vous prenez du retard, si vous dépassez l’échéance limite, vous êtes mort.
Parce qu’un événement, une fois planifié, ne peut plus se décaler dans le temps. Le facteur temps est donc primordial.
Pour un projet d’acquisition et fusion d’une entreprise, c’est le facteur budget qui sera le plus important.
L’opération doit être rentable, mais pas besoin de se précipiter et de mal faire les choses.
Enfin, pour un projet de migration informatique, le facteur primordial est la qualité.
On fait une migration en production, ce qui implique que la moindre erreur a des répercussions importantes sur la société.
Avec une erreur de manip’, on peut mettre à l’arrêt des milliers de salariés. On va donc préférer prendre le temps nécessaire pour que l’opération se passe sans accroc, quitte à prendre un peu de retard ou dépasser le budget.
Bien sûr, idéalement un projet devra respecter et les échéances, et le budget, et la qualité attendue.
Mais un projet réussi, c’est avant tout un client satisfait. Ce qui signifie respecter les engagements concernant le ou les critères les plus importants.
Et les trois ne peuvent pas l’être en même temps.
11 ) Les logiciels de gestion de projet sont indispensables pour réussir
Un logiciel de gestion de projet, aussi complet soit-il, est aussi efficace que votre processus de gestion de projet.
Autrement dit, si vous misez tout sur un outil sans réfléchir avant à la manière de gérer vos projets, vous courrez au désastre.
Lorsqu’on m’approche pour savoir quel est le meilleur logiciel de gestion de projet, mon conseil est systématiquement le même :
Commencez par utiliser des modèles Word, Excel, et PowerPoint, testez et standardisez votre méthode de gestion de projet.
A partir de là, une fois que vous aurez les idées claires sur comment vous souhaitez travailler, des outils se démarqueront d’eux-mêmes.
Si vous décidez de le faire à l’envers et de tout de même choisir l’outil avant de cadrer votre besoin, sachez que vous ferez face à plusieurs difficultés :
- Les équipes ne s’approprieront pas l’outil.
Un outil qui n’est pas adapté n’a aucune chance d’être apprécié des équipes. Elles l’utiliseront à contrecœur, ou contourneront son usage. - Des fonctionnalités essentielles n’existent pas ou coûteront un bras pour les développer.
Vous vous rendez compte après coup qu’il vous manque une fonctionnalité essentielle pour travailler. Manque de bol, elle n’est pas disponible dans l’outil. Si l’éditeur est sympa, il vous proposera un développement spécifique, par contre ça coûtera bonbon. - Vous serez contraints par l’outil.
Vos processus s’adapteront à l’outil, et seront donc inadaptés par rapport à votre manière de travailler. Alors que c’est plutôt l’inverse qui devrait se produire : c’est l’outil qui doit s’adapter à vos processus.
12 ) Tout le monde peut gérer un projet
Tout le monde peut devenir chef de projet si l’envie est là. Mais tout le monde ne peut pas gérer un projet.
Les techniques de gestion de projet sont nombreuses, et doivent s’adapter au projet et au contexte, pour éviter de cramer du gaz inutilement.
Et ça, ça ne s’invente pas, ça demande de l’expérience, mais aussi de se former et de s’ouvrir constamment à de nouvelles manières de faire.
Le piège en entreprise, c’est de confier le pilotage de projets stratégiques à des experts du métier, qui connaissent certes très bien leur domaine d’activité, mais qui n’ont aucune idée de comment mener un projet à terme.
Alors qu’il faudrait confier ce type de projets à des chefs de projet expérimentés, qui eux vont s’appuyer sur l’expertise des spécialistes métiers.
Souvent, on me rétorque que « jusqu’à maintenant, on s’en est toujours sorti, on a toujours réussi à mener nos projets à bout, alors pourquoi changer ? ».
Oui, c’est sur, on arrive toujours à nos fins à un moment donné. Mais à quel prix ?
- Combien aura coûté ce fameux projet ?
- Combien de temps cela a t-il pris de le sortir ?
- Le résultat est-il à la hauteur des attentes ?
- La motivation des équipes est-elle intacte ?
J’ai entendu ce discours maintes et maintes fois, notamment dans les administrations publiques, et le constat que j’ai pu faire derrière était plutôt amer :
- La durée du projet peut facilement être divisée par deux avec la bonne approche.
- Le budget a systématiquement explosé.
- Les informations sur le projet sont floues ou brouillonnes.
- Le chef de projet s’est cramé les ailes et est au bout du rouleau.
- Les collaborateurs sont démissionnaires, démotivés, désengagés.
- Le résultat est toujours loin des ambitions du départ.
- La résistance au changement en interne est forte.
- Tout le monde a l’impression d’avoir fait des efforts de dingue pour accoucher d’une souris.
Donc non, tout le monde ne peut pas gérer un projet. Car il ne s’agit pas uniquement de faire un planning et de suivre une liste de tâches.
Cela nécessite de comprendre les techniques et outils de communication, de gestion de projet, de management des risques, … Mais aussi de se former et d’avoir de l’expérience.
13 ) Au premier échec, votre carrière de chef de projet est terminée
C’est une peur très fréquente chez les chefs de projet juniors. Et ça se comprend.
Mais elle n’est pas fondée.
On part tous du principe qu’en gestion de projet, il n’y a pas le droit à l’échec. Si le projet foire, c’est forcément de la faute du chef de projet, qui est mauvais.
Un projet qui part dans le mur et ça y est, c’est terminé, votre carrière est fini, et vous êtes bon pour pointer chez pôle emploi (france travail maintenant) pour supplier de vous payer une reconversion professionnelle.
Oui mais non, ça ne marche pas comme ça.
Des échecs retentissant, on en a tous eu. Moi le premier. Et pourtant je suis toujours là, et on me paye pour mon expertise.
Il existe de nombreux facteurs d’échecs en gestion de projet, qui peuvent expliquer le plantage d’un projet.
L’inexpérience ou l’incompétence du chef de projet en fait bien sûr partie, mais l’écrasante majorité du temps, il n’est pas en cause.
Un projet a plus de chances de se planter lorsque les experts ne se responsabilisent pas, lorsque les parties prenantes ne sont pas engagées ni impliquées dans le projet, lorsque les attentes sont irréalisables ou que les moyens ne sont pas à la hauteur des ambitions, ou encore que le client change d’avis comme de chemise et ne vous laisse pas le choix.
Les échecs sont extrêmement formateurs, et forgent les chefs de projet.
Le pire projet que j’ai vécu a été paradoxalement le plus formateur. Même si ça n’a pas été de tout repos.
Je comprends aujourd’hui quels sont les mécanismes qui nous ont mené droit dans le mur.
Je sais les reconnaître, et je peux maintenant alerter en avance mes clients lorsque cela se produit ou est en passe de se produire.
Je ne connais aucun chef de projet expérimenté qui a réussi tous ses projets et n’a vécu aucun échec.
D’ailleurs, celui qui me l’affirme haut et fort, c’est soit qu’il n’est pas encore assez expérimenté, soit qu’il est un menteur.
Et en entretien d’embauche, c’est précisément ce que je vais aller creuser : vos échecs, et les leçons que vous en avez tiré.
14 ) Le chef de projet doit être un expert dans le secteur d’activité concerné
Un chef de projet ne doit pas obligatoirement être un expert dans le domaine concerné.
Je ne le recommande d’ailleurs pas, car il pourrait facilement tomber dans le piège de l’expert.
Il n’y a rien de pire qu’un chef de projet qui prend la casquette de l’expert et fait le travail à la place de son équipe projet. Il n’est pas payé pour ça. Et ça se fait au détriment du pilotage du projet.
On peut être un spécialiste et se concentrer sur l’opérationnel, ou être chef de projet et se concentrer sur le pilotage global du projet.
Mais les deux à la fois, ce n’est pas possible.
Même pour un slasheur ou un HPI (Haut Potentiel Intellectuel). Il y a forcément une des deux activités qui pâtit de l’autre.
Par contre, je vous l’accorde, avoir un minimum de connaissances dans ce domaine est un avantage : on sait de quoi on parle, et on parle le même langage que l’équipe projet.
Ça facilite les échanges, la communication, et la collaboration. Mais, et j’insiste sur ce point, ce n’est pas indispensable pour mener un projet à bien.
On dit souvent qu’un bon expert ne fait pas forcément un bon manager. C’est tout aussi vrai pour un chef de projet : un bon expert ne fait pas forcément un bon chef de projet.
C’est même souvent l’inverse.
15 ) La majorité du temps, un chef de projet doit traiter de l’administratif
On voit souvent le job de chef de projet comme celui d’un gratte-papier, drogué à l’administratif.
On collectionne des centaines de documents Word, Excel et PowerPoint, on passe son temps les yeux rivés sur un tableau Excel, à rédiger des comptes-rendus ou des procès-verbaux.
Ce mythe vient d’une méconnaissance de ce qu’est la gestion de projet.
Être chef de projet, c’est avant tout un job de terrain. Votre objectif est de mener le projet à bien, afin d’obtenir les gains attendus.
Pour cela, vous êtes au contact des experts métiers au quotidien, vous échangez régulièrement avec les parties prenantes, vous suivez l’avancée du projet et des tâches, …
On est loin du mythe du chef de projet coincé dans sa tour d’ivoire à remplir de la paperasse toute la journée.
Ceci dit, la documentation est très importante en gestion de projet. Tout (ou presque) doit être tracé à l’écrit.
Une réunion doit donner lieu à un compte-rendu. Les décisions doivent être tracées. Les problèmes doivent être historisés. Les risques doivent être identifiés.
Les documents doivent être versionnés, afin de pouvoir retrouver dans l’historique une ancienne version, et comprendre comment le projet a évolué. Les validations de livrables doivent donner lieu à des procès-verbaux.
La documentation est importante. Mais le chef de projet ne doit pas y passer 90 % de son temps.
16 ) Être chef de projet, c’est faire des heures sans les compter
Pour être chef de projet, il faut être prêt à faire 70 heures par semaine.
Il faut arriver le matin avant tout le monde pour faire ce que l’on a pas eu le temps de faire la veille (rédaction de compte-rendu, envoi de mails, …), et partir le soir après 20h, le temps de traiter les dernières urgences.
Ça, c’est la conception du métier dans l’imaginaire collectif.
Et si je vous disais qu’on peut gérer des projets complexes, faire face à des imprévus, et pourtant travailler de 9h à 18h, avec deux heures de pause le midi, afin de faire du sport. Vous me croyez ?
C’est pourtant ce que j’ai fait en tant que salarié pendant des années.
On peut être productif, s’agiter et s’occuper toute la journée à faire des tâches qui n’ont aucune importance.
On s’occupe à être improductif. J’appelle ça le syndrome de l’éolienne : on brasse de l’air, puis on agite les bras en voyant tout ce qu’il reste à faire.
La clé pour être maître de son temps, c’est de prioriser les actions, et d’agir là où l’on peut apporter le plus de valeur en tant que chef de projet.
Et de limiter les distractions : pas de messagerie instantanée, pas de mails toute la journée, pas de téléphone qui sonne à tout bout de champ.
On se fixe 2 ou 3 créneaux dans la journée pour traiter ça, et le reste du temps, on se concentre sur le pilotage du projet.
Idem pour les réunions : on ne planifie jamais de réunions qui s’enchaînent jusqu’à couvrir toute la journée.
Si je dois participer à des réunions, c’est uniquement sur une demi-journée.
L’autre demi-journée est réservée à la rédaction des comptes-rendus, et le suivi et le pilotage du projet.
17 ) Le chef de projet a la réponse à tout
On m’a dit une fois qu’être chef de projet, c’était gérer les problèmes des autres, et régler ce que personne ne voulait traiter.
Ça, c’est le syndrome du super-héros, où le chef de projet est LE sauveur et a réponse à tout. Mais la réalité est toute autre.
Le chef de projet est le garant de la réussite du projet. Mais il n’a pas vocation à régler tous les problèmes rencontrés.
Son job, c’est de s’assurer que le projet avance, et de mettre de l’huile dans les rouages grippés.
Il doit donc échanger avec les experts, comprendre les problématiques rencontrés, potentiellement émettre des recommandations, et agir sur des éléments à son niveau (problème organisationnel, conflit ou incompréhension avec le client par exemple).
18 ) Ne jamais arrêter un projet qui a commencé
Il y a une croyance populaire qui dit qu’une fois le projet lancé, on doit le mener jusqu’au bout. C’est faux.
Ce mythe vient de l’aversion à la perte, un biais bien connu et qui touche tout le monde, y compris les dirigeants d’entreprise.
Imaginez : vous venez d’injecter 10 millions d’euros dans un projet qui ne porte pas ses fruits et qui n’arrive pas à sortir.
Si vous arrêtez ce projet maintenant, ces 10 millions d’euros seront une pure perte.
Alors qui si vous réinjectez à nouveau de l’argent dans le projet, vous pourriez potentiellement être gagnant. On est tous tenté de continuer, car on a trop investi pour ne pas réussir.
Mais le fait est que si vous aviez arrêté maintenant ce projet mal ficelé, vous auriez perdu 10 millions d’euros.
Si le projet se retrouve dans le mur dans deux ans, vous perdriez 30 millions d’euros.
Il faut reconnaître ce biais d’aversion à la perte en gestion de projet, et être lucide sur les chances de réussite du projet.
Ensuite, sachez que toutes les méthodologies de gestion de projet incluent des mécanismes permettant d’arrêter prématurément un projet, à n’importe quel moment, soit parce qu’il coûte trop cher, soit parce qu’il n’est plus rentable, soit parce qu’il n’a plus de raison d’être, soit parce que le résultat actuel est satisfaisant en l’état.
19 ) Tout est une question de chiffres
En entreprise, il est courant de prendre des décisions en s’appuyant sur des faits, des statistiques et des études chiffrées.
Les émotions et l’instinct n’ont pas leur place autour de la table.
On préfère collecter des informations pendant quelques semaines ou mois supplémentaires avant de prendre une décision éclairée, plutôt que de se précipiter et de faire le mauvais choix.
En gestion de projet, c’est différent.
Les décisions doivent se prendre rapidement, pour éviter de bloquer le projet, sur la base d’informations parcellaires, incomplètes et non vérifiées.
Bien sûr, on s’appuie sur des faits et des chiffres, mais ce n’est pas toujours possible.
Parfois, on est obligé de peser le pour et le contre entre deux options sur la base d’hypothèses non vérifiées. Parfois, on agit par intuition.
On se base sur les informations à notre disposition à un instant t pour faire avancer le projet. Et on adapte ensuite en fonction des résultats.
En gestion de projet, on n’a pas le temps de se poser et de collecter des statistiques pendant 3 mois avant de décider quoi faire. Tout n’est pas qu’une question de chiffres.
20 ) L’agilité est LA réponse à tous les problèmes
En entreprise, l’agilité est sur toutes les lèvres. A entendre les chefs d’entreprise, toutes les sociétés sont agiles, de la TPE de 5 personnes à la multinationale de 80 000 personnes.
Être agile, ça permet d’être plus flexible, de s’adapter en cours de route aux évolutions du besoin ou du marché, et d’être plus efficace. C’est la solution moderne à tous les problèmes.
En résumé, soit on est agile, soit on est fragile.
Sauf que les méthodes agiles ne sont pas adaptées à tous les projets, ni tous les contextes. Livrer une application informatique par incrément, des petits bouts fonctionnels d’application que l’on améliore avec le temps, ça fonctionne bien.
Faites de même avec un avion de ligne qui fait voler des passagers, et là ce n’est pas la même.
Adopter l’agilité dans ce contexte serait suicidaire, et pourrait poser de sérieux risques de sécurité.
L’agilité n’est donc pas la solution moderne à tous nos problèmes de gestion de projet. Cette approche est plutôt révélatrice, et a même tendance à les amplifier. Si l’organisation n’est pas prête à traiter ces problèmes à bras le corps, c’est la catastrophe assurée.
