Gestion de projet : Analyse détaillée par question

Question 1 : partager une vision commune

Êtes-vous certain d’avoir obtenu durablement le consensus entre toutes les parties prenantes ? Vous êtes-vous bien compris avec votre client ? Comment vous en assurer ?

Êtes-vous certain que rien ne va changer ?

Malheureusement, le contexte où tout est défini à l’avance, formalisé clairement et stabilisé ressemble fort à une utopie, ou du moins est assez rare. Le chef de projet n’est qu’un élément d’une chaîne où les maillons précédents n’ont pas toujours pris la mesure des enjeux que constitue le lancement d’un projet. Sans commanditaire, sans objectif stratégique clair, sans priorité et sans financement approprié, le chef de

projet devrait être en droit de refuser de démarrer le projet, car il court de gros risques !

Heureusement, avec l’émergence de concepts tels que l’alignement du système d’information sur la stratégie, la maîtrise accrue des dépenses, la gouvernance et la prise de conscienceque l’informatique peut être une source de profit, on lance de moins en moins de projets sans justification réelle dans les schémas directeurs. Et le chef de projet doit avoir accès à ces informations capitales pour bien appréhender le contexte du projet. Exigez-les !

Question 2 : fixer un délai réaliste

La question n’est pas de savoir si le délai est fixe et immuable ; la question est de savoir s’il est réaliste compte tenu des objectifs et des moyens. Une échéance de fin de projet peut tout à fait être imposée par les contraintes du marché ou d’une réglementation, ou retenue par la direction pour une question stratégique ; c’est souvent le cas d’ailleurs ; on voit rarement un projet démarrer sans échéance. Par conséquent, contrainte ou estimée par le chef de projet, il n’est pas choquant que cette échéance soit contractuelle ; elle doit, dès lors, être respectée et maintenue, et non vécue comme l’échéance fatidique. C’est ce qu’on appelle le timeboxing. Cela signifie que, dans le triptyque des 3 la dimension calendrier est fixe et que les deux autres dimensions (contenu et coût) sont éventuellement ajustables, à la baisse pour l’une, à la hausse pour l’autre.

La difficulté réside plutôt autour de deux problématiques : d’une part, celle du calcul de cette échéance, plus ou moins fiable selon la précision et la pérennité des éléments de calcul ; d’autre part, celle du respect des objectifs à atteindre et de la conformité du contenu aux engagements pris. On peut donc s’engager sur un délai mais plus difficilement sur un contenu détaillé, étant donné les nombreuses incertitudes qui entourent le projet.

.

Question 3 : adopter une démarche rigoureuse de recueil des besoins

Il est illusoire de penser que tous les besoins peuvent être exprimés lors de l’initialisation du projet pour une série de raisons qui seront détaillées ultérieurement. S’ils le sont, est-on sûr qu’ils correspondent exactement à ce que veut le client et à ce qu’il voudra à la fin de la réalisation ? Le gel des besoins donne-t-il une garantie de succès au projet ? Ce qu’il est important d’obtenir, ce sont des besoins, même de haut niveau, recueillis sur un mode consensuel et priorisés. Vouloir attendre de la maîtrise d’ouvrage un cahier des charges exhaustif, détaillé et définitif nous plonge dans le piège de la sur-spécification ; à l’inverse, partir de « rien » ou de très peu ne donne pas une orientation effective au chef de projet. Le juste milieu est à trouver avec les utilisateurs ou leurs représentants pour démarrer au plus vite sans avoir à faire marche arrière, en adoptant une démarche rigoureuse.

.

Question 4 : collaborer avec la maîtrise d’ouvrage

S’il est indispensable d’avoir un interlocuteur unique du côté de la maîtrise d’ouvrage, celui-ci doit bénéficier d’une réelle autonomie et d’un pouvoir de décision. En effet, ce n’est pas au chef de projet d’arbitrer entre les différentes voix, dissonantes parfois, des utilisateurs ; il doit s’assurer que son interlocuteur est bien le représentant de tous les utilisateurs et lever tout risque. Une connaissance des rouages d’un projet est un plus pour cet interlocuteur qui doit s’impliquer dans la vie du projet. Néanmoins, un contact permanent avec les utilisateurs finals est capital, lorsqu’il est possible. Leur implication dans la vie du projet est un facteur de succès : pour la compréhension de leurs exigences, pour obtenir leur feedback sur les premiers développements, pour une meilleure transparence sur les contraintes de l’équipe, bref pour une collaboration étroite, tout au long du projet.