Gérer un projet : mission (im)possible ?

Comprendre l’environnement de chaque projet

Chaque projet se déroule dans un contexte particulier : social, économique, fonctionnel, national ou international, normatif, politique, technologique, historique, stratégique… qu’il faut prendre en compte dès son démarrage.
Aussi, le chef de projet agit-il en interaction avec ce qui l’entoure : directement avec les acteurs du projet, avec l’organisation dans laquelle se déroule le projet et l’environ-nement dans lequel évolue cette organisation (figure I-3) ; son rôle, sa responsabilité, ses tâches ou son influence varient en fonction de ces facteurs.
Le chef de projet interagit avec son équipe, le client, les sous-traitants ou autres fournisseurs impliqués dans le déroulement du projet.
Toutes les parties prenantes doivent être identifiées : il s’agit de toutes les organisations (départements, services, entreprises, sous-traitants, fournisseurs…) et toutes les person-nes affectées par le projet ou y ayant un rôle direct ou indirect. Le chef de projet comprend, ainsi, les attentes, les bénéfices escomptés, les enjeux, les conflits d’intérêt, les priorités. Le plus tôt est le mieux pour identifier les alliés possibles, repérer ceux qui pourraient constituer des obstacles et envisager de mettre au point un plan de conduite du changement. Sur le plan organisationnel et logistique, par exemple, dans une entreprise qui pratique le développement offshore, le projet sera impacté par les décalages horaires et la distance entre les équipes. L’environnement humain est un facteur déterminant pour le succès d’un projet.
Le projet se déroule dans une organisation qui se caractérise par une culture, un organi-gramme, des procédures, des moyens plus ou moins importants mis à disposition.
La culture de l’entreprise se reflète au travers de ses valeurs, de ses rapports humains, de son organisation ; certains projets bénéficient de la culture projet développée par des entreprises, qui offrent ainsi plus facilement support, responsabilité et autonomie aux équipes projet ; l’organi-gramme et les procédures plus ou moins contraignantes ont un impact sur les rapports hiérar-chiques et les modalités du reporting ; les services juridiques d’une structure importante ou d’un établissement public peuvent être plus contraignants sur les procédures d’achat qu’une PME de quelques personnes.

L’environnement dans lequel évolue cette organisation influence les conditions du projet.

Un projet international nécessite une prise en compte des différences culturelles et des régle-mentations locales. La concurrence, la pression du marché peuvent impacter le délai d’un projet ; une nouvelle réglementation ou un décret-loi peuvent modifier le contenu du projet.
Tous les éléments de contexte doivent donc être bien appréhendés par le chef de projet ; il reste ainsi mieux focalisé sur l’objectif, il évalue les contraintes et les risques, il établit la stratégie d’ensemble et définit les conditions de pilotage du projet.
Le chef de projet doit, par conséquent, être attentif, observateur, faire preuve d’une bonne capacité d’analyse et d’organisation. Il adaptera son style de management en fonction du contexte ; c’est ce qu’on appelle le management situationnel, qui répond à la nécessité d’exercer différents modes de management, à différents moments et avec des équipes souvent hétérogènes, dans divers contextes, souvent évolutifs au cours d’un projet.
Le chef de projet doit, en outre, développer son sens de la négociation pour obtenir les ressources qui lui sont nécessaires, avec des profils et des expertises spécifiques pour chaque projet ou bien pour discuter de l’assouplissement de telle ou telle formalité.
Entouré d’une équipe de collaborateurs et d’experts, le chef de projet doit démontrer une ouverture d’esprit mais rester indépendant afin de ne jamais perdre de vue l’objectif et de ne pas se laisser influencer abusivement par les discours des techniciens séduits par une technologie émergente ou les bons conseils prodigués par tous ceux qui, en dehors du projet, ont toujours de bonnes idées sur la façon de mieux conduire le projet !

Manager les hommes

Indépendance d’esprit, oui, mais la capacité du chef de projet à mobiliser l’ensemble des acteurs du projet facilitera l’atteinte des objectifs.
Une fois l’équipe constituée, le chef de projet doit rassembler, pour amener l’équipe à comprendre la vision du projet, à l’accepter et à la partager.
La méthodologie de gestion du projet mise au point sera communiquée, afin que chacun applique les processus et procédures définis. La tolérance et l’ouverture d’esprit du chef de projet faciliteront l’adaptation de cette méthodologie au fil de l’eau. C’est sa compé-tence de leader et ses capacités à bien communiquer qui favorisent cette adhésion.
On sous-estime souvent la dimension managériale de la fonction du chef de projet ; on décrit trop souvent ce dernier en réduisant son rôle à la construction de diagrammes de Gant et à la rédaction de plans projet dans lesquels il décrit sa stratégie. Avant tout, il est un chef d’orchestre, animé par le souci de réaliser une œuvre collective, avec des profils et des rôles variés. Sa tâche consiste à rendre cohérent le jeu de l’ensemble des acteurs en leur donnant un rythme commun.
Le succès du manager passe par la confiance qu’il doit gagner et que lui témoignent les membres de l’équipe ainsi que par la sécurité et la solidarité ressenties au sein du groupe face à l’extérieur (hiérarchie, clients…).
Nous verrons, au chapitre 6, « Gérer les hommes », combien son style de management est en train d’évoluer : plutôt directif à l’origine, le chef de projet devient progressive-ment coach et facilitateur pour servir son équipe.
Un débat est fréquemment ouvert sur la nécessité, pour le chef de projet, d’avoir en outre des compétences sur les aspects techniques du projet. Certes, il est plus aisé de trouver des solutions adéquates lorsqu’on a un ou plusieurs domaines d’expertise ; il est évidem-ment plus confortable de dialoguer en connaisseur avec des techniciens qui mettront telle ou telle technologie en avant ; et il est plus facile de démontrer son empathie pour un développeur qui rencontre des difficultés lorsqu’on a soi-même produit quelques millions de lignes de code.
Cependant, les activités de management, de relations humaines, de coordination et de gestion, notamment dans les projets de plus en plus importants, deviennent le cœur de métier du chef de projet, même dans un contexte hautement technologique. Les capacités d’organisation deviennent prépondérantes aux dépens des connaissances techniques.
En termes d’évolution de carrière, s’il veut prendre la responsabilité de projets d’enver-gure, le chef de projet devra « délaisser » sa spécialité de base au profit des techniques de management. L’une d’entre elles consiste d’ailleurs à savoir déléguer et à savoir s’entou-rer de personnes qui sauront prendre le relais sur ces spécialités.
Le chef de projet doit-il aussi avoir des compétences techniques (on entend ici, par techniques, les compétences dans les domaines informatiques, fonctionnels et technologiques) ?
La réponse de l’expert, Christophe Addinquy, directeur de projets back-office chez Vidal.
Je vote « pour », pour les raisons suivantes :
– Avoir des compétences techniques ne signifie pas être expert. Le chef de projet n’a pas besoin d’être expert, il s’agit d’un autre rôle.
– Le chef de projet sera d’autant plus efficace qu’il est « holistique », qu’il est capable d’avoir une vue globale comprenant toutes les facettes du projet. Cela lui permettra aussi de challen-ger des solutions proposées par rapport aux finalités du projet.
– Il sera davantage en connexion avec l’équipe s’il peut avoir des discussions techniques avec les différents membres. À l’inverse, s’il ne peut descendre à leur niveau, il prend le risque d’être vu comme un « outsider ».
Bien sûr, cela rend plus difficile le travail de délégation des choix techniques.
Le propre d’un chef d’entreprise n’est-il pas de savoir favoriser la compétence collective, c’est-à-dire mettre à contribution des collaborateurs aussi divers qu’un directeur des ventes, un directeur des achats, un directeur juridique, un directeur des ressources humaines, un directeur de la communication, un directeur qualité… ? Chacun avec des compétences très variées que, seul, le chef d’entreprise ne pourrait réunir, mais qu’il peut orchestrer en coordonnant le jeu de tous les acteurs.
Malheureusement, doté de toutes ces qualités et de toutes ces compétences, comme bon nombre de managers, le chef de projet a souvent un sentiment de solitude.

La solitude du chef de projet

En dépit d’une équipe, plus ou moins importante, qui l’entoure, le chef de projet se sent en effet souvent seul. Seul, face aux difficultés rencontrées, face aux questions qui lui sont posées, face aux problèmes imprévus, face aux décisions à prendre, face aux enga-gements à honorer.
Seul, lorsqu’on lui demande d’estimer « pour hier » le coût d’un projet sur la base d’un e-mail de quelques lignes ; seul, lorsqu’il demande une ou deux ressources supplémen-taires mais qu’« aucune n’est disponible » ou lorsqu’on affecte sans délai l’un de ses collaborateurs sur un autre projet « plus urgent » ; seul, lorsque certains membres de son équipe ont besoin de monter en compétence sur une nouvelle technologie mais qu’« il n’y a plus de budget formation disponible avant l’année prochaine » ; seul, lorsqu’on n’a plus le temps de tester et qu’il faut livrer dans l’urgence ; seul, face au client qui s’impa-tiente, auprès duquel il doit justifier le retard, tout en préservant sa solidarité avec l’équipe ; seul, face aux contrôleurs de gestion qui le pressent de « faire remonter » son reporting mensuel alors que lui-même n’arrive pas à obtenir de son équipe les indicateurs de temps passé…
Quels étranges sentiments de stress, de solitude et d’échec, parfois, alors que le chef de projet a précisément un rôle de coordinateur et d’interface entre des acteurs aussi multi-ples que son équipe, le client, sa hiérarchie, les fournisseurs… Ces sentiments sans doute sont-ils aiguisés par le fait qu’il hésitera à partager ses préoccupations. Avec ses collabo-rateurs ? Avec ses pairs ou sa hiérarchie ? Pour être soupçonné d’incompétence ? Il aura souvent tendance à centraliser la résolution des problèmes en souterrain et à n’alerter que tardivement sa direction.
Alors que le simple fait de communiquer, interroger, tirer profit des idées du groupe lui permet d’avoir un regard et une analyse complémentaires.
Deux exemples pour illustrer cette nécessaire concertation et cette approche collective des difficultés : l’estimation des charges et des coûts du projet et la gestion des risques. Comment un chef de projet, aussi compétent et expérimenté soit-il, pourrait, seul, recenser l’exhaustivité des tâches à réaliser et calculer la durée du projet ? Comment pourrait-il, seul, bénéficier d’une vision suffisamment large pour anticiper tous les risques d’un projet ? Aussi brillant soit-il, son analyse ne peut être que parcellaire.
D’une part, nous verrons, dans le chapitre 4, « Planifier son projet », qu’une démarche colla-borative et la recherche du consensus fiabilisent l’estimation globale et confortent le chef de projet. D’autre part, la gestion des risques sera abordée au chapitre 5, « Suivre et piloter son projet », et présentée, là encore, avec une vision et une approche collectives, rendant l’analyse plus exhaustive.
Nouer des alliances, tisser des relations au sein et en dehors du groupe doivent faire partie de la stratégie du chef de projet lequel est tenu :
• d’identifier, dès le démarrage du projet, les bons acteurs ; il s’appuiera sur les personnes plutôt prédisposées au changement, dotées d’une forte capacité d’influence pour convaincre les plus réticents à coopérer ;
• d’« aller au contact » des utilisateurs pour mieux les comprendre, pour se faire comprendre, pour jouer la carte de la transparence et « humaniser » le monde infor-matique ;
• d’associer ses collaborateurs pour analyser les causes des problèmes rencontrés et pour trouver les solutions les plus efficaces et les plus rentables ; ce qui les impliquera davantage encore dans le succès du projet ;
• de déléguer une partie de ses travaux ; c’est une marque de reconnaissance et de confiance vis-à-vis d’un collaborateur, ce qui lui permet de se consacrer à la résolution des problèmes qui surgissent ; le chef de projet n’a pas nécessairement l’expertise pour tout traiter ;
• de partager avec d’autres chefs de projet qui rencontrent probablement les mêmes difficultés ; il s’agit de gagner du temps en capitalisant sur les bonnes pratiques ; à cet effet certaines organisations ont mis en place des structures appelées « Bureau de projet » ou Project Management Office (PMO) afin d’apporter assistance et support aux équipes projet avec des pratiques et des outils mis en commun grâce au partage d’informations et à la capitalisation ;
• de dialoguer, avec objectivité et intégrité, avec des experts techniques ; cela donne un éclairage plus complet sur l’éventail des solutions disponibles appropriées ;
• de pratiquer le Management By Wandering Around, le management par écoute et rencontre, en communiquant de façon informelle avec ses collaborateurs ; le chef de projet n’est plus dans sa tour d’ivoire à produire des plans, il a son bureau dans la même salle que l’équipe ; il développe ainsi ses qualités relationnelles pour améliorer ses relations interpersonnelles et managériales.
Grâce à de nouvelles approches, plus collaboratives, responsabilisant les équipes – présentées au chapitre 6, « Gérer les hommes » –, le chef de projet n’est plus seul pour faire face à de nombreuses incertitudes, inévitables sur tout projet.

La certitude de l’incertitude

Nombreuses, en effet, sont les incertitudes au cours d’un projet.
• Nous ne savons pas précisément ce que nous allons développer : les exigences évoluent souvent, le client ne sait pas toujours ce qu’il veut…
• Nous ne connaissons pas toujours les individus qui seront amenés à collaborer dans l’équipe ; nous ne pouvons prédire leur autonomie, leur proactivité ou leur capacité à appréhender le domaine.
• Nous ne pouvons donc pas précisément estimer la productivité de l’équipe, qui peut varier en fonction des contextes.
• Nous n’avons, souvent, qu’une idée de la solution à implémenter et qu’une ébauche de l’architecture, notamment en début de projet.
• Nous ne maîtrisons pas toujours les technologies qui seront déployées (nouvelle techno-logie, intégration de deux technologies, ressources faiblement expérimentées sur la technologie retenue…).
• Nous consacrons pourtant beaucoup de temps à établir des plannings qui sont systéma-tiquement dépassés ou rapidement obsolètes, puisque, chaque fois, des événements surviennent en cours de route pour modifier la donne initiale.
Toutes ces interrogations font qu’une attitude prédictive, qui consiste à vouloir plani-fier et estimer de façon définitive, pour figer le déroulement du projet, est inadaptée. Comment, en effet, dans ces conditions, établir un planning fiable du projet, détermi-ner les ressources et les expertises nécessaires, s’engager et engager son équipe sur un résultat final, un délai, un budget ? L’approche prédictive rassure, elle est plus confortable, mais conduit trop souvent à l’échec puisqu’on tente de gommer ces incer-titudes.
Quelle attitude, alors, le chef de projet doit-il adopter face à ces incertitudes ?

Accepter l’incertitude

La première est d’accepter l’incertitude, pour mieux la maîtriser, et non la combattre.
Il s’agit d’accepter une réalité et de comprendre que, dans le développement logiciel, tout n’est pas prévisible.
D’une part, parce que le secteur informatique est une industrie jeune, comparée à l’indus-trie automobile, par exemple, qui a plus d’un siècle d’expérience. D’autre part, parce qu’il est difficile de s’entendre avec le client, « une bonne fois pour toutes », sur ce qu’on va livrer. Et aussi, parce que les techniques d’estimation et de planification ne sont pas des sciences exactes.
Chaque projet est une nouvelle expérience ; en acceptant l’inconnu d’un projet, plus ou moins important, selon qu’on est sur un projet d’exploration ou de maintenance, le chef de projet évitera de se retrouver en situation d’échec.
Si on accepte l’incertitude, on accepte aussi l’idée du changement : changement dans le périmètre des besoins, changement dans la planification, changement dans l’organisation de l’équipe… pour s’adapter aux imprévus.
C’est dans cet environnement mouvant, non stabilisé, que le chef de projet et l’équipe doivent chaque fois repenser la stratégie de développement et adapter les processus.
Nous verrons comment une démarche adaptative, basée sur le feedback du client, l’expé-rience, le constat, l’analyse tout au long du projet, l’humilité et la simplicité pour reconnaître qu’on ne sait pas tout, porte ses fruits, dans une démarche d’amélioration continue.
Cette capacité à reconnaître qu’on ne sait pas, qu’on va apprendre « en faisant », et de ce fait s’adapter aux spécificités de chaque projet, de chaque équipe, de chaque client, est sans doute la qualité la plus honorable du chef de projet.

Anticiper

Cependant, la reconnaissance qu’il ne peut tout savoir à l’avance implique que le chef de projet anticipe pour imaginer les événements heureux ou malheureux qui pourraient surve-nir sur le projet, afin d’envisager différents scénarios. Bien entendu, plus l’expérience du chef de projet est longue et riche, plus les membres de l’équipe sont associés à la démar-che, meilleure est la spéculation. En développant le réflexe de la capitalisation, mais aussi en sachant apprendre de l’échec, on améliore, de fait, cette capacité d’anticipation.
Toutefois, la zone de bonne prévisibilité s’étalant entre quelques heures et un mois maximum, prévoir au-delà devient quasi impossible. Il n’est donc possible d’anticiper et de planifier un projet qu’étapes par étapes. C’est de ce constat qu’est né le dévelop-pement itératif qui sera présenté au chapitre 2, « Méthodes traditionnelles ou méthodes agiles ? ».
Anticiper, c’est mettre en place une stratégie de gestion des risques : identifier, analyser, suivre les risques, prévoir un plan d’actions pour atténuer ou éliminer l’effet des risques. Ce thème est évoqué en détail au chapitre 5, « Suivre et piloter son projet ».
Le chef de projet doit, par conséquent, faire preuve d’humilité et démontrer sa capacité d’adaptation, d’anticipation… et de persuasion. En effet, s’il accepte lui-même cette imprévisibilité, il doit également convaincre ses clients, sa hiérarchie, et les amener à l’accepter, eux aussi. Cette démarche peut être longue car bouscule des a priori ancrés dans les esprits depuis le début de l’informatique ; il devra s’armer de bon arguments pour contrer les objections et les résistances. Dans ce contexte et compte tenu de ce niveau d’exigences vis-à-vis du chef de projet, est-il encore possible de gérer un projet ?