Mister No

velpeauDes spécialistes nombreux et caractériels, des conflits potentiels entre maîtrise d’œuvre et maîtrise d’ouvrage. La construction d’un système d’information suppose une coordination efficace qui est assurée par le chef de projet. Celui-ci est le garant de l’avancement, le responsable de la livraison du produit.

Les outils de gestion du projet

Faisons un tour des outils qui permettent au chef de projet d’asseoir son autorité.
Il y a d’abord le plan d’assurance qualité. Il définit les rôles de chacun des participants, les livrables principaux à prévoir, les conditions de réalisation… Ce document est sensé évoluer au fur et à mesure de l’avancement du projet, mais bien souvent il repose dans un placard, à peine fini, dès que chacun a compris son rôle. Il n’est ressorti qu’en cas de crise gravissime, chacun des participants se le renvoyant à la figure.
Il y a l’analyse de risque. Un projet comporte un grand nombre d’inconnues, d’évènements ou de sujets qui peuvent le faire capoter. Il n’est pas possible de tous les contrôler. L’analyse de risque permet de déterminer les plus probables et les plus dangereux, pour concentrer sur eux les efforts. Elle demande du temps et des ressources particulières (avoir un bon spécialiste est utile). Bien faite, associant toute l’équipe projet, permettant à tout le monde de parler sans langue de bois, l’analyse de risque peut être un bon moyen de souder l’équipe projet et de préparer un plan d’action contre les dangers qui menacent le projet. Mais couteuse et difficile à réaliser elle n’est pas toujours faite.
Puis, il y a le planning. Ce document ne cesse d’évoluer et tout le monde a les yeux rivés dessus. Il existe plusieurs manières de le présenter : PERT, présentation des taches avec les liaisons entre elles, GANT, présentation sous forme graphique (la plus habituelle car la plus facile à visualiser). Dans tous les cas, l’objectif est de positionner les taches à accomplir et leur moment de réalisation.

La tyrannie du planning et du budget

Pourquoi cette obsession du planning ? Un chef de projet répétait comme un mantra « à l’heure à peu près bien, plutôt que parfait en retard ». Le respect du planning a différentes vertus.
D’abord le temps c’est de l’argent. Un projet qui tarde, c’est des équipes qui restent mobilisées, et donc des coûts qui augmentent. Dans ce cas, la hiérarchie commence à titiller l’équipe, pour savoir pourquoi le projet est un panier percé.
Ensuite, un projet correspond souvent à une attente à un moment. Livré trop tôt, il est inutile, trop tard, il est déjà dépassé.
Puis le respect du planning a pour vertu de maintenir la mobilisation du groupe. Les équipiers savent que leur travail est attendu, s’inquiètent de leur retard, comme de celui des autres.
Car le délai est l’indicateur le plus facile à suivre de réussite d’un projet. Ce n’est pas nécessairement le plus pertinent, mais le plus simple à comprendre. Un projet dont le planning dérive perd la confiance de son équipe, de ses clients et de ses futurs utilisateurs. Le retard génère du retard. Les troupes se démobilisent. Le commanditaire devient tatillon, réclame des justificatifs qui prennent du temps, un temps qui manque déjà. Les futurs utilisateurs s’inquiètent, et commencent à trouver des défauts au produit avant même de l’avoir vu.

Résister aux sollicitations

Enfin un projet dont les délais dérivent est un projet sollicité.
La définition d’un projet est toujours un compromis. Il a fallu trouver une voie entre les besoins des utilisateurs, la volonté du commanditaire, les ressources de la technique, les moyens financiers du projet. Un certain nombre d’options ont été abandonnées, des sujets mis de coté. Au cours de l’exécution, les concepteurs-développeurs découvrent que certains aspects ont été oubliés, et complètent idéalement le système d’information qu’il faut livrer.
L’équipe projet a la hantise de ne pas répondre au besoin, de produire un système d’information inutile, qui sera abandonné à peine terminé, par oubli d’un détail essentiel à le rendre convivial. La tentation est grande d’ajouter de nouvelles fonctionnalités. Les solliciteurs se précipitent. Utilisateurs frustrés, maîtres d’ouvrage qui changent d’avis, et mêmes concepteurs-développeurs appartenant à l’équipe qui ont leurs marottes, leurs idées sur ce qui serait indispensable. Individuellement chaque idée est bonne. Mais leur accumulation rend le produit incontrôlable, le résultat ne peut être fiabilisé, et le projet passe de l’accumulation des retards au naufrage industriel.
Il y a quelque chose d’injuste dans cette importance du planning. Quelques mois, quelques années après, le système d’information est toujours là et la contrainte de délai a été oubliée. Les utilisateurs et les équipes chargées de la maintenance se demandent pourquoi tel aspect n’a pas été traité, pourquoi tel développement est insuffisamment testé, pourquoi telle solution semble aussi peu ergonomique. Mais tenir le délai a trop d’avantage pour être négligé et demeure le mot d’ordre pour le chef de projet.

Le maître du temps

Le chef de projet n’est pas le personnage le plus important du projet. Il peut y avoir dans son équipe des spécialistes plus compétents et mieux payés que lui. Le plus souvent il n’est pas non plus l’employeur et le responsable hiérarchique des membres de l’équipe (même s’il a son mot à dire sur leur choix et leur évolution de carrière).
Il se définit plutôt comme un entraineur de football. Il motive tout le monde, positionne chacun sur le terrain, choisit les remplaçants qui doivent entrer. Il décrit la stratégie globale à suivre, en laissant assez de liberté aux joueurs pour qu’ils soient créatifs (il ne peut pas taper dans le ballon à leur place). De même, le chef de projet n’est ni le patron, ni celui qui fait le système d’information, juste le coordinateur.
Dans sa tache, le chef de projet est souvent assisté par le PMO (Project Management Office), personnage généralement jeune, chargé d’actualiser le planning, de suivre le budget, de contrôler l’exécution des différents livrables (code, reprise de données, formation, etc.). Il court en tout sens et prépare le comité de pilotage (COPIL).
Le comité de pilotage a lieu régulièrement. Suivant les projets et mêmes les moments du projet, il a lieu tous les jours, toutes les semaines, plus rarement tous les mois. Ce qui importe c’est qu’il permette d’orienter au plus tôt lorsqu’apparaît une nouvelle question. Il rassemble tous les acteurs du projet ou au moins les responsables des principaux livrables, et il est présidé par le chef de projet.
Au cours du COPIL, sont examinés l’avancement des livrables, le suivi du budget et des ressources, l’état du plan d’action suite à l’analyse de risque, et tous les problèmes qui peuvent surgir et menacent la livraison.
Un bon planning laisse du temps aux concepteurs-développeurs pour concevoir, développer et tester des solutions innovantes, répondant au plus près aux besoins des utilisateurs et du maître d’ouvrage. Il doit aussi laisser de la place pour gérer l’impondérable, permettre d’intégrer une nouvelle tache qui n’était pas prévu.
Pour conserver cette marge de manœuvre, le chef de projet doit repousser toutes les sollicitations inutiles, qui retarderaient le planning. Il doit savoir dire non, piétiner les egos, refuser les idées sans doute très bonnes, mais qui menacent la cohérence du projet, sa logique, et font du livrable final un monstre inexécutable et mal testé. Il est « Mister No », celui qui permettra à son équipe d’être inventive.

Cet article, publié dans gouverner, maitrise d'ouvrage, système d'information, est tagué , , , . Ajoutez ce permalien à vos favoris.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s