Organiser le projet

Mode de pilotage

Maintenant que nous en savons plus sur ce projet, qui le finance, qui est impliqué directement et indirectement, quels sont les objectifs à atteindre et les moyens évoqués, il nous reste à déterminer comment nous allons le gérer. Pas en termes de méthode ou méthodologie à utiliser, mais plutôt quel mode de pilotage nous allons mettre en œuvre et quels sont nos leviers. Vous connaissez certainement le fameux triangle coût/délai/qualité permettant d’orienter la conduite d’un projet.

Nous sommes d’accord, il n’est pas possible de concilier toutes ces exigences. Eh bien, ce triptyque est l’outil le plus inefficace qui existe. Il est censé indiquer sur quel axe le directeur de projet pourra influer pour garder le contrôle de la situation. Dans les faits, ça ne fonctionne pas.

Principalement, parce que le facteur coût n’est jamais un axe de négociation. Tous les projets sont soumis à des coûts fixes ou dont la variable d’ajustement est insuffisante pour jouer un rôle réel. Il n’y a que dans les films de science-fiction que le commanditaire déclare « l’argent n’est pas un problème ». Dans la vraie vie, si vous posez naïvement la question au sponsor projet, il déclarera que l’objectif principal est la qualité et qu’au passage il s’est engagé personnellement à ce que le projet sorte en décembre. Information que vous avez normalement déjà obtenue, lors de la phase de collecte des objectifs.

Certains auteurs expliquent cette méthode en indiquant que la qualité contient également le périmètre, d’autres, qu’elle représente également l’adaptabilité. Si sur le plan académique l’argument est défendable, en réalité, l’ensemble devient alors tellement flou et confus qu’il n’est plus possible de parler de pilotage. Soit le directeur de projet a la mainmise sur tout ce qui constitue le projet, ce qui est une vision chimérique de sa fonction, soit il ne contrôle plus rien et doit en référer aux uns et aux autres en permanence, incapable de proposer des solutions cohérentes...

Contrainte majeure

Lorsque nous avons défini le mode de gestion de projet à l’aide de la matrice pyramidale, nous avons établi qu’il était fort possible qu’un des axes de cette matrice doive demeurer inamovible. C’est donc notre contrainte majeure sur ce projet. Si le projet doit respecter un niveau de sécurisation militaire ou bancaire et un niveau de disponibilité supérieur à 99,5 %, notre axe qualité est clairement une contrainte stricte à respecter.

Cette information doit être partagée par tous les membres du projet, quel que soit leur niveau d’intervention. Cette contrainte est majeure, et tout le monde doit en avoir conscience en permanence.

Au fur et à mesure de la définition du projet, d’autres contraintes seront découvertes. Elles seront ventilées dans différentes thématiques : d’image, techniques, légales, sociales... Certaines peuvent avoir une ampleur nécessitant de les classifier non pas dans une thématique en tant que contrainte classique mais en tant que contrainte majeure.

Par exemple, la mise en œuvre d’un projet de mesure de la qualité d’un réseau de distribution, comportant une révision de la rémunération des agents, offrant un nouveau mix qualité/quantité en remplacement du seul critère...

Constitution d’une liste exhaustive des contraintes

Comme nous venons de le voir, il arrive qu’un projet soit porteur de plusieurs contraintes. La portée de ces dernières peut parfois même surpasser les objectifs du projet (coût, délai, périmètre, qualité). De fait, il est fréquent de confondre ou de mélanger une contrainte et un objectif. Une contrainte découle souvent d’un objectif, mais ne peut en aucun cas être le résumé de celui-ci.

Afin d’être le plus objectif et exhaustif possible dans la rédaction des contraintes, il faut commencer par analyser la portée et les impacts des objectifs et moyens mis en œuvre, puis replacer ces éléments dans leur contexte concurrentiel. Il faut étudier avec soin ce qu’il faut faire et ce qu’il ne faut surtout pas faire et quels sont les risques avérés (donc non pilotables puisqu’ils sont déjà avérés).

Une réunion de travail en petit comité avec les maîtres d’ouvrage peut donner d’excellents résultats si elle est bien préparée. Cela signifie que l’ordre du jour n’a pas simplement été communiqué, mais que les participants ont été informés en tête à tête afin de bien la préparer.

Macroplanning

Pour l’instant, nous ne cherchons pas à avoir une vision détaillée, mais plutôt à fixer les grandes lignes afin de pouvoir répondre à la sempiternelle mais légitime question du Quand. Cette question peut d’ailleurs être déjà tranchée par un objectif de délai. Par exemple, le bug de l’an 2000 devait être résolu avant le 31 décembre 1999. C’est un véritable objectif de délai. Il y a dans ce cas une réelle contrainte à gérer. Dans les autres cas, il s’agit de donner à l’exécutif des informations sur la mise en service du produit car d’autres actions peuvent dépendre de cette date. Élaborer assez tôt un macroplanning permet également d’informer les acteurs du projet sur leur disponibilité attendue et de révéler ainsi un certain nombre de contraintes ou de risques.

Si les utilisateurs doivent être impliqués lors de la réalisation, il faut s’assurer qu’ils seront disponibles à cette période. Cela conduit ainsi à déterminer non seulement quand le projet pourrait être achevé, mais également à quel rythme devront s’étaler les itérations, et s’il est nécessaire d’aménager une pause en cours de projet.

Définition du périmètre fonctionnel

Un projet est composé de lots, eux-mêmes scindés en features (fonctionnalités), dans lesquelles on trouve plusieurs user stories qui seront réalisées par plusieurs tâches différentes.

Certains appellent cette tâche le feature plan, l’architecture fonctionnelle, ou les spécifications fonctionnelles générales. Craig Larman apporte une vision beaucoup plus élégante en écrivant : « Try…Think ‘gardening’ over ‘architecting’ ». Cela pourrait effectivement s’apparenter au travail préalable qu’effectue un paysagiste dans les jardins de Versailles.

L’objectif est de chercher à identifier un ensemble de fonctionnalités (features) cohérentes avec les objectifs du projet. Si plusieurs solutions répondent à un même objectif, cela permet de les départager ou de proposer une aide à la décision. Cela permet également de savoir si certaines fonctionnalités sont liées entre elles. On parle alors de couplage.

Un simple tableau indiquant les fonctionnalités attendues dans le périmètre, ordonnées en must have et nice to have permet d’y voir plus clair. Pour le réaliser, plusieurs solutions peuvent être utilisées en fonction de la problématique à étudier.

Identification des dépendances

Tant que nous sommes dans la liste des fonctionnalités, identifier les liens entre elles nous permettra ultérieurement de gagner un temps précieux.

Les dépendances, ou le couplage, se définissent par l’adhérence entre deux fonctionnalités. Si l’on remplace l’une, on envisage fortement de remplacer l’autre. Si l’on modifie ou conçoit l’une, il faut avoir une vision précise de l’autre, car elles sont liées par cet effet de couplage. Par exemple, si nous avons un gestionnaire de contenu référençant les différents médias, un moteur de recherche, des gabarits de présentation web et des gabarits mobile et tablette, nous pouvons souhaiter avoir une adhérence faible entre chaque élément et pouvoir les modifier indépendamment les uns des autres. Mais nous pouvons à l’opposé imaginer qu’ils sont indissociables, auquel cas il convient de définir qu’ils ont un couplage fort.

Il est fréquent de constater que le couplage applicatif est considéré comme un état de fait alors que c’est fondamentalement un besoin. Il correspond à une vision à long terme que le sponsor du produit doit avoir. Cette vision étant fortement liée à des prospectives technologiques, si le sponsor...

Acteurs du projet

Un projet d’envergure suffisante pour mobiliser un directeur de projet implique souvent plusieurs acteurs dans une entreprise. Il peut s’agir de responsables de division, ou de leurs représentants, d’experts métier, de ressources transversales comme les services financiers, de ressources humaines, d’informatique, de qualité, d’innovation ou de conduite du changement. Si pour des projets relativement simples, on identifie clairement le MOA et le MOE, lorsque le projet implique de nombreux intervenants, ces notions peuvent devenir confuses, et les acteurs se multiplier sans que l’on sache clairement quel est leur rôle ou leur influence potentielle. Il arrive parfois que le pouvoir de décision du MOA soit dilué dans des fonctions de MOAD (MOA délégué), AMOA (assistance à MOA) ou MOAO (MOA opérationnelle).

La multiplication des acteurs donne parfois lieu à des règlements de comptes totalement externes au projet, mais qui peuvent fortement impacter celui-ci. De plus, la dilution de l’exécutif peut rendre la gestion du projet et des conflits très complexe. S’il n’est pas clairement missionné comme détenteur d’un pouvoir, le directeur de projet doit alors faire preuve de diplomatie et passer plus de temps à gérer des consensus qu’à gérer son équipe....

Les locaux

L’organisation de l’espace de travail peut sembler anecdotique, néanmoins l’application stricte des méthodes agiles et les études sur la dynamique des groupes impliquent de prendre très sérieusement en compte cet aspect.

Dans un schéma traditionnel de gestion de projet, le chef de projet représente pour l’équipe un leader imposé disposant d’une autorité qu’il peut appliquer à sa guise. Dans ce contexte, il est préférable qu’il soit isolé du reste de l’équipe, disposant de son propre bureau. Une war room regroupant tous les chefs de projets, à proximité d’un open space où sont situées leurs équipes renforcera cette autorité.

Ce mode d’organisation offrant l’avantage de gagner 20 % à 40 % d’espace, il est souvent mis en œuvre pour des raisons économiques, mais il renforce la culture hiérarchique, voire autoritaire. Le manager disposant alors d’un bureau, même s’il pratique la politique de « ma porte reste toujours ouverte », sera inévitablement considéré comme un employé à part, effectuant une tâche bien plus importante que ses collègues (ou subordonnés), qui nécessite qu’il doive pouvoir s’isoler....

Outils projet

Nous ne parlerons pas de la pléiade de solutions de gestion de projets agiles qui existent en ligne, tel Scrumwise permettant de mettre en œuvre tout ou partie des principes agiles. Toutes ces solutions reposant sur un cloud dont on ne connaît quasiment rien, disponibilité, GTR (garantie de temps de rétablissement), représentent beaucoup de risques impossibles à mesurer.

En revanche, cinq outils indispensables doivent être disponibles et si ce n’est pas le cas, il convient d’anticiper sur leur mise en œuvre afin de ne pas devoir apprendre à s’en servir en plein projet.

1. Modeling UML

2. Contrôleur de source

3. Intégration continue

4. Bug tracker

5. Solution de test

Il faut également prévoir des solutions plus génériques comme un intranet dédié ou un Wiki, une visioconférence si l’intégralité des acteurs n’est pas réunie dans les mêmes locaux, des adresses e-mail spécifiques en cas de sourcing de sous-traitants, ainsi que les éventuels badges et accès aux locaux. Enfin...

Évaluation des risques

Les risques sont inhérents à tout projet, qu’il soit informatique, industriel, humain... Refuser de l’admettre revient à dire « j’ai choisi de ne pas choisir » (Mark Renton, 1996).

Le premier risque à évaluer concerne le projet lui-même.

S’il nous semble que ce n’est pas un projet risqué, ou au contraire que déployer ce projet induit des risques, il faut informer le sponsor et valider avec ce dernier notre évaluation. Les risques, ou leur absence, doivent être connus, identifiés et acceptés. S’ils sont inacceptables, à moins de les réduire, il faut arrêter le projet, ou reporter son lancement à une date ultérieure.

Il n’est pas raisonnable de dresser une liste exhaustive des risques inhérents au projet. Il y aura toujours un risque qui sera oublié et une liste trop étendue ne sera plus pilotable efficacement. Imaginez de devoir piloter deux cents risques au quotidien...

Chercher à gérer l’intégralité des risques est aussi dangereux que de les ignorer totalement. La priorité doit rester le développement de l’application, et non la gestion de l’environnement. Accepter d’assumer des risques, c’est le rôle d’un manager, c’est une des raisons qui justifient son salaire plus élevé.

Il faut donc identifier les risques majeurs, et pour cela, il convient d’évaluer leur criticité. Alors seulement, il sera possible de les piloter.