Comment être un bon chef de projet et réussir une bonne gestion de projet ?
Pour répondre à cette question, j’ai le plaisir de recevoir Illia Racunica, chef de projet depuis plus de 15 ans.
Illia va vous donner ses conseils pour bien gérer un projet, ainsi que les compétences clés d’un bon chef de projet.
Sommaire de l'article
Conseil N°1 – Comprendre le besoin du métier au delà de l’expression de besoin
On dit souvent que
- modifier les caractéristiques d’un projet en phase de cadrage coûte 1,
- modifier quelque chose en cours de projet coûte 10,
- mais modifier quelque chose une fois le projet lancé coûte 100.
Pour être un bon chef de projet, il faut tout d’abord bien comprendre le besoin du métier pour éviter de revoir son projet en cours de route.
Un cahier des charges ou une expression de besoin pour cadrer une fonction, la mise en place d’un outil… ne sont pas suffisantes pour pouvoir comprendre le besoin du métier.
Pour savoir exactement ce qu’il faut mettre en place, il faut discuter avec le métier.
C‘est à dire interroger les opérationnels ou encore aller rencontrer les personnes sur le terrain.
Si cela est nécessaire, le chef de projet doit se déplacer chez les futurs utilisateurs du projet et s’efforcer de comprendre comment ils s’en serviront.
Cela permet de reformuler et comprendre tout ce qui est dans l’expression de besoin, parce que souvent, il y a un décalage entre l’expression de besoin ou le cahier des charges, et le besoin réel.
Les causes de ce décalage sont multiples :
- Difficulté du métier à exprimer son besoin
- Mauvaises interprétations du besoin par le rédacteur de l’Expression de Besoin
- Les à priori du métier sur une solution technique (favorable ou défavorable) alors qu’il a un besoin fonctionnel
- L’expérience du chef de projet qui peut se baser sur ses expériences passées
- …
Cela explique une partie pourquoi il y a fréquemment un décalage entre le projet livré et les besoins dans un projet informatique.
On peut livrer après plusieurs semaines de travail un projet qui est un exploit technique et qui ne satisfait absolument pas le métier parce qu’il ne correspond pas à son besoin réel.
Je vais vous raconter une de mes “mauvaises expériences” qui m’a sensibilisé à ce sujet :
- J’ai reçu des spécifications techniques (et pas une expression de besoin) pour du Monitoring Temps Réels pour des manageurs de plateaux d’un centre d’appels.
- Nous devions mettre à disposition une application qui s’abonne à des messages d’un “Bus d’évènements” et qui devait calculer des indicateurs.
- Les spécifications précisaient d’où nous devions récupérer ces évènements.
- J‘ai réalisé ce projet, mais il n’a jamais été mis en production parce qu’il ne servait à rien pour le métier : nous ne mesurions pas les bons indicateurs et les indicateurs souhaités par le métier ne pouvaient pas se mesurer avec les briques utiliser dans ce projet
C’est l’erreur classique du chef de projet : ne pas vérifier le besoin métier.
Un simple rendez-vous avec les personnes du métier aurait montré quel était besoin et que notre conception initiale ne pouvait pas y répondre.
C’est pourquoi, pour devenir un bon chef de projet, il est indispensable de discuter avec les personnes du métier, de faire des ateliers afin de bien comprendre les vrais besoins.
Il faut organiser ces ateliers “métier” en plus des réunions techniques pour bien énumérer les attentes et les besoins.
Par exemple, pour la gestion de projets dans des centres d’appels, il faut aller sur les plateaux pour voir ce qui se passe réellement.
On peut même se mettre en double écoute avec les agents pour voir comment ils travaillent.
Cette méthode est trop peu souvent appliquée, le chef de projet se basant sur l’expression de besoin initiale et/ou le cahier des charges en supposant que le problème a été bien analysé et compris… mais ce n’est pas toujours le cas.
Conseil N°2 – Mettre en place un planning
Lorsqu’on est en mode projet, contrairement à un projet déjà en production, on fait souvent quelque chose de totalement nouveau.
Donc l’évaluation du projet global et d’une simple tâche est toujours quelque chose de difficile, un peu empirique, avec une certaine marge aléatoire.
Le métier va toujours exiger des délais livraison très courts, mais il faut savoir proposer des délais réalistes pour ne pas donner d’insatisfaction surtout si la mise en production à des conséquences organisationnelles.
Si la mise en production nécessite l’intervention d’un certain nombre d’astreintes, un certain nombre d’intervenants qui coûtent cher… le décalage d’une mise en production peut s’avérer coûteux.
Ainsi, il faut savoir proposer un calendrier qui soit raisonnable pour deux raisons
- d’une part, déjà pour respecter les délais
- d’autre part, pour ne pas épuiser les équipes.
Lorsque les usagers du produit doivent être formés et si on les forme trop tôt ou trop tard, ils ne sauront plus utiliser l’outil au moment où l’on va les livrer l’outil.
Le chef de projet doit également s’efforcer de préserver ses ressources, c’est-à-dire qu’il doit proposer un calendrier raisonnable pour préserver ses équipes d’un stress et d’une pression trop importante.
Epargner ses équipes est aujourd’hui crucial dans le métier de chef de projet, car on est dans une période où le turnover est important.
Si pour respecter des délais, un technicien, un développeur, un testeur… doit travailler 10 à 12 heures par jour, il y a le risque de démotivation et de démissionne au pire moment.
Et à ce moment-là, il y aura une perte de connaissance dans le projet.
Il ne s’agit pas uniquement d’un retard de 15 jours, mais un retard de 3 mois le temps de trouver une nouvelle personne et de la former.
Une ressource qui dure deux ou trois ans sur sa mission, permet d’avancer beaucoup plus qu’une ressource qui va partir au bout de 3 à 6 mois.
Les périodes de rush ne doivent pas durer plus de 15 jours de manière intensive, et sur une période de trois mois.
Conseil N°3 – Savoir dire non !
Ce n’est pas facile de dire “non” en tant que chef de projet, car on a un client en face, c’est plus facile de dire oui que non…
Pourtant, un bon chef de produit doit apprendre à dire non à son client, en expliquant bien entendu pourquoi.
Quand est-ce qu’on dit non, quand est-ce qu’on dit oui ?
Il y a d’abord des contextes où il est très difficile de dire non, lorsque par exemple le projet a un impact pour la production.
Il faut trouver une solution vite, et donc on ne peut pas temporiser de trop.
Dans les autres cas, une des clés est de savoir hiérarchiser les demandes et apprendre aux clients à hiérarchiser ses besoins.
Il existe des projets, où lorsqu’on livre un nouveau produit, il n’y a pas vraiment une nécessité urgente.
Il y aura toujours des projets prioritaires, il faut savoir arbitrer par rapport au projet qui techniquement peuvent être décalés ou ceux qui ne peuvent pas être décalés.
Le responsable qui finalement arbitrera (en général ce n’est pas le chef de projet) doit avoir suffisamment d’autorités pour que les différentes parties acceptent sa décision.
Une petite astuce consiste à poser la question via Teams, Slack… à ses collègues, afin d’apporter une réponse en session.
Conseil N°4 – Prioriser les tâches
Le rôle du chef de projet, c’est de savoir ce qui est vraiment important pour le projet, et de concentrer son équipe sur ce qui est important pour le client, et pour l’avancement du projet.
Il faut donc prioriser et avoir un “backlog” des demandes en cours.
Par exemple avec les priorisations 0,1,2,4 et 5 des actions, on peut choisir ce qu’il faut faire ou pas.
Pour aller plus loin, vous pouvez consulter ce dossier avec les 6 étapes pour bien gérer un projet.
Quelle est ton astuce préférée de chef de projet ?
Mon astuce principale consiste à prendre des notes pendant la réunion, parfois même directement dans le support de présentation.
Si vous affichez votre écran avec Teams, Zoom ou un autre outil de gestion de projet (voir cette liste)tout le monde voit ce que vous tapez, ce qui permet d’avoir une validation, mais surtout, il n’y a pas besoin de beaucoup de reformuler.
Dans l’idéal, il faut envoyer les notes dans le quart d’heure après la réunion, ou la demi-heure après la réunion.
Dans le but de mettre les idées bien en place, il peut être judicieux de reprendre ses notes le lendemain, mais je conseille d’envoyer un au plus tard au-delà de 2 jours.
Au delà, le risque de ne plus être envoyé avant la réunion, d’avoir des personnes qui n’avancent pas sur leurs actions…
