[Chronique] Gestion de projets : le jeu des dix erreurs

Fort de son expérience de manager de transition, notre chroniqueur Thierry Adenis, met en évidence 10 erreurs récurrentes sur les projets de transformation d’envergure. Du « pas de souci, je gère en mode agile » jusqu’à l’oubli du « bon sens paysan », il passe en revue les moyens d’adresser ces problématiques qui traversent naturellement toute entreprise.

Cela fait près de dix ans que mon métier de manager de transition m’a amené à intervenir sur des projets d’envergure en difficulté, voire en perdition. Cela fait près de dix ans que je vois revenir les mêmes causes majeures de dysfonctionnement.

J’ai donc essayé de faire un focus sur les dix erreurs les plus fréquentes, et qui sont évitables, ou a minima dont l’impact peut être réduit, si elles sont bien abordées dès le début du projet. Bien entendu, un projet de taille significative reste un sujet complexe à gérer, et il est, de fait, unique par ses objectifs, son contexte, ses contraintes, ses moyens…

A lire aussi : [Chronique] Mais à qui appartient la transformation digitale ?

Le sujet de ce post n’est donc pas « comment réussir facilement son projet à tous les coups ». Ce serait prétentieux, simpliste, et surtout mensonger. Je l’ai conçu comme ma vision des problèmes récurrents de la gestion de projets, le but étant d’en faire une base d’échanges avec votre propre expérience.

Chaque sujet mériterait un post à part entière. Le but n’est donc pas d’être exhaustif sur chacun d’eux, mais de mettre en exergue les problèmes récurrents et d’identifier des pistes de réflexion pour en réduire les impacts.

1. Il n’y a pas de méthode idéale

« Pas de souci, je gère en mode Agile. » Combien de fois ai-je entendu cette phrase ?

Et, tout fier, le chef de projet nous explique (plutôt, nous récite) en long, en large et en travers, tout le wording et la comitologie de la méthode.

Je parle ici d’Agile, car très à la mode, mais ma remarque est valable pour toutes les méthodes. Si vous n’avez pas piloté de projets en mode Agile à 30 ans, vous avez raté votre vie de chef de projet.

Le souci est qu’une méthode n’est qu’un outil. Et qu’un outil ne porte aucune intelligence en lui-même. C’est ce que l’on va faire de l’outil qui va apporter l’intelligence.

Chaque type de méthode a une finalité, répond à des objectifs particuliers, dans un contexte donné.

Il faut donc employer la bonne méthode au bon moment du projet. Le pilotage d’un projet complexe peut conduire à utiliser plusieurs méthodes selon son cycle d’avancement.

Le bon chef de projet se doit donc de maîtriser plusieurs méthodes, tel un artisan qui possède plusieurs outils.

Or, très souvent, le chef de projet ne connaît qu’une seule méthode. De nos jours, c’est très souvent une méthode Agile. Il va donc l’employer, ou tenter de l’employer, pour tous les sujets.

Mais surtout, dans cette application à la lettre, il va manquer de recul.

Je prends souvent une analogie. Marc Madiot, directeur sportif de l’équipe cycliste de la FDJ, écrit dans son livre Parlons vélo  : « Les coureurs ont perdu le sens de la course le jour où on leur a mis des oreillettes. » Si je paraphrasais, je dirais que le chef de projet risque fortement de perdre le sens de son projet, et donc de son pilotage, s’il a le nez collé à sa méthode.

Je pense qu’il faut que le chef de projet construise sa propre méthode pour un projet donné, au sens où il va piocher dans sa connaissance, son expérience, des parties de méthodes qu’il a apprises et expérimentées, les conseils de tierces personnes, et déterminer ainsi quel va être le « système méthodologique » du projet. Une fois établi, ce système devra être partagé avec l’ensemble des participants.

Mais surtout, ce système ne doit pas être figé. Il doit être réinterrogé régulièrement, adapté, réexpliqué. En résumé, il doit vivre. Ce doit être un apporteur de valeur, non une contrainte.

Cela induit également qu’une entreprise se doit de former régulièrement les collaborateurs amenés à piloter des projets.

2. Chef de projet & TechnoFocus, deux entités opposées

Les projets à composantes IT ont pour but de déployer des solutions technologiques. Mais est-ce la seule finalité du projet ? Aucunement.

Comme développé dans de précédentes chroniques, la seule finalité d’une solution technologique est d’être bien utilisée. En réalité, un projet IT déploie des usages, et ces usages ne sont pleinement opérationnels que si l’ensemble des composantes liées fonctionnent. L’organisation, la gestion du changement, la formation, les processus…

Le problème vient souvent du fait que le chef de projet, d’autant plus s’il est issu de la DSI, se concentre essentiellement sur les livrables Produit. Donc sur la technologie.

Se pose alors la question primordiale : qui doit diriger un projet technique ?

Je considère que le chef de projet est avant tout un manager. Il doit donc posséder des qualités de leadership, de gestionnaire, de facilitateur, d’organisateur, de communicant, bien plus que des compétences techniques.

Dans de plus en plus d’entreprises, un collaborateur doit avoir dirigé un projet d’envergure avant de prétendre postuler un poste de direction. Cela fait partie de son parcours de formation.

Que ce soit un non-expert technique du sujet lui permettra de ne pas rentrer dans le détail de l’opérationnel, d’éviter de se mêler à des batailles d’experts. Le chef de projet doit être au-dessus de la mêlée afin de consacrer son énergie aux objectifs et engagements du projet. Autre effet positif : n’étant pas expert lui-même, il valorisera d’autant plus les idées et les actions de ceux-ci. Bien entendu, il ne faut pas passer d’un extrême à l’autre. Si je pense qu’il ne doit pas être expert, il doit néanmoins avoir une culture technologique générale afin de comprendre les divers sujets abordés.

Respecter les objectifs et maintenir la cohésion de l’ensemble des acteurs, voilà ce que l’on attend du chef de projet.

On revient donc sur la sempiternelle métaphore du chef d’orchestre, analogie qui reste toujours vraie. Les musiciens savent jouer, connaissent la partition. Mais, sans le chef d’orchestre, ils ne seront jamais synchronisés. Le rôle du chef d’orchestre n’est donc pas de dire aux opérationnels ce qu’ils doivent faire, mais de piloter l’enchaînement des actions et leur bonne temporalité. Idem pour le chef de projet.

3. Le sponsor, le compagnon salvateur du chef de projet

Lancer un projet d’envergure n’est pas un acte anodin pour une entreprise. Elle va engager des dépenses importantes, que ce soit en finance ou en ressources humaines, et elle en attend une plus-value ; mais surtout, la réalisation de ce projet va perturber le fonctionnement quotidien de l’entreprise. En effet, tout projet comporte une composante plus ou moins grande de transformation. Et une transformation, cela perturbe le quotidien de beaucoup de monde.

Le chef de projet va donc être un dérangeur d’habitudes. Il ne peut pas être seul à porter les diverses perturbations opérationnelles et organisationnelles induites par le projet. Comme le dit Vincent Liegey, « avoir raison tout seul, c’est avoir tort ».

Il doit donc trouver, dès le début du projet (phase d’étude), un sponsor. Plus le projet est important et plus il va induire de changements, plus le sponsor doit être puissant, au sens positionné dans les toutes premières strates organisationnelles de l’entreprise. Son soutien doit être infaillible. Dans les moments de doute, dans les mauvaises nouvelles, dans les décisions majeures à prendre, le sponsor sera le seul ami du chef de projet.

Dans mes divers projets, durant les périodes difficiles, j’ai rencontré les deux extrêmes, du « continuez à avancer, je vais gérer les mécontents » au « c’est embêtant VOTRE projet de transformation, il dérange les collaborateurs ». Une chose est sûre, dans l’un ou l’autre cas, vous ne travaillez pas dans les mêmes conditions.

J’en ai retenu une chose : je ne lance plus de projet de transformation sans m’être assuré de la qualité et du soutien de mon sponsor.

4. Le triangle d’or

Le triangle d’or du projet est défini par trois contraintes : le coût, le délai, la qualité.

Le rôle du chef de projet est d’équilibrer ces trois composantes tout au long du projet, notamment lorsque des problèmes apparaissent. Le triangle a été défini comme tel pour rappeler que ces trois éléments sont interdépendants les uns des autres.

À l’état initial, ces trois axes sont souvent à iso-importance. Le défi du chef de projet sera de les respecter tous.

Cela, c’est la théorie du départ. Si le projet se déroule selon le plan prévu, pas de souci.

Mais un projet rencontre souvent des problèmes. Le leader sera donc amené à prendre des décisions qui font que les trois axes ne seront pas tous atteignables dans les valeurs définies initialement.

Pour ma part, j’établis au départ une classification.

En premier, déterminer l’axe majeur, axe non négociable, celui qui est intangible. Un projet à forte contrainte financière (budget indépassable), un projet qui doit impérativement tenir le délai (ex. : contrainte réglementaire), un projet qui doit impérativement avoir un très bon niveau de qualité produit (ex. : industrie pharmaceutique).

En second, définir l’axe mineur, sur lequel on a une potentielle marge de manœuvre. En cas de problème majeur, on pourra rallonger le coût ou le délai, être un peu moins exigeant sur la qualité (gestion du risque).

Ce sont, pour ma part, des données « officielles » du projet, qui doivent être connues de l’ensemble des acteurs majeurs…

Ainsi, en cas de problème, le chef de projet peut actionner les négociations sur l’axe mineur. Le fait que celui-ci ait été identifié initialement comme tel permet d’accélérer les arbitrages et négociations, mais ne simplifie nullement cet exercice périlleux.

5. Le maître du temps

Combien de projets partent dans l’opérationnel dès la validation du besoin ?

Dans un planning projet, je n’ai jamais vu de phase de réflexion. On pose les crayons, on prend du recul, on réanalyse les composantes majeures, on échange. En résumé, on revient aux fondamentaux en se réassurant des enjeux et contrainte du projet.

Elle est différente de la phase de cadrage. Cette phase de réflexion est le premier pas de la phase opérationnelle. Le projet est validé, ses attendus sont définis, on a choisi les solutions technologiques, les contrats de sous-traitance sont signés. Tout est prêt pour se lancer dans la grande aventure.

Cette phase doit être courte et doit réunir les personnes clés et les ressources critiques (à l’identique du chemin critique). C’est le dernier débriefing avant le lancement.

Le principe est de savoir perdre du temps pour en gagner par la suite. Ces pauses de réflexion doivent émailler le projet dans ses moments clés. Elles permettent de se détacher quelques instants du quotidien opérationnel du projet et des tensions liées, pour réanalyser la situation et vérifier le cap.

Au cours du projet, le responsable connaîtra des phases d’accélération et des phases plus lentes. Il est indispensable de bien identifier ces phases et de les respecter. L’équipe projet ne peut pas être en permanence en vitesse maximale. Elle va s’épuiser.

Le rôle du chef de projet est ainsi d’être le maître du temps de son projet, et de ne jamais le subir.

S’il s’aperçoit qu’il le subit, il doit en tenir compte, et adapter son pilotage en prenant des décisions parfois fortes pour reprendre la main.

6. Les ressources

Les ressources sont le nerf de la guerre d’un projet. Si vous n’avez pas les bonnes ressources, au bon moment, sur les bonnes actions, votre projet est en risque.

Le problème est que les projets arrivent en supplément des activités habituelles des collaborateurs ; et comme le dit l’adage : les bons collaborateurs sont très occupés, les moins bons n’ont pas grand-chose à faire.

Alors, comment faire pour avoir les bonnes ressources ?

Tout d’abord, c’est évident mais pas systématiquement fait, il faut construire au plus tôt le Resource Breakdown Structure (RBS) du projet, qui va définir la structure des ressources humaines ; c’est-à-dire définir précisément les ressources qui interviendront par lots ou périmètres technico-fonctionnels, non en termes de noms, mais en termes de compétences (ressources génériques).

Puis vient le délicat travail d’y affecter des personnes. Je ne vais pas détailler cette phase qui est unique pour chaque projet, tant il y a de variables.

Mais je souhaite insister sur le fait qu’il convient de s’assurer que la personne ciblée pourra bien remplir la mission attendue sur le projet, ce qui présuppose que le besoin en ressources est fiable, et d’avoir validé que le quotidien actuel de cette même personne continuera à être opéré par un tiers. La fiche de mission, décrivant précisément le rôle, les tâches, les livrables, le planning de la personne le temps du projet, est un document RH trop peu utilisé.

Pour libérer les ressources clés, il convient parfois d’être très imaginatif : appel (classique) à de la prestation ou des intérimaires, retour de retraités, réduction d’une activité opérationnelle le temps du projet… Ne craignez pas de sortir du cadre, tant l’enjeu est stratégique et les conséquences coûteuses.

En conclusion, je dirais que tant que le plan d’allocation des ressources humaines n’est pas validé et que les ressources clés du projet ne sont pas officiellement réservées, lancer le projet est un acte fort risqué. Nombre de projets se retrouvent à l’arrêt ou en fort ralentissement (donc en fort retard au regard du planning prévu) de ce fait.

7. On ne gère bien que ce que l’on mesure

Cette phrase aux formes et auteurs multiples résume bien le sujet. On ne peut piloter un projet que par des faits. Il faut factualiser les engagements, savoir où en est réellement le projet, et connaître la véracité du reste à faire. La subjectivité est le pire piège. Comme le dit Sénèque : « Il n’y a pas de vent favorable pour celui qui ne sait pas où il va. ».

Mesurer, d’accord, mais mesurer quoi ?

Toute la performance du système de la mesure réside dans le choix des indicateurs. Ils doivent être clairs dans leur définition, simples à mesurer, simples à interpréter.

Pour qu’ils soient le plus pertinents possible, je pense que l’idéal est que ces indicateurs soient définis avec l’ensemble des acteurs (direction, DSI, directions opérationnelles, sous-traitants…). Chacune des entités doit se les approprier. Ils doivent être indiscutables et indiscutés.

Ne laissez jamais le chef de projet choisir seul ses indicateurs. D’une part, ils risquent de ne pas être tous pertinents, mais surtout, d’autre part, de ne pas être adoptés par les autres parties prenantes.

Si le projet est long et complexe, il faudra adapter les indicateurs aux différentes phases.

Une fois les indicateurs définis, reste le recueil des données qui vont les construire.

Je ne vais pas détailler le fait qu’il faut que les données soient vraies, et que le chef de projet doit s’en assurer tout au long du projet ; une évidence pas si évidente pour beaucoup de projets.

Mais j’insisterai sur deux points que je juge importants :

• Il ne faut pas que la partie « administrative » du recueil de l’information soit consommatrice de temps. Vos opérationnels doivent, en priorité, opérer. Ils doivent donc passer un minimum de temps à saisir l’information. Moins elle leur coûtera à saisir, plus elle sera juste et fraîche.
• Si vous voulez que vos opérationnels saisissent vite et bien les données brutes, il y a deux points importants : ils doivent comprendre l’intérêt pour le projet du temps qu’ils vont y consacrer, tant pour eux que pour l’entreprise, et surtout, ils doivent être impliqués dans le circuit de diffusion (si vous les citez en auteurs, c’est encore mieux). Non seulement cela les motivera, mais surtout ils trouveront du sens et de la reconnaissance à leur travail.

A lire aussi : Management : le principe de reconnaissance

8. Le risque

La gestion du risque est le processus qui permet d’identifier et d’évaluer les risques en vue d’élaborer un plan visant à minimiser et à maîtriser ces risques et leurs conséquences potentielles pour une entreprise (source : redhat.com, « What is risk management ? »).

La gestion du risque est un état d’esprit avant d’être un outil. Il s’applique sur tous les sujets demandant un pilotage, que ce soit personnel ou professionnel.

Je pense que l’on sous-estime ce processus, qui devrait être maîtrisé par tout un chacun quel que soit son métier, quelle que soit sa fonction. Comme très souvent avec les processus, on se focalise sur l’outil de gestion (savoir-faire), plutôt que sur les qualités qu’il permet de développer (savoir être).

La gestion du risque est l’amie du chef de projet. Son but opérationnel est de ne pas disperser son énergie et ses actes avec la même intensité sur l’ensemble des sujets du projet. Cela permet de cibler ses efforts, de mettre en place des actions de surveillance sur des sujets « à risque », de ne pas rester dans une analyse théorique mais d’affronter quotidiennement la réalité, en cours ou à venir.

Souvent, la gestion du risque s’arrête à la construction de la matrice classe d’impact et classe de probabilités. Comme pour toute analyse, l’identification et la schématisation ne sont que le début du travail. Il faut que cette matrice soit continuellement analysée, traduite en actions opérationnelles, et soit un support de communication pour partager avec l’ensemble des personnes impliquées la situation du projet, sur le court, moyen et long terme.

L’identification des risques, leur évaluation et leur traitement sont des tâches permanentes du chef de projet.

Je finirai ce sujet par un point que je juge important. La gestion du risque va permettre au chef de projet, en cas de problèmes potentiels majeurs, de savoir s’il faut arrêter ou suspendre un projet. C’est un acte tabou dans de nombreuses entreprises. Jugé très souvent comme un acte de lâcheté, je pense au contraire que c’est un acte de courage. Lorsque je commence une mission et que j’analyse la gestion de projet, je pose la question : « Combien avez-vous arrêté de projets l’an dernier ? » Très souvent, la réponse est : « Aucun ! nous avons un bon processus de gestion de projets ! » Je pense au contraire que l’on mesure la maturité de ce processus à sa capacité à arrêter des projets. Les raisons peuvent être multiples : projet ayant très peu de chances d’aboutir dans le triptyque initial coût/qualité/délais, dépriorisation pour un projet plus stratégique ou à plus fort ROI, projet lancé trop tôt (mauvaise préparation) …

9. La communication

Un projet d’envergure ne concerne pas que les opérationnels qui y participent. Il concerne tout l’écosystème de production des livrables, les managers, la direction, mais également tous les utilisateurs qui seront amenés à utiliser directement ou indirectement les livrables du projet.

On parle souvent de gestion du changement sur la phase d’avant-mise en production.

Pour ma part, je pense que la gestion du changement débute en même temps que le projet. Plus on communiquera tôt vers un périmètre large de collaborateurs, plus on créera un intérêt pour le projet, et plus on facilitera son déploiement.

Pour cela, il convient de mettre en place un plan de communication complet, définissant les personnes ciblées, les supports, les messages, le timing… Pour des projets d’envergure, c’est un poste à temps plein. Aujourd’hui, la variété des canaux de communication et les utilisateurs très digitaux permettent de faire des communications amusantes, disruptives, qui aiguisent l’attrait pour le futur livrable et renforcent l’image de l’entreprise.

Cependant, un plan de communication demande du courage. Quand tout va bien, tout va bien ; mais il faut être prêt également à communiquer sur les difficultés, voire les problèmes. Je suis généralement surpris de voir que ces messages honnêtes, bien que négatifs, contrairement à ce que l’on appréhendait, renforcent la crédibilité de l’équipe projet. De plus, les destinataires sont reconnaissants de recevoir une information vraie. Ils se sentent vraiment à bord du projet.

10. Le bon sens

Je pense qu’il ne faut jamais oublier de prendre du recul régulièrement.

Abreuvé de méthodes, de KPI, de procédures, le chef de projet, comme tout manager, ne doit pas oublier le « bon sens paysan ».

Quand un problème devient « brumeux », il faut savoir prendre du recul directement ou indirectement, appeler un tiers externe au projet, casser les codes, penser out of the box, et surtout, faire confiance à son intuition.

L’intuition n’est pas à opposer à la raison. Comme l’explique Sophie Ramspacher : « intégrer l’intuition dans le métier de manager ne revient pas à faire disparaître le cadre préétabli, ni à faire en sorte que toutes les décisions soient prises grâce à l’intuition en laissant de côté l’analyse. L’idée est de bénéficier de la synergie des deux (intuition et raisonnement) pour optimiser les décisions managériales. »

L’intuition fait souvent peur, au moins dans les débuts de la vie professionnelle. Nous avons été abreuvés pendant nos premières années professionnelles (études incluses) de théories et méthodes en tous genres. L’intuition, cette petite lumière qui s’allume et nous souffle subrepticement une idée, fait peur, car nous ne comprenons pas son mécanisme de création. Plus nous devenons matures, plus nous allons apprendre à la connaître, voire à la générer. Nous allons apprendre à maîtriser notre cerveau.

Cette intuition est ce que nos ancêtres ont appelé le « bon sens paysan ».

L’intuition vient de notre inconscient, et provient d’expériences que nous avons faites, mais dont nous n’avons pas forcément de souvenirs conscients. Elle ne vient donc pas de nulle part. Elle fait partie entièrement de nous. Il faut donc apprendre à l’écouter, pour appliquer cette idée intuitive… ou ne pas l’appliquer.

Pour ma part, quand une idée intuitive survient et qu’elle me semble intéressante, je vais la mettre en pratique. Mais je suis extrêmement vigilant, dans les premiers temps de son application, à ce que ce ne soit pas une mauvaise idée. Mon principe de base n’est pas de choisir la meilleure solution, mais surtout d’éviter de choisir la mauvaise.

La gestion de projets ? Un formidable monde d’opportunités

Je souhaite terminer par une note positive.

Je pense que l’on complexifie et alourdit beaucoup la gestion de projets. Quand je vois les slides des formations à la gestion de projets et les messages associés, je suis toujours très surpris par l’esprit pessimiste qui s’en dégage. On a envie de tout à son issue, sauf de diriger un projet. Ce métier est souvent décrit comme un monde de contraintes, lourd, étouffant.

Il est absolument vrai qu’un projet peut être très complexe, porter des enjeux très importants, embarquer beaucoup de monde, d’autant plus si c’est la reprise d’un projet ayant déjà échoué. C’est un fait évident : un projet, quelle qu’en soit sa taille, n’est jamais simple.

Mais je continue de penser qu’un projet est un formidable lieu d’opportunités. Le chef de projet doit être un leader à l’esprit positif, communiquant, qui est honnête pour affronter la vérité, qui pense simple, qui s’appuie sur les sachants opérationnels et sait les challenger quand le besoin s’en fait sentir, qui est courageux pour regarder les problèmes en face, qui sait prendre son temps ou accélérer selon la phase du projet…

Et surtout, qui prend du plaisir dans ce management.

Je vous souhaite donc de passer de très bons moments à gérer des projets ambitieux, même si ce long chemin sera très souvent parsemé de cailloux ; car c’est justement pour contourner ou amortir le choc de ces cailloux que l’on a besoin d’un chef de projet.

Enfin, n’oublions pas que l’on ne demande pas à un chef de projet de nous exposer les problèmes : on lui demande de nous exposer ses solutions.