Rappelons qu’un projet est "une entreprise temporaire menée pour créer un produit, un service ou un résultat unique". En conséquence, nous avons besoin d’une équipe qui sera créée de manière unique et temporaire.
Le « chef » de projet, « project manager » devra mener à bien l’initiative. Le terme anglais de « manager » implique un rôle à responsabilité et une certaine autorité.
La complexité réside souvent dans le fait que cette autorité du chef de projet sur l’équipe n’est pas directe. La plupart du temps, chaque membre de l’équipe reporte à un supérieur hiérarchique.
De plus, le projet possède lui-même une hiérarchie composée par le sponsor et les membres du COPIL. Enfin, le projet peut faire partie d’un Programme ou d’un Portefeuille eux-mêmes gérés par d’autres managers.
Toute cette complexité peut créer des conflits, des « ingérences » dans les prises de décision au niveau projet.
Nous allons aborder ce sujet plus en détail en abordant les points suivants : rappel des types d’organisation, rappel des types d’autorité, les difficultés transverses et les difficultés verticales.
Types d’organisation
Voyons rapidement les différents types d’organisation que nous pouvons rencontrer.
Pour chaque type, la balance de pouvoir et de la distribution des responsabilités varient au sein de l'organisation :
Type d’organisation | Description | Rôle du Chef de Projet |
|---|---|---|
Matricielle faible | Le pouvoir est principalement détenu par les managers fonctionnels. Les membres de l'équipe continuent de travailler principalement dans leurs départements fonctionnels. | Le chef de projet a un rôle de coordination partiel et souvent part-time, avec peu d'autorité sur les membres de l'équipe. Le chef de projet agit comme un facilitateur pour la communication et la coordination entre les départements |
Matricielle équilibrée | Le pouvoir est partagé entre le chef de projet et les managers fonctionnels. Les membres de l'équipe sont partagés entre leurs responsabilités fonctionnelles et les tâches du projet. | Le chef de projet a une autorité modérée et travaille à temps plein sur le projet. Mais les décisions importantes nécessitent souvent l'approbation des managers fonctionnels. |
Matricielle forte | Le chef de projet détient la majorité du pouvoir et de l'autorité. Les membres de l'équipe sont principalement dédiés au projet et le chef de projet a une autorité significative sur les ressources et les décisions du projet. | Le chef de projet travaille à temps plein et dispose d'un bureau de projet qui inclut des fonctions telles que :
|
En plus des structures matricielles, il existe d'autres types d'organisation :
1) Organisation fonctionnelle
Ici, les membres de l'équipe travaillent exclusivement dans leurs départements fonctionnels, et il n'y a pas de chef de projet désigné.
Les projets sont gérés au sein des départements, et la coordination interdépartementale est limitée.
2) Organisation de projet
Ici, au contraire, tous les membres de l'équipe sont dédiés au projet, et le chef de projet a une autorité complète sur les ressources et les décisions.
Cette structure est souvent utilisée pour des projets complexes ou de grande envergure.
À la lecture de ces descriptions, il est évident que le type d’organisation influe considérablement sur l’autorité que possède le chef de projet et sa capacité à gérer certaines ingérences ou certains conflits.
Types d’autorité
Rappelons ici les différentes formes d’autorité qui existent et comment on peut les appliquer dans un contexte de gestion de projet :
Analysons cela plus en détails.
1) Légitimité
C’est l’autorité implicite d’un « chef de projet ».
Que cela soit le terme « chef » ou « manager », les deux évoquent un symbole d’autorité.
Implicitement, le chef de projet est le responsable du projet : il prend des décisions, gère un budget et reporte l’état du projet aux instances supérieures.
- En fonction du degré de maturité et du type d’organisation, cette légitimité est plus ou moins importante.
- Pour les membres de l’équipe projet, le responsable hiérarchique, qui est rarement le chef de projet, possède également une légitimité
- La légitimité venant du rôle n’est parfois pas suffisante
2) Référent
Nous nous basons ici sur la capacité d'un individu à attirer et à fidéliser les autres grâce à son charisme et ses compétences interpersonnelles.
C’est le « leader » à comparer au manager.
C’est, ou devrait être, une des qualités d’un chef de projet, entrant ici dans ce que l’on appelle souvent les « soft skills ».
- Une autorité parfois plus difficile à utiliser en début de carrière
- Même si certains la possèdent plus naturellement que d’autres, c’est une caractéristique qui se travaille, s’améliore, sous forme de formation ou de coaching
- C’est l’autorité qui fait la différence dans les contextes complexes et transverses !
3) Expertise
Elle provient des compétences ou de l'expertise d'un individu.
Dans le cas du chef de projet, on peut la scinder en deux types :
- L’expertise en gestion de projet : maîtrise de la méthodologie, expériences antérieures, capacité à expliquer ce qui est fait.
- L’expertise technique liée au sujet du projet.
La première est souvent liée à l’autorité « légitime » et l’autorité « référente » : un « bon » chef de projet arrive avec une réputation et des qualités qui confortent sa légitimité.
La seconde provient d’une expertise technique au sens large ; la personne en question a été un expert dans le domaine avant de devenir chef de projet.
Rappelons qu’une certaine approche de la gestion de projet préconise un certain agnosticisme : un chef de projet compétent doit pouvoir piloter n’importe quel sujet du moment qu’il soit bien entouré.
L’utilisation de l’expertise « technique » dans un contexte projet est à double tranchant :
Autant le fait de maîtriser le sujet facilite le travail, permet d’organiser les activités, mieux identifier les risques et comprendre les besoins des demandeurs, autant se substituer aux membres de l'équipe, faire du micro-management et/ou coacher les personnes pour leurs activités est contre-productif.
Le chef de projet devra utiliser cet avantage avec parcimonie : faciliter la communication, accélérer la compréhension du contexte, tout en laissant aux experts membres de l’équipe les responsabilités qui leur sont attribuées.
4) Par la récompense
Cette autorité est liée à la capacité d'un individu à offrir des récompenses, telles que des avantages, des promotions, des augmentations de salaire, ou des responsabilités accrues.
- Dans le cadre du projet, cette capacité est généralement réduite, et clairement définie au départ du projet, pour toute l’équipe.
- En contrepartie, les responsables hiérarchiques en possèdent beaucoup plus, essentiellement par l’intermédiaire des évaluations.
Participation du chef de projet aux évaluations :
En fonction des entreprises, il peut être demandé aux chefs de projet d’évaluer les résultats et performances des membres de l’équipe projet.
Ceci ne doit pas être considéré comme un moyen de distribuer des récompenses.
C’est plutôt une réalité : lorsqu'une personne passe l’essentiel de son temps à travailler à un ou plusieurs projets, qui mieux que le chef de projet peut évaluer ce qu’il fait et analyser son progrès ?
5) Par la coercition
Ici, nous parlons de la capacité à imposer des sanctions ou des punitions.
Plus pour référence qu’autre chose, elle est très peu utilisée dans le cadre de la gestion de projet.
Un recours en cas de problème de comportement inadéquat, et lorsque toutes les autres méthodes de gestion de personnes et de conflits ont échoué.
Comprendre la structure et les formes d’autorité est une chose. Mais sur le terrain, ces configurations donnent lieu à des situations concrètes, parfois délicates à gérer.
La suite de l’article aborde deux dimensions majeures de ces ingérences :
- Les tensions transverses, liées aux interactions entre départements ou responsables fonctionnels,
- Les pressions verticales, issues de la hiérarchie projet ou du sponsor lui-même.
Difficultés transverses : que peut faire le chef de projet ?
Les interactions horizontales entre les parties prenantes du projet donnent souvent lieu à des situations délicates.
Elles ne relèvent pas de conflits ouverts, mais prennent la forme de désalignements dans les contributions attendues.
Parmi ces difficultés, on peut citer :
1) Un manque de participation au projet
Cela peut se révéler de plusieurs manières :
- Certains membres de l’équipe ne participent pas au projet comme il avait été prévu. Ce qui engendre du retard.
- Certains membres de l’équipe ont des priorités conflictuelles qui les empêchent de se dédier correctement au projet, d’un point de vue « qualitatif » : manque d’implication.
Scénario classique, qui n’est malheureusement pas possible d’éliminer complètement.
Idéalement, au départ du projet, le plan de charge devrait être détaillé, non seulement quantitativement parlant que temporellement, ET devrait avoir été approuvé par le chef de projet ET les responsables hiérarchiques des membres de l’équipe.
Néanmoins, dans des contextes très dynamiques, une seconde validation est la bienvenue.
En effet, le plan de charge peut avoir été approuvé plusieurs semaines avant, et demande quelques réajustements.
Un autre cas est des difficultés de priorisation du côté d’un responsable fonctionnel : plusieurs demandes « prioritaires » peuvent arriver, créant un « goulot d’étranglement » en termes de ressources.
Ici, on peut conseiller les approches suivantes en fonction de la taille et de la criticité du problème :
Rappelons que tout ceci doit demeurer factuel, fournissant le plus d’informations possible en amont, et en suivant ensuite les procédures de gestion de modifications et de mise à jour de la documentation projet.
Le dilemme BUILD/RUN !
Nous l’avons tous vécu : une partie de l’équipe a des activités à la fois projet et opérationnelles.
Le postulat de départ est que l’Opération est prioritaire sur le projet, ce qui est raisonnable.
Maintenant, si les interruptions sont trop fréquentes, cela devient un problème de performance pour le projet.
Comment faire ?
- Assigner des ressources dédiées sur les activités critiques
- Collaborer étroitement avec les Équipes Opérationnelles pour accompagner de près leur besoin et créer un réel partenariat
- Augmenter l’autonomie des personnes en question en les laissant gérer plus librement leurs activités
2) L’influence des départements « techniques »
L’objet d’un projet est en général un produit ou un service qui sera ensuite utilisé, géré et/ou maintenu par un département de l’entreprise.
De plus, ce ou ces départements fournissent des personnes à l’équipe projet.
Le chef de projet doit équilibrer les besoins du projet avec les attentes des départements fonctionnels.
Parfois, l’importance et l’influence d’un département, d’un responsable fonctionnel ou d’un expert peuvent déstabiliser la bonne conduite du projet.
Un exemple classique est celui du déploiement d’un ERP.
En général, une entreprise possède un département ERP ou « Solutions et Applications » qui est responsable de l’accompagnement et du support du ou des ERP.
L’expertise se trouve dans ce département. L’autorité « d’expertise » vient de chez eux.
La tendance peut être à voir le responsable de ce département vouloir prendre l’essentiel des décisions et trop s’immiscer dans la vie du projet.
Quelques clarifications s’imposent :
Pour restaurer une dynamique de projet maîtrisée, certaines actions concrètes doivent être mises en œuvre :
- Rappeler les Rôles et Responsabilités de chacun et partager le RACI du projet.
- S’assurer que le périmètre du projet, les principales décisions, telles que l’architecture, ont été validées par le département en question.
- Rappeler que le rôle du chef de projet est de piloter le projet, en se basant sur la description fournie au départ.
- Communiquer, communiquer et encore communiquer, pour s’assurer que l’information atteint les principales parties prenantes de manière détaillée et en temps et en heure.
C’est dans ces cas de figure que les qualités de diplomatie, de capacité de négociation et de communication ont leur sens.
La double validation des temps projets :
Faire valider les temps de l’équipe projet à la fois par le chef de projet et par le responsable hiérarchique peut, au premier abord, apparaître comme exagéré.
C’est pourtant un excellent moyen, pour le chef de projet, de se rapprocher des managers fonctionnels et de pouvoir détecter rapidement des écarts.
3) Les conflits de rôle
Les conflits de rôle sont fréquents dans les équipes de projet où les membres proviennent de différentes fonctions ou départements.
Ces conflits peuvent survenir lorsque les membres de l'équipe reçoivent des directives contradictoires de leurs managers fonctionnels et du chef de projet.
Cela peut également venir d’écarts et de chevauchements de responsabilités dans les équipes.
1.1) Sources de conflits de rôle
Les conflits de rôle peuvent être causés par un désalignement entre les objectifs et les attentes des managers fonctionnels et celles du chef de projet.
Par exemple, un membre de l'équipe de R&D peut être confronté à des directives qui favorisent les objectifs du département R&D plutôt que ceux du projet.
Il peut également y avoir des interprétations quant à la définition d’un rôle au sein de l’équipe projet, sa limite de responsabilité et son interaction avec les autres membres de l’équipe.
Enfin, de manière plus diffuse, des conflits de personnalités, des niveaux d’expertise ou d’expérience peuvent également apporter des difficultés.
1.2) Impact des conflits de rôle sur la performance
Ce genre de conflits peuvent affecter la performance de l'équipe en créant de la confusion, du retravail, voire des oublis et en réduisant la motivation.
Les membres de l'équipe peuvent devenir moins engagés et moins productifs lorsque les directives ne sont pas claires ou incohérentes.
Cela peut également entraîner des retards dans l'exécution du projet et affecter la qualité des livrables.
1.3) Astuces pour gérer les conflits de rôle
Pour commencer, une chose simple :
Revoir en détail le RACI du projet, les responsabilités définies pour les groupes d’activités.
Cette approche permet de créer une lecture et une compréhension commune de l’équipe.
Ensuite, il faut investir dans la notion de collaboration, dans le renforcement de l’esprit d’équipe et la communication, ce qui permet de diminuer, voire de supprimer les petits conflits.
- Encourager la collaboration en établissant des objectifs communs, en favorisant un environnement de travail inclusif et en reconnaissant les contributions de chaque membre de l'équipe.
- Promouvoir l'innovation au sein de l’équipe projet pour mieux résoudre ce genre de difficultés.
Enfin, du côté du chef de projet, la formation en gestion des conflits et en communication interculturelle permettra de mieux se préparer pour résoudre les tensions et promouvoir un environnement de travail harmonieux.
Difficultés verticales : comment y faire face ?
Voici les cas classiques de difficultés verticales qui peuvent se présenter :
1) Changements de direction fréquents et mal communiqués
Un cas classique qui provient souvent de la hiérarchie du projet, COPIL ou Board.
Même s’il est aujourd’hui compréhensible qu’un projet est une entité dynamique qui évoluera tout au long de son cycle de vie, l’excès de changement, et surtout le fait qu’ils ne soient pas bien expliqués ou communiqués affectent considérablement la performance du projet.
Quelques exemples :
- Inclusion/Exclusion d’items au périmètre du projet
- Changement de sponsor
- Modification des dates clés, avec parfois des demandes d’accélération
2) Ingérence directe du sponsor dans le projet
Autant il est essentiel pour le chef de projet que le sponsor soit présent, autant l’excès de présence porte atteinte au bon fonctionnement :
- Modification de l’équipe projet par négociation directe avec certains responsables hiérarchiques.
- Remise en cause des décisions du chef de projet.
- Micro-management, vérification fréquente des détails.
Ici encore, il est important de rappeler à tous la gouvernance du projet, les rôles et responsabilités de chacun ainsi que le RACI du projet.
De plus, dans le cas de tentative de modification du périmètre du projet, l’ajout de fonctionnalités non prévues initialement par exemple, il est essentiel de revenir aux bases et rappeler la description du projet au départ, du budget associé.
Toute modification doit suivre la procédure de gestion des modifications.
Ce n’est pas parce que le sponsor est lui-même le ou l’un des approbateurs que le process en question ne doit pas être suivi.
Conclusion
En résumé, l'interférence de la hiérarchie dans la gestion de projet peut créer des défis et des complications significatifs.
La hiérarchie transverse des membres de l'équipe projet peut compliquer la communication et la collaboration, tandis que la hiérarchie directe du sponsor du projet peut influencer la gestion des attentes et l'alignement stratégique.
Pour anticiper et minimiser ces impacts, les chefs de projet doivent développer des compétences en communication, en gestion des conflits et en leadership, tout en revenant aux bases de la gestion de projet :
- description du périmètre du projet,
- approbation du plan de charge détaillé,
- divulgation du RACI du projet.
Ils doivent également être capables de comprendre les priorités et les objectifs de l’entreprise en tant que tel et s'assurer que leur travail s'inscrit dans ce cadre.
Recevez GRATUITEMENT le Guide Pratique du Chef de Projet Performant
* Suivez une méthodologie claire pour gérer vos projets de bout en bout
* Améliorez votre efficacité opérationnelle en utilisant les bons livrables au bon moment
* Suivez 25 conseils d'expert et arrêtez de subir les dérives
Vous recevrez régulièrement des contenus intéressants. Vos données seront en lieu sûr, nous détestons le spam sans doute autant que vous, et vous pouvez vous désinscrire à tout moment. Voir notre politique de confidentialité.
