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.
