Conduite de projet

2 janvier 2003

Le but de la conduite de projet est d'assurer la relation avec le fournisseur pendant toute la durée de la réalisation, en se donnant pour but la réussite du projet - c'est-à-dire la mise en exploitation d'un produit conforme aux spécifications, dans les conditions prévues de délai et de coût. 

Nous avons vu que la majorité des projets informatiques échouaient en cours de route, ou connaissaient des dépassement de coût et de délai considérables (voir "Méthodes concernant un projet"). L'enjeu de la conduite de projet est donc important.

Le plus souvent, l'application est réalisée par une SSII, mise en exploitation par la direction de l'informatique, et utilisée par un métier de l'entreprise. C'est ce dernier (maîtrise d'ouvrage) qui est donc le client final de la SSII ; il lui revient donc, en principe, d'assumer la responsabilité de la conduite du projet ainsi que la vérification du service fait et la gestion du budget. Dans les faits, cependant, ces diverses tâches sont souvent déléguées à la direction informatique, car l'on pense que "tout ça, c'est de l'informatique" ; il en résulte parfois des dommages, les impératifs techniques de la plate-forme informatique recevant plus de poids dans les arbitrages que les besoins du métier. 

Cette forme d'organisation tend toutefois à disparaître pour être remplacée par une autre organisation, dans laquelle la maîtrise d'ouvrage prend toutes ses responsabilités. Mais il faut pour cela qu'elle soit dotée de personnes compétentes, et c'est le plus grand frein à cette évolution. 

Organisation de la conduite de projet

L'organisation qui convient à la conduite de projet dépend de la taille du projet, de la place du processus concerné parmi les métiers de l'entreprise (est-il propre à un métier, est-il transverse à plusieurs métiers ?), de l'importance du projet en regard de la stratégie de l'entreprise etc. L'organisation doit donc être définie au coup par coup, et il n'existe pas de forme d'organisation générale s'imposant à tout projet. 

Nous allons ci-dessous décrire quelques-uns des éléments que l'on rencontre le plus souvent dans l'organisation de la conduite de projet, et signaler des pièges qui peuvent se présenter. 

Directeur de projet

Le but du projet est de fournir un produit utile à une maîtrise d'ouvrage. Il est donc naturel que la direction du projet soit confiée à un représentant de la maîtrise d'ouvrage, dûment mandaté par le maître d'ouvrage stratégique (qui sera, selon la nature du projet, le directeur d'un des métiers de l'entreprise ou le DG lui-même). Il "coiffe", dans la structure de projet, les experts qui représentent la maîtrise d'ouvrage et ceux qui représentent la maîtrise d'œuvre (CP MOA et CP MOE), et il arbitre leurs éventuels conflits. Il est assisté par un chef de projet pilotage, chargé du reporting et du suivi de l'exécution des décisions. Il lui revient de définir dès le début du projet avec ces trois responsables le contour de leurs missions, l'échéancier des travaux que chacun doit réaliser, la nature de leur coopération. 

Il faut que son mandat constitue une vraie délégation de responsabilité : un directeur de projet dont les décisions seraient fréquemment désavouées par le mandataire deviendrait rapidement un "zombie", un personnage falot dont le rôle n'est pas même symbolique. 

Il faut aussi que ce directeur puisse réellement diriger le projet, et qu'il dispose pour cela des informations nécessaires sur la qualité de la réalisation, sur la tenue des délais, sur l'avancement des travaux, sur la situation du budget (voir ci-dessous le paragraphe consacré au reporting). Il arrive souvent que la partie financière du projet soit entièrement gérée par la direction informatique, qui soit par désordre, soit par désir d'indépendance, ne fournit pas les informations nécessaires au directeur de projet. Il serait préférable - mais c'est une disposition rarement prise - que le directeur de projet fût investi de la responsabilité du suivi du contrat et de la certification du service fait qui déclenche le paiement des factures. 

Souvent le directeur de projet, estimant son affaire déjà bien assez difficile à réussir, cherche à se libérer des contraintes de cohérence du système d'information et à s'isoler du reste de l'entreprise. Rien n'est plus difficile que d'organiser une réunion de coordination entre plusieurs directeurs de projet ! Or le manque de cohérence du SI serait dommageable pour l'entreprise. Il revient à la coordination des maîtrises d'ouvrage (la MOAD auprès du DG) de veiller à établir des passerelles entre les divers projets, et à assurer le dialogue indispensable entre les directeurs de projet malgré leurs réticences. 

Tout suivi de projet est scandé par les réunions de divers comités (voir ci-dessous). L'expérience, fort pénible, montre que ces réunions sont souvent longues et confuses, sans ordre du jour, durée limite ni compte rendu. Or la conduite du projet dépend pour une bonne part de la qualité de ces réunions. Il faut respecter quelques règles :
- il est interdit en réunion de critiquer une personne absente, ou une entité qui n'est pas représentée, car il faut avant tout respecter le droit de réponse ; 
- l'ordre du jour de la réunion doit être établi avant la réunion, éventuellement complété en début de réunion, et rigoureusement suivi ; à chaque point doit être accordée une durée limite qu'il faut respecter, ainsi que la durée totale de la réunion ;
- les tâches décidées en réunion doivent être affectées à une personne ou une entité précises (ne jamais dire "on va faire cela" à la cantonade, sans désigner celui qui devra le faire) ; 
- les décisions doivent être notées par le CP pilotage, leur exécution doit faire l'objet d'un pointage lors des réunions suivantes. 

Outre son rôle purement technique et professionnel, le directeur de projet doit se soucier de "l'ambiance" du projet. Tout grand projet comporte des moments de crise, de doute, voire de désespoir ; dans ces moments-là les responsables cherchent moins à faire leur travail qu'à faire porter par d'autres la responsabilité d'un échec qui semble inévitable. Il faut alors du talent pour apaiser les conflits, restaurer ou maintenir l'espoir de succès : le directeur de projet doit maîtriser l'expression de ses sentiments. En général il devra afficher de la sérénité et se comporter avec bonhomie envers les personnes ; en de rares occasions, il devra aussi manifester de l'inquiétude et se mettre en colère. La gestion de la psychologie collective d'un projet est un art aussi délicat que la diplomatie. 

Comité directeur

Le comité directeur, mensuel ou trimestriel selon les projets, réunit le directeur de projet, le directeur informatique, le DG, les directeurs concernés par le projet, et les experts invités (y compris ceux qui représentent le fournisseur, au moins pour une partie de la réunion). Son but est de vérifier que le déroulement du projet est bien conforme aux objectifs stratégiques de l'entreprise, notamment en ce qui concerne les délais et les coûts. 

L'expérience montre que ces réunions sont souvent édulcorées, personne n'osant en présence du DG et devant des directeurs plus ou moins anxieux émettre la moindre alarme ni poser une question de simple bon sens. 

Il revient au DG de faire en sorte que le comité directeur ne soit pas une chambre d'enregistrement où personne n'ose dire la vérité : si le DG donne le mauvais exemple en faisant taire celui qui émet un signal d'alarme, les réunions du comité directeur seront vides de contenu. 

Comité de pilotage

Le comité de pilotage est hebdomadaire ou mensuel selon l'importance du projet. Il réunit le directeur du projet, les chefs de projet MOA, MOE et pilotage, ainsi que les experts invités. Périodiquement, le fournisseur lui-même est invité. C'est la réunion principale pour la conduite de projet, c'est là que se prennent les décisions essentielles au vu des reportings et des alarmes émises par les parties en présence. La qualité de ces réunions dépend du directeur de projet, et de l'importance qu'il attache à la rigueur dans le suivi de la réalisation et des décisions prises. 

Comité d'avancement

Le comité d'avancement est hebdomadaire ; il réunit les chefs de projet MOA, MOE et pilotage, ainsi que les représentants du fournisseur. Il a pour but de repérer et de régler les divers problèmes d'ordre matériel ou organisationnel que pose la réalisation : disponibilité des locaux, serveurs et postes de travail ; turn-over des personnes ; tenue des délais de production des divers livrables ; traitement des alarmes émises lors des comités précédents. 

Reporting du projet

Le projet doit faire l'objet d'un compte rendu régulier ("reporting") qui permette d'évaluer clairement sa situation. Les reportings présentent souvent des défauts : 
- trop lourds, ils sont difficiles à lire et l'information utile est noyée dans un fatras de nombres et de graphiques ;
- remplis à la va-vite, ils comportent des incohérences qui sautent aux yeux : on passe plus de temps à se les faire expliquer qu'à traiter les problèmes ;
- ils présentent les derniers événements sans les rattacher à l'historique du projet, ce qui rend difficile leur interprétation : si par exemple le fournisseur dit "la livraison du lot 3 sera reculée de trois semaines", le sens de cette phrase n'est pas le même si cette échéance a déjà été reculée plusieurs fois ou non ; 
- ils obéissent de façon pédante au formalisme d'une "méthode qualité", sans y faire le tri entre l'important et l'accessoire (c'est un symptôme d'incompétence, ou pis de mauvais esprit). 

Nous avons proposé une méthode pour établir un reporting simple et utile (voir "Pour un suivi de projet efficace"). 

Les personnes engagées dans le projet jugent bien naturellement le travail de production plus important que le reporting, qu'elles considèrent comme une corvée. C'est ce qui les pousse à le remplir à la va-vite, sans se soucier de l'exactitude des informations fournies. On voit ainsi apparaître dans le reporting des erreurs manifestes (comme un taux de réalisation de 150 %), ou un échéancier prévisionnel qui ne tient aucun compte des retards enregistrés dans le passé. Pour que le reporting soit sérieusement rempli, il faut (1) qu'il porte la signature d'une personne chargée de vérifier l'exactitude de toutes les informations qu'il contient, et qui sera donc responsable des éventuelles erreurs ou lacunes ; (2) que les exécutants sachent qu'à l'occasion certains des reportings peuvent remonter jusqu'au sommet de l'entreprise, et susciter des décisions. 

Il est salubre en effet de faire parvenir au DG une sélection des reportings. Un DG conscient de l'importance du SI doit se faire communiquer systématiquement les reportings mensuels des dix à quinze principaux projets ; et on doit lui montrer les reportings des projets de moindre importance, mais qui rencontrent des difficultés et sur lesquels on risque de devoir lui demander des décisions.