Voici un article de Jesse Fewell qui m’a paru intéressant: « Bad Requirements? Actually, That’s Your Fault »
Je suis fatigué des chefs de projet qui se plaignent de la mauvaise qualité de la définition des exigences. La vérité est que personne ne devrait s’en étonner. Dans la recherche comme dans les désastres très visibles, nous entendons dire que des exigences incorrectes et la mauvaise gestion du contenu sont des raisons principales d’échec des projets. Si nous savons que c’est un problème commun de notre profession, pourquoi continuons-nous stupidement à répéter ce qui ne marche pas ? Je voudrais partager quelques suggestions pour nous empêcher de trébucher sur ces mêmes erreurs :
Abandonnez l’illusion d’obtenir des exigences complètes.
Il y a toujours une dépendance manquée, une partie prenante que nous n’avons pas interviewée, une nuance cachée, ou une chose que nous regretterons de n’avoir pas su. Ne tombez pas dans le piège de penser que davantage est toujours mieux ou vous ne commencerez jamais.
Supposez toujours que les besoins initiaux sont faux.
Parfois la définition du contenu est trop inclinée vers une partie prenante ou n’a pas été correctement examinée de près. Parfois la plus grande partie des exigences sont en réalité seulement des choses « agréables-à-avoir ». De nos jours, on s’attend à ce que le chef de projet ait le bon sens organisationnel et les compétences de facilitation pour arriver à la cause racine de ces problèmes. Pour vous assurer que vous donnez les bonnes priorités au bon moment, prenez la déclaration de portée initiale comme un point de départ, travaillez ensuite avec le sponsor pour l’affiner.
Acceptez que tout besoin change.
La culture de management de projet traditionnelle décrit le changement comme un mal nécessaire, comme les lois : si tout le monde faisait tout correctement, nous n’aurions pas besoin d’elles. Pour atténuer « le risque » lié au changement, nous mettons en place des processus de demande de changement intimidants et des pénalités financières. Mais que se passe-t-il si ce que vous avez développé pendant les deux dernières années n’est plus approprié pour votre marché ? Y-a-t-il un sens à continuer à faire payer votre sponsor pour ce qui est maintenant essentiellement un produit inutile ? Pas selon moi. Si nous acceptons que les exigences soient incomplètes et incorrectes, nous devons les modifier pour refléter la réalité. En effet, le corpus de connaissance en management de projet (PMBOK ®) énonce : “à cause du potentiel de changement, le plan de gestion de projet est itératif et passe par l’élaboration progressive tout au long du cycle de vie du projet.”
Simplifiez votre approche de gestion des modifications.
Les chefs de projet agiles embrassent explicitement la valeur de bien répondre aux changements et instituent une politique de projet en conséquence. Commencez par mettre en œuvre une structure de contrat qui supporte les changements autorisés plutôt que les pénalise. Au début de chaque itération, organisez une revue de haut niveau mais minutieuse des priorités de contenu. Si votre sponsor a des difficultés à déterminer les priorités, assistez-le en lui indiquant les différences. Une fois que les changements sont acceptés, redéfinissez les références de la valeur acquise au moins toutes les trois à quatre itérations pour qu’elles correspondent au dernier périmètre. Et pendant que vous y êtes, communiquez proactivement la dernière définition du contenu à toutes les parties prenantes.
Si vous trouvez systématiquement que la définition des exigences vous amènent des problèmes, faites quelque chose. C’est votre responsabilité de chef de projet que d’être adaptable aux besoins de votre sponsor. Arrêtez de prendre les exigences pour acquises et commencer à équiper votre sponsor pour qu’il fasse les bons choix de contenu.
DantotsuPM.com 
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 ?
J’aimeJ’aime
Ping : 5 façons d’éviter la dérive de contenu sur vos projets | DantotsuPM.com