Commentaires sur : Mauvaise définition des exigences ? En réalité, c’est votre faute http://dantotsupm.com/2010/07/20/mauvaise-definition-des-exigences-en-realite-cest-votre-faute/ à la recherche du meilleur du management de projet Sat, 25 Feb 2012 09:40:29 +0000 hourly 1 http://wordpress.com/ Par : P.E. Pernet http://dantotsupm.com/2010/07/20/mauvaise-definition-des-exigences-en-realite-cest-votre-faute/#comment-237 Tue, 20 Jul 2010 10:22:36 +0000 http://dantotsupm.com/?p=2436#comment-237 Bonjour,
En lisant cet article, 2 réflexions me viennent à l’esprit:
La notion de «Requirements» est différente de celle «d’exigence». Le «requirement» est un besoin, il fait partie de la définition intégrante de l’objectif du projet : mon produit, mon logiciel, ma nouvelle organisation doit réaliser telle fonction. L’exigence, pour moi, définit les condition dans lesquelles cette fonction doit être réalisée et cela couvre autant les aspects définition de la fonction que les aspects qualitatifs du produit ou du processus qui permettra de réaliser cette fonction (PAQ projet). Je suis conscient que nous entrons là dans une sémantique qui peut paraître complexe mais je reste persuadé qu’il faut être capable de distinguer le «que faire» du «comment et dans quelles condition le faire»
Sur la capture de ces besoins : Oui, si un chef de projet de se retrouve dans une situation où il doit faire face à un problème lié à la mauvaise définition des besoins, c’est de sa faute. Comme nombre de mes collègues, j’ai moi aussi à mes débuts fait entièrement et aveuglément fait confiance au cahier des charges qui m’était remis pour débuter les travaux … jusqu’à ce que je me rende compte qu’il était incomplet, orienté par une partie au détriment des autres, incohérent etc… Ces expériences m’ont appris à maintenir ou imposer systématiquement, de façon clairement autonome ou au sein d’autres tâches, une revue et une validation des besoins par les différentes parties prenantes et/ou groupes de travail. Cette étape, qui peut être rapide, permet non seulement de valider la compréhension du besoin mais également, avec les parties prenantes «stratégiques», de capturer leur ressenti sur cette expression de besoin et d’en déduire s’ils feront partie des supports ou des opposants, initiant par là l’analyse des parties prenantes ! Ces échanges, qu’ils soient en face à face ou en groupe de travail, permettent également de capturer ces fameux besoins implicites ou «non-dits» que ne peuvent véhiculer le papier. Ce point est très important si vous agissez comme prestataire de service, extérieur à la société ou au service dont ce n’est pas votre métier d’origine. Rédiger un cahier des charges est une opération longue, fastidieuse et parfois complexe. Quand cette opération est faite en interne, il arrive souvent que certaines spécificité ou contraintes liées au métier, qui sont naturellement admises et intégrée par la personne en charge de cette rédaction, soit purement et simplement omise tellement elles semblent naturelles. A vous de les capturer sous peine de vous retrouver dans une situation difficile. Il en va de même pour les cahier des charges «politique», rédigés d’une certaine façon pour être certains d’avoir son projet, même si, en réalité, on aimerait les choses un peu différemment…

Maintenant, que risque t’on à ne pas faire cette analyse des besoins et à faire une confiance absolue dans son Agilité ? Et bien, les risques sont multiples : dépassement de temps ou de budget à force de redécouvrir ou revenir sur de nouveaux besoins (je vous renvois à la notion scope-time-costs ainsi qu’au principe de temporalité d’un projet), à se retrouver écartelé entre le cahier des charges signé, approuvé par le comité de pilotage … et la réalité du terrain qu’il faudra expliquer, etc …
Le changement fait partie intégrante d’un projet, c’est une des mécanique de l’élaboration progressive qui caractérise le mode projet. Tenter de stopper c’est mettre fin à toute créativité de ses équipes et donc s’interdire l’innovation ou l’apport de valeur ajoutée.
Il faut donc trouver un juste milieu en validant ces besoins, exprimés ou non et en répondant de façon raisonnée aux changement. Pour cela, il faut conserver en tête les règles d’une bonne gestion du changement : quel apport sur mon produit final ? Quel impact (temps, coûts) ? Quelle justification ? Est-ce de mon ressort ou de celui du comité de pilotage ?

]]>