Chef de projet : un métier complexe

Être chef de projet est un métier passionnant mais difficile à exercer. Avant tout, à cause de ses rôles, le chef de projet, lui-même, doit être multicompétent : c’est-à-dire maîtriser les techniques de gestion de projet, appréhender, chaque fois, les spécificités du projet et en plus être un bon leader d’équipe. Ensuite, il est souvent seul, pour faire face, notamment, à l’incertitude et à l’éthique qui les entourent. Alors, gérer un projet serait-ce une mission (im)possible ?

Le rôle du chef de projet

Le chef de projet est un gestionnaire et, comme tout gestionnaire, il a la responsabilité de planifier, organiser, diriger et contrôler (PODC).

Planifier

Les activités de planification ne se limitent pas à établir l’échéancier lors de l’étape de planification du projet. Pour le chef de projet, la planification se poursuit tout au long de la phase d’exécution, puisqu’il doit s’assurer que les travaux avancent au rythme prévu et que tout retard est corrigé dans les meilleurs délais. La correction d’un retard oblige souvent à effectuer une nouvelle planification d’une partie ou de l’ensemble des tâches liées au projet.

La phase d’exécution comporte son lot de planification. Il est essentiel de ne pas perdre de vue que le PODC est un processus itératif, c’est-à-dire qu’il se répète.

Lire Aussi: Comment calculer le ratio de couverture des charges fixes

Organiser

Les activités d’organisation du chef de projet sont multiples : non seulement doit-il s’occuper d’affecter les ressources aux tâches, mais aussi de coordonner l’utilisation des ressources et de traiter adroitement avec les facteurs humains toujours présents dans un projet. L’organisation du travail est critique dans un projet où plusieurs ressources spécialisées interviennent. En effet, plus un projet utilise des ressources spécialisées, plus ces ressources sont difficiles à remplacer en cas de besoin.

Diriger

Le chef de projet doit aussi savoir diriger son œuvre. En sa qualité de directeur, il doit prendre des décisions importantes, sans dépasser les limites budgétaires établies par le promoteur et son propre employeur. Ainsi, il possède l’autorité nécessaire pour gérer à sa guise le budget du projet, toujours dans l’objectif de respecter les contraintes de coût, de temps et de qualité. S’il lui est impossible de respecter l’une de ces contraintes, le chef de projet doit être le premier à réagir à cette situation.

Son rôle est alors de signaler cette situation au promoteur et de lui proposer des correctifs. Lorsque ces derniers nécessitent que les contraintes soient modifiées, seul le promoteur peut prendre la décision finale à ce sujet, puisqu’il est celui qui a demandé que le projet soit réalisé selon ces contraintes.

Lire Aussi: Le modèle organisationnel de décision

Contrôler

Le chef de projet doit aussi contrôler. Son contrôle s’effectue sur plusieurs plans : contrôle de l’avancement (temps), contrôle des coûts et de la qualité.

Le point 6.2 de cet article est consacrée aux activités de contrôle et de suivi qui doivent être effectuées par le chef au cours de l’exécution du projet. Le contrôle exercé par le chef de projet permet d’apporter des correctifs qui amènent à leur tour des changements.

Le rôle du chef de projet ne se limite donc pas au simple contrôle : les écarts existant entre la planification initiale et l’avancement réel des activités doivent être réduits. Ces correctifs amènent habituellement des changements dans la distribution du budget, mais aussi dans l’affectation des ressources.

Lire Aussi: Tax Optimization Strategies for Maximum Savings

Le contrôle implique aussi de savoir gérer les changements dans l’équipe de projet, ainsi que ceux qui sont demandés par le promoteur. En effet, il n’est pas rare que le promoteur lui-même demande des modifications au projet, ce qui peut
supposer des changements importants.

À l’extrême, il arrive que les changements demandés amènent des changements à la définition originale du projet, déterminée lors de la phase 1, ce qui a évidemment des conséquences sur les contraintes de temps, de coût et de qualité de l’extrant.

Le chef de projet ne doit pas perdre de vue que, pour le promoteur, le projet n’est pas une fin en soi. Il s’agit plutôt d’une étape nécessaire qui précède l’utilisation de son produit. Il souhaite donc que le projet soit réalisé pour que l’extrant corresponde à ses attentes.

Pour mener bien son rôle, le chef de projet doit cumuler plusieurs compétences.

Le chef de projet multicompétent

Le périmètre des responsabilités du chef de projet est large mais variable. En effet, selon la taille et le contexte particulier du projet, le métier change.

Cependant, invariablement, la responsabilité première du chef de projet est de mener le projet à son terme.

Un projet est généralement subdivisé en phases, chacune d’entre elles devant aboutir à la mise à disposition de livrables. On parle aussi de cycle de vie pour décrire l’enchaînement de ces phases.

La gestion de projet est la mise en œuvre de connaissances, de compétences, d’outils et de techniques appliqués au projet afin d’en respecter les exigences, vis-à-vis du client (interne ou externe) et de sa propre hiérarchie. Même si elle se résume souvent à… faire
des listes ! Des listes de priorités, des listes de risques, des check-lists d’éléments à vérifier, des listes d’actions…

Pour atteindre l’objectif, le chef de projet doit toutefois prendre en compte les trois contraintes (les 3 C) que constituent le contenu du projet, le calendrier et le coût (voir figure 1)

Le succès du projet se mesure, en effet, à la satisfaction du client et à la qualité du résultat, c’est-à-dire à la conformité du produit, à ce qui est attendu, livré dans le respect du délai imparti et du budget alloué.

Or, comme nous l’indique la figure 2 ci-dessous, statistiquement, les études menées par le Standish Group1 démontrent que la proportion de projets qui sont considérés comme des succès (autrement dit, respectant les 3 C) reste faible : entre 25 % et 30 %. Cela signifie que trois projets sur quatre sont des échecs complets ou partiels : les projets sont abandonnés en cours de route ou aboutissent, mais au prix de dépassements importants, ou offrent moins de fonctionnalités que prévu.

En effet, l’ajout d’un contenu supplémentaire affecte le budget, voire le délai. Raccourcir le délai de réalisation, pour respecter une date réglementaire par exemple, nécessitera d’ajuster le contenu à la baisse ou d’augmenter le budget en affectant de nouvelles ressources

Jonglant avec ces contraintes, devant souvent arbitrer, à tort, en lieu et place du client, le chef de projet va devoir puiser dans sa « boîte à outils », usant de telle ou telle compétence pour faire aboutir le projet avec succès.

La maîtrise des techniques de gestion de projet est une compétence de base, que le chef de projet doit exploiter en s’adaptant aux caractéristiques de chaque projet. Il doit donc développer des qualités d’analyse et de compréhension de l’environnement de chaque projet. Si, en outre, il est accompagné d’une équipe et que de nombreux acteurs son partie prenante du projet, il doit déployer des qualités interpersonnelles pour animer et coordonner cette communauté.

Maîtriser les techniques de gestion de projet

Le PMI, dans son PMBOK (Project Management Body of Knowledge), recense et classifie les techniques de gestion de projet en neuf domaines de connaissance et en groupes de processus (voir tableau 1).

Management de l’intégration du projet	Management du contenu du projet	Management des délais du projet
• Élaboration de la charte du projet • Élaboration de l’énoncé préliminaire du contenu du projet • Élaboration du plan de management du projet • Direction et pilotage de l’exécution du projet • Surveillance et maîtrise du travail du projet • Maîtrise intégrée des modifications • Clôture du projet	• Planification du contenu • Définition du contenu • Création de la structure de découpage du projet • Vérification du contenu • Maîtrise du contenu	• Identification des activités • Séquencement des activités • Estimation des ressources nécessaires aux activités • Estimation de la durée des activités • Élaboration de l’échéancier • Maîtrise de l’échéancier
Management des coûts du projet	Management de la qualité du projet	Management des ressources humaines du projet
• Estimation des coûts • Budgétisation • Maîtrise des coûts	• Planification de la qualité • Mise en œuvre de l’assurance qualité • Mise en œuvre du contrôle qualité	• Planification des ressources humaines • Formation de l’équipe de projet • Développement de l’équipe de projet • Diriger l’équipe de projet
Management des communications du projet	Management des risques du projet	Management des approvisionnements du projet
• Planification des communications • Diffusion de l’information • Établissement du rapport d’avancement • Management des parties prenantes	• Planification du management des risques • Identification des risques • Analyse qualitative des risques • Analyse quantitative des risques • Planification des réponses aux risques • Surveillance et maîtrise des risques	• Planification des approvisionnements • Planification des contrats • Sollicitation des offres ou des propositions des fournisseurs • Administration du contrat • Clôture du contrat

Derrière les processus, des activités sont à réaliser, généralement instrumentées avec des applications progicielles ou bureautiques.

Le PMBOK liste et décrit ces activités mais c’est au chef de projet d’apprécier leur pertinence et de déterminer leur organisation ou leur séquencement, selon la méthodologie adoptée et le degré de formalisme exigé, en fonction du projet (taille, criticité, acteurs, risques, innovation ou maintenance, externalisation partielle ou totale).

En professionnel de la gestion de projet, le chef de projet doit :

• connaître et maîtriser ces techniques ;
• savoir expliciter et justifier ses choix ;
• être capable de reproduire une pratique qui a bien marché dans un contexte donné, dans un contexte analogue ou l’adapter à un contexte différent ;
• savoir mettre en avant ce qu’il sait et inspirer confiance ;
• être reconnu en tant que professionnel.

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’environnement dans lequel évolue cette organisation (figure 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.

Le projet se déroule dans une organisation qui se caractérise par une culture, un organigramme, des procédures, des moyens plus ou moins importants mis à disposition.

L’environnement dans lequel évolue cette organisation influence les conditions 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…).

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 (comme on a évoqué précédemment).

Certes, il est plus aisé de trouver des solutions adéquates lorsqu’on a un ou plusieurs domaines d’expertise ; il est évidemment 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’envergure, 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’entourer de personnes qui sauront prendre le relais sur ces spécialité

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.

En résumé, le super chef de projet doit concentrer de nombreuses compétences, comme l’illustre la figure 4.

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 engagements à 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émentaires 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, 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 multiples 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 collaborateurs ? 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.

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 informatique ;
• 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, 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 technologie, 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ématiquement 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 planifier 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éterminer 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 incertitudes.

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’industrie 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.

S’adapter

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 survenir 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émarche, 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.

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.

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 ?

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

On peut en effet se poser la question d’autant que, même si la tendance s’améliore, la proportion de projets qui sont considérés comme des succès reste minoritaire.

La réussite et l’échec pour le chef de projet

Essayons d’identifier les sources d’échec, autour ou dans le projet lui-même.

En premier lieu, pourquoi ne sommes-nous pas attentifs aux signes avant-coureurs ?

Lorsqu’un projet démarre sans qu’un consensus n’ait été trouvé entre les différentes parties prenantes sur l’objectif à atteindre, lorsqu’on constate un déséquilibre évident entre l’ambition du projet et les moyens ou le délai qui lui sont accordés, on sait que le
projet démarre mal.

Et dans ce cas, il s’agit davantage d’une mauvaise orientation ou d’un mauvais dimensionnement plutôt que d’une mauvaise gestion du projet. Si l’entreprise ne se dote pas des moyens adéquats pour accompagner son ambition, alors qu’une trop grande pression est mise sur l’engagement de résultats, les maillons successifs de la chaîne ne feront que pallier et compenser tant bien que mal cette déficience. Et le chef de projet se remettra sans cesse en question, alors que des raisons indépendantes, parfois, de sa compétence, expliquent ce taux anormalement élevé d’échecs.

• Au départ, l’imprécision du cahier des charges ou, à l’inverse, la « surspécification » des utilisateurs qui veulent être exhaustifs font qu’il n’est plus possible de revenir sur les besoins exprimés initialement. Il en résulte un taux important de fonctionnalités livrées, qui ne seront pas utilisées, et une complexité du développement accrue inutilement.
• L’évolution constante des besoins pour des raisons de mauvaise compréhension, de volatilité du marché ou de l’effet tunnel (longueur des projets) est difficilement compatible avec une démarche classique de gestion de projet.
• L’absence de priorisation ou de valorisation des besoins exprimés par la maîtrise d’ouvrage amène les utilisateurs à vouloir « tout, tout de suite » ; alors qu’en sensibilisant ceux-ci à la nécessaire hiérarchisation des besoins en fonction de leur valeur réellement ajoutée, on évite de « gaspiller » des ressources inutilement.
• Cela s’explique en partie par la faible professionnalisation de la maîtrise d’ouvrage ; en général, celle-ci est peu sensibilisée à la complémentarité de son rôle ; elle n’a pas toujours conscience de l’importance de l’implication et de la disponibilité des utilisateurs. Même si ce métier se développe peu à peu dans les organisations, les maîtrises d’ouvrage n’ont pas encore toutes atteint le niveau de maturité indispensable pour une vraie relation de partenariat, reposant sur l’harmonie, la complémentarité et le partage des enjeux.
• Faible implication des utilisateurs mais aussi de la direction : c’est elle qui légitime un projet, qui donne l’orientation, les objectifs et… les moyens qui vont avec. C’est elle aussi qui, malheureusement, n’est alertée et donc ne s’implique que lorsque la sonnette d’alarme est tirée. Et elle apparaît alors comme un « tribunal correctionnel » une fois que tous les indicateurs sont au rouge…
• C’est la direction, en outre, qui a lancé, ces dernières années, une politique de rationalisation des achats de prestations informatiques, en imposant un cadre contractuel et juridique souvent inadapté : dans ce contexte, les uns veulent réduire leurs coûts, les autres maximiser leur profit au détriment des projets eux-mêmes.
• Malgré cette rationalisation, on déplore, encore, des projets « jouets », circonstanciels, suivant une mode, qui ne desservent aucun objectif ou ne répondent à aucun besoin stratégique. Ces projets, inévitablement, s’étiolent et n’aboutissent à aucun résultat
  tangible, alors qu’ils ont un coût et un effet parfois démotivant sur les équipes.

Cependant, il ne serait pas objectif de ne justifier ces échecs que par des facteurs externes.

Bien des faiblesses internes au projet sont parfois à déplorer :

• Les méthodologies classiques de gestion de projet prévoient une approche séquentielle des activités : « Je définis le produit, je le conçois, je le développe, je le teste puis je le livre. »

Une approche classique suppose, par conséquent, que l’on estime a priori l’ensemble des charges nécessaires à la réalisation du produit malgré toute l’incertitude qui, nous l’avons vu précédemment, environne le projet. Il est évident qu’une mauvaise estimation des charges conduit immanquablement à un dépassement budgétaire, récurrent sur de nombreux projets. La question est : « Pouvons-nous estimer de façon certaine ? »

• Cette approche séquentielle a pour conséquence une détection tardive des anomalies (bogues, non-conformités, oublis…) dans le cycle de vie. Or, on constate que plus une anomalie est détectée tard, plus le coût de correction sera élevé. Les projets qui dérivent dans le temps sont souvent des projets qui ont un taux d’anomalies important, donc de corrections, de régressions, de « colmatages de dernière minute » qui allongent la durée du projet… et son coût final.

• L’approche séquentielle suppose l’intervention successive de différents « corps de métier » : des développeurs succèdent aux concepteurs, qui succèdent eux-mêmes aux analystes…, ce qui engendre des ruptures dans la « chaîne de fabrication » et par conséquent des pertes d’informations précieuses.

• Il est fréquent d’observer, par ailleurs, un manque de rigueur dans le pilotage et le suivi du projet. Le système de pilotage est souvent mal adapté au projet, le reporting est fastidieux et le chef de projet se démène chaque jour avec ses indicateurs au rouge.
• La technologie, si elle offre de plus en plus de perspectives, n’en est pas pour autant toujours maîtrisée, parce que trop souvent encore instable ou utilisée dans des architectures complexes. L’équipe a donc de mauvaises surprises, notamment lorsqu’il s’agit de procéder à l’intégration finale ! On voit même, parfois, le périmètre fonctionnel s’ajuster pour s’adapter à la solution retenue !
• L’inadéquation des ressources, enfin, est fréquemment vécue par les chefs de projet comme une entrave au bon déroulement du projet : ne pas disposer des bonnes compétences au bon moment ou voir son meilleur architecte affecté à un autre projet plus
  prioritaire contraint l’équipe à travailler en sous-effectif ou par tâtonnements.

Ce sont toutes ces raisons qui nous mènent à une situation d’échec et qui rendent la gestion d’un projet difficile. Alors, si nous combinons, en prime, l’introduction d’une nouvelle technologie, d’une nouvelle méthodologie de gestion de projet avec un chef de
projet peu expérimenté ou nouveau dans la société, entouré de développeurs juniors, sans soutien de sa direction… C’est malheureusement la concomitance de tous ces facteurs qui pénalise souvent le chef de projet et qui le conduit à douter parfois de ses capacités à gérer un projet.

Il ne s’agit pas, ici, de noircir le paysage du chef de projet, mais de dresser un tableau réaliste et optimiste.

Car la gestion d’un projet est un métier passionnant qui offre l’opportunité de nombre d’initiatives, d’expérimentations, d’innovations, de créativité et d’expression de soi.

Chef de projet, débutant ou expérimenté, vous vous êtes peut-être reconnu dans cette description et vous pouvez constater que vous n’êtes pas seul face aux difficultés.

Nombreux sont ceux qui partagent les mêmes difficultés et les mêmes doutes. Heureusement, le métier évolue, les méthodologies de conduite de projet aussi, basant leurs fondements sur les retours d’expérience et la réalité des projets. Ce sont des approches plus empiriques, plus simples, plus légères, dites agiles, souvent soupçonnées d’effet de mode, mais qui ouvrent bien des perspectives et extraient le chef de projet de la spirale de l’échec.

On sait combien la capacité d’adaptation et la réactivité sont devenues nécessaires dans toute organisation, pour l’informatique en particulier. En effet, le système d’information est devenu un instrument clé pour accompagner la stratégie d’une organisation.

Sur le plan commercial, le cycle de vie des produits ne suit plus les modèles classiques élaborés par les stratèges et les départements marketing ; les changements, dans la demande, sont plus fréquents et plus rapides ; on doit donc développer très rapidement de nouvelles offres pour faire face aux nouveaux besoins du marché et à la concurrence.

Le système d’information et ses applications sont donc un levier déterminant pour supporter ces nouvelles offres de produits ou de services et sont considérés comme des outils de création de valeur. Dans ce contexte, l’informatique devient stratégique, à son
tour, et doit par conséquent être d’une réactivité à toute épreuve pour servir l’organisation. Développer une nouvelle application logicielle ne doit plus être une entreprise lourde dont on ne voit jamais la fin.

Le suivi du projet

Périodiquement, le chef de projet doit procéder au suivi de l’avancement, des coûts et de la qualité. Puisque la planification reflète rarement les faits avec exactitude, il est essentiel d’ajuster les prévisions pour tenir compte de la réalisation effective du projet. Chaque semaine, le chef de projet produit un rap- port de suivi, lequel comporte cinq sections :

• la définition de la planification initiale ;
• le contrôle de l’avancement ;
• le contrôle des coûts ;
• le contrôle de la qualité ;
• les actions correctives.

Le contrôle de l’avancement et des coûts se fait principalement au moyen de mesures quantitatives, alors que le contrôle de la qualité se fait plutôt à l’aide de mesures qualitatives. Les sections suivantes présentent les renseignements que le chef de projet doit inclure dans son rapport de suivi.

La définition de la planification initiale

À la fin de la phase de planification, le chef de projet soumet sa planification initiale à l’équipe de projet. C’est d’après cette planification que devrait normalement se dérouler le projet. Cette première planification est appelée « planification initiale ». Elle est ensuite utilisée pour mesurer l’avancement du projet. Le diagramme de Gantt du projet fait donc partie de tous les rapports de suivi. La figure 5 ci-dessous présente le diagramme de Gantt de la planification initiale d’un projet simple.

Le contrôle de l’avancement

Pour effectuer le contrôle de l’avancement, le chef de projet doit se servir d’un diagramme de Gantt du suivi du projet (appelé « diagramme de Gantt suivi » ou « Gantt suivi »). Ce diagramme incorpore le diagramme de Gantt de la planification initiale et celui des tâches telles qu’elles ont été effectivement exécutées. Cette juxtaposition permet de voir aisément les modifications apportées à la planification initiale.

La figure 6 présente le diagramme de Gantt suivi. En observant cette figure, on constate que les tâches A, B et D ont été exécutées comme on les avait planifiées. Toutefois, la tâche C a été achevée en cinq jours plutôt qu’en six, ce qui influence le reste du projet. En effet, la tâche E peut commencer une journée plus tôt, ce qui permet de devancer la date de début de la tâche F.

Cet enchaînement permet de terminer le projet une journée plus tôt, la tâche C étant critique. Le Gantt suivi comporte quatre renseignements essentiels :

• les tâches planifiées initialement ;
• les tâches exécutées ;
• les tâches à venir, selon la planification revue ;
• la date du jour.

Cette information permet au chef de projet d’obtenir une image complète de l’avancement du projet et du respect de la planification initiale. Certains renseignements intéressants peuvent être tirés du Gantt suivi. Par exemple, les tâches A, B, C et D sont terminées à 100 %, alors que la tâche F n’est pas commencée (0 %). Pour sa part, la tâche E, d’une durée de quatre jours, a débuté il y a un jour. Rien n’indique que la durée de cette tâche sera modifiée dans le nouvel échéancier. Une proportion de 25 % de la tâche E est donc achevée.

Dans la section « Contrôle de l’avancement », le rapport de suivi du projet présente quatre renseignements essentiels :

• le diagramme de Gantt suivi ;
• la liste des tâches en cours et leur pourcentage d’avancement ;
• la prévision de la date de fin des tâches, incluant le retard prévu ;
• le pourcentage d’avancement global du projet.

Il est parfois difficile d’établir avec précision la date de fin d’une tâche. On calcule cette date en demandant à son responsable d’en estimer la durée restante. Il s’agit d’un exercice difficile, que le responsable de la tâche effectue souvent avec l’aide du chef de projet.

Quelques remarques doivent être faites à propos de ce type de tableau.

• La colonne « Statut » présente l’état d’avancement de chacune des tâches : terminée, en cours ou à venir.
• La durée planifiée et la durée réelle de chaque tâche sont indiquées. Habituellement, la durée restante est obtenue par simple soustraction ; toutefois, le chef de projet peut estimer que la durée restante d’une tâche est différente, auquel cas il apporte les ajustements nécessaires à ce tableau. La tâche C en est un exemple.
• La formule suivante permet de connaître le pourcentage d’avancement d’une tâche :

Pourcentage d’avancement = Durée réelle / (Durée réelle + Durée restante)

• On obtient les dates de fin planifiée, réelle et prévue en reportant le diagramme de Gantt suivi dans un calendrier.

• Le retard doit être calculé pour chaque tâche du projet afin d’assurer un suivi efficace et de savoir où se trouvent les difficultés. Un retard négatif (on parle alors d’une avance, comme c’est le cas dans notre exemple) signifie que la tâche se termine plus tôt que ce qui avait été planifié initialement.

Un retard positif signifie que la tâche se termine avec un retard. On doit également calculer le retard pour l’ensemble du projet. Comme un retard s’accumule d’une tâche à l’autre, le retard de la dernière tâche correspond au retard total du projet. On détermine ce retard en utilisant les formules suivantes :

Retard d’une tâche en cours ou à venir = Fin prévue – Fin planifiée

Retard d’une tâche terminée = Fin réelle – Fin planifiée

Le contrôle des coûts

Le contrôle des coûts est étroitement lié au contrôle de l’avancement.

Généralement, le retard qui s’accumule en cours de projet entraîne une hausse des coûts, puisqu’on tente habituellement de rattraper ce retard en augmentant les heures de travail. Rappelons que le coût total d’un projet se divise en trois
coûts distincts :

• le coût en ressources de chacune des tâches ;
• les coûts fixes associés aux tâches ;
• les coûts non répartis.

Pour effectuer le contrôle des coûts, le chef de projet doit dresser un budget des coûts par tâche. Ce budget permet de comparer les coûts planifiés initialement aux coûts réels du projet. La figure 8 présente un exemple de budget pour le projet étudié. Les renseignements qu’on y trouve sont obtenus grâce aux moyens suivants.

• On obtient le pourcentage d’avancement des tâches et le pourcentage global d’avancement du projet en se servant du tableau de suivi de l’avancement.
• Les montants du coût fixe planifié et du coût en ressources planifié de chacune des tâches proviennent de la planification initiale du projet. Ces montants permettent de calculer le coût total planifié de chaque tâche.
• Le coût planifié à ce jour est obtenu en multipliant le coût planifié de la tâche par son pourcentage d’avancement. On trouve ainsi le coût qui devrait avoir été engagé jusqu’à maintenant :

Coût planifié à ce jour = Coût total planifié X Pourcentage d’avancement

• Le service de la comptabilité de l’entreprise mandataire calcule le coût réel de chaque tâche. Dans le cas d’une petite entreprise, le chef de projet peut être appelé à tenir lui-même la comptabilité du projet. Le budget est alors constitué du coût des salaires engagés pour l’exécution de la tâche ainsi que des dépenses (équipement, matériel, location et autres frais) directement liées à la tâche.

• On obtient l’écart en calculant la différence entre le coût réel et le coût planifié à ce jour. Un écart négatif représente une économie, alors qu’un écart positif représente un dépassement du budget planifié.

Écart = Coût réel – Coût planifié à ce jour

On calcule la variation en pourcentage en divisant l’écart par le coût planifié à ce jour. Cette information constitue un outil de référence permettant de voir où ont été faites les erreurs de planification les plus importantes.

Variation = Écart / Coût planifié à ce jour

Le contrôle de la qualité

On mesure le contrôle de la qualité essentiellement de façon qualitative. Ce contrôle est principalement effectué sur les livrables plus que sur les tâches elles-mêmes. Le chef de projet ou le responsable du livrable doit s’assurer que les critères de qualité énoncés par le promoteur sont respectés. Généralement, on s’assure de la qualité de chaque livrable du projet afin de garantir que l’extrant soit composé d’éléments de qualité.

La section « Contrôle de la qualité » du rapport de suivi du projet est essentielle- ment composée d’un compte rendu de la discussion tenue entre le chef de projet et ses collaborateurs sur la perception de la qualité des livrables. Ce compte rendu
ne doit rapporter que l’essentiel des tests effectués, tout en permettant de vérifier si les critères de qualité énoncés lors de la définition du projet ont été respectés.

Les actions correctives

Le rapport de suivi fait état de l’avancement du projet, de la progression des coûts et du respect des normes de qualité. Dans la plupart des situations, le projet se déroule à peu près selon la planification initiale et aucune action particulière n’a à être entreprise. Toutefois, dans certains cas, des ajustements doivent être apportés par le chef de projet afin de pallier les problèmes éprouvés en cours de projet.

Ces ajustements portent principalement sur les tâches critiques, c’est-à-dire celles pour lesquelles on ne peut accumuler de retard sans compromettre la date de fin du projet. Lorsqu’il décide des ajustements à apporter, le chef de projet doit constamment tenir compte des trois contraintes inhérentes à tout projet : coût, temps et qualité.

Lors de la définition du projet, on a déterminé que le promoteur devait placer ces trois contraintes par ordre d’importance pour son projet. Dans des situations extrêmes où il est impossible de les respecter, le chef de projet doit se reporter à cette hiérarchisation des contraintes qu’a faite le promoteur.

Les ressources humaines doivent être au centre des préoccupations du chef de projet. Dans certains cas, celui-ci doit prendre des décisions difficiles

Les contradictions du rôle et l’éthique

La gestion de projet implique de faire face à de nombreuses contradictions.

Il arrive régulièrement que le chef de projet soit assis entre deux chaises. Il réalise le projet désiré par le promoteur, son client, mais il est rémunéré par le mandataire, son employeur. Il dirige une équipe de projet mais, hiérarchiquement, les ressources humaines qui lui sont prêtées pour la durée du projet ne relèvent pas de lui.

Les sections suivantes présentent le relevé qu’ont fait Gray et Larson des contradictions avec lesquelles le chef de projet doit composer quotidiennement. Ces contradictions l’amènent à devoir prendre des décisions qui font appel à son sens de l’éthique.

Innover ou maintenir la stabilité

On demande au chef de projet d’innover et de faire preuve de créativité dans la conduite de son projet. Toutefois, son équipe a besoin de stabilité pour bien fonctionner dans le cadre de projets parfois complexes et arriver à s’accoutumer à travailler avec des chefs dont les habitudes de gestion diffèrent.

Voir le projet de façon globale ou s’occuper des détails

Le chef de projet doit effectuer une planification détaillée de chacune des tâches et s’assurer de leur exécution dans le respect des contraintes défi- nies. Mais il doit éviter de porter son attention sur un seul arbre qui lui cacherait la forêt. Bien que le projet soit décomposé en un ensemble de tâches plus ou moins indépendantes, il ne peut être réalisé que s’il est envisagé comme un objectif global, celui de la livraison de l’extrant final.

Le chef de projet doit composer avec cette dualité et s’assurer que les ressources qui exécutent une tâche précise comprennent quel est leur rôle dans le processus.

Encourager les individus ou favoriser l’esprit d’équipe

On dit du chef de projet qu’il doit être un rassembleur, qu’il doit favoriser l’esprit d’équipe et la synergie au sein de son groupe. Toutefois, il doit aussi être celui qui arrive à motiver individuellement les ressources qui collaborent à son projet. L’équipe est constituée d’un groupe de personnes hétérogènes dont les objectifs individuels sont parfois divergents, voire incompatibles.

Déléguer ou intervenir

Le chef de projet doit déléguer ses responsabilités à certaines personnes clés. Toutefois, il demeure responsable de l’ensemble du projet, ce qui signifie qu’il est celui qui doit ultimement rendre compte de l’avancement du projet.

Faire preuve de flexibilité ou de fermeté

On demande au chef de projet d’être flexible, attentif et ouvert aux idées nouvelles. On lui demande de plus d’être un bon directeur et de contrôler l’avancement du projet, ce qui exige de la fermeté dans les cas où un retard est constaté et où le responsable n’a pas de solution à proposer.

Le chef de projet doit donc savoir faire preuve de flexibilité avec l’équipe et de fermeté quant aux échéances.

Accorder sa loyauté à l’équipe ou à l’organisation

Le chef de projet est placé dans une situation parfois inconfortable, comme celle du contremaître d’usine. Il travaille avec l’équipe de projet et agit donc en tant que représentant de ses employés auprès de la direction de l’organisation.

Toutefois, il relève de cette même direction et doit rendre des comptes sur son projet. Il doit donc être perçu comme un joueur d’équipe par les membres de l’équipe de projet, mais aussi comme un gestionnaire de haut niveau par la direction.