La gestion de projet est souvent réduite à ses dimensions techniques: planification, suivi, reporting. Pourtant, une part croissante du rôle de chef de projet consiste à développer les compétences de son équipe. Quand un membre de l’équipe ne maîtrise pas l’estimation, quand un autre peine à structurer ses comptes rendus, quand un troisième évite les interactions avec les parties prenantes, la réponse n’est pas toujours de faire à leur place: c’est de les accompagner dans leur progression.
Coaching et formation, deux logiques distinctes
La formation transmet des connaissances de manière structurée: un formateur enseigne un contenu à un groupe de participants. Le coaching opère différemment. Il part de la situation spécifique de l’individu, identifie l’écart entre sa pratique actuelle et le niveau attendu, puis l’accompagne dans la réduction de cet écart par la réflexion et l’expérimentation.
Le référentiel de compétences ICB4 de l’IPMA (International Project Management Association) inclut explicitement le développement des personnes parmi les compétences comportementales du chef de projet. Ce n’est pas un ajout cosmétique: c’est la reconnaissance que la performance du projet dépend directement de la capacité du chef de projet à faire progresser son équipe.
En pratique, la différence entre un chef de projet qui forme et un chef de projet qui coache se manifeste dans la manière de traiter une erreur. Le formateur explique la bonne méthode. Le coach pose des questions: “Qu’est-ce qui t’a conduit à cette estimation? Quelles hypothèses as-tu posées? Que ferais-tu différemment la prochaine fois?” L’objectif est de développer l’autonomie de raisonnement, pas de créer une dépendance au chef de projet.
Le modèle GROW appliqué au contexte projet
Parmi les cadres de coaching structurés, le modèle GROW développé par John Whitmore offre une structure simple et applicable en contexte projet. L’acronyme désigne quatre étapes: Goal (objectif), Reality (situation actuelle), Options (possibilités d’action) et Will (engagement concret).
Prenons un exemple courant. Un chef de projet constate qu’un membre de son équipe produit des rapports d’avancement systématiquement incomplets. Plutôt que de corriger les rapports lui-même ou d’envoyer un modèle de rapport, il structure un échange selon le modèle GROW. Goal: quel niveau de qualité vise-t-on pour ces rapports? Reality: qu’est-ce qui, dans le processus actuel de rédaction, produit des rapports incomplets? Options: quelles approches permettraient d’améliorer la situation? Will: quelle action concrète le collaborateur s’engage-t-il à mettre en place dès le prochain rapport?
Autre exemple: un membre d’équipe qui évite systématiquement le contact direct avec les parties prenantes (stakeholders) et passe par le chef de projet comme intermédiaire. Goal: quelles interactions devrait-il gérer en autonomie? Reality: qu’est-ce qui le freine dans ces interactions? Options: un accompagnement progressif, d’abord en binôme avec le chef de projet puis en autonomie? Will: sur quelle interaction précise s’engage-t-il cette semaine?
Ce type d’échange prend dix minutes, là où la correction manuelle d’un livrable en prend cinq. Mais il produit un changement durable là où la correction produit une dépendance.
La résistance au changement, obstacle prévisible
Quand un chef de projet tente de faire évoluer les pratiques de son équipe, la résistance est un phénomène normal et prévisible. Les professionnels qui gèrent des projets depuis des années ont développé des habitudes, des raccourcis et des zones de confort. Leur demander de changer de méthode revient à leur demander de redevenir temporairement moins performants, le temps d’intégrer la nouvelle pratique.
Cette résistance n’est pas un signe d’incompétence ou de mauvaise volonté. C’est une réaction naturelle à la perturbation d’un équilibre fonctionnel. Le chef de projet qui en tient compte ajuste son approche: il explique le pourquoi du changement avant le comment, il accepte une période de transition où la performance peut temporairement baisser, et il fournit un accompagnement individualisé plutôt qu’une directive collective.
La confiance comme prérequis
Le coaching en contexte projet ne fonctionne que si une relation de confiance existe entre le chef de projet et les membres de l’équipe. Un professionnel qui se sent jugé ou évalué ne s’ouvrira pas sur ses difficultés. Un collaborateur qui craint que ses erreurs soient remontées à la hiérarchie ne demandera pas d’aide.
Construire cette confiance prend du temps et passe par des actes concrets: reconnaître ouvertement ses propres erreurs, traiter les erreurs de l’équipe comme des opportunités d’apprentissage plutôt que comme des fautes, donner du feedback régulier et équilibré (pas seulement quand quelque chose ne va pas), et respecter la confidentialité des échanges individuels.
Quand le coaching atteint ses limites
Le coaching n’est pas une solution universelle. Il suppose que le professionnel dispose d’un socle de compétences suffisant pour progresser par la réflexion et l’expérimentation. Un membre d’équipe qui n’a aucune connaissance de la gestion des risques ne progressera pas par le coaching seul: il a d’abord besoin d’une formation structurée qui lui fournisse les bases conceptuelles.
De même, le coaching requiert du temps et une disponibilité que le chef de projet n’a pas toujours. Dans un projet sous pression, avec des délais serrés et des ressources limitées, prendre le temps de coacher chaque membre de l’équipe peut sembler un luxe. La clé est de considérer cet investissement sur la durée: une équipe qui gagne en autonomie libère progressivement le chef de projet des tâches de supervision et de correction.