A défaut de bénéfices clairs au niveau du projet, le coût du retard à ne pas avoir le livrable du projet peut permettre une priorisation.
Cost of Delay. Can It Be Quantified?
https://www.leadingagile.com/2017/06/cost-delay-project-management-2 par Marty Bradley
La plupart des organisations ont du mal à déterminer combien de revenu chaque projet va créer. Donc, elles ont besoin d’un autre critère pour prioriser leurs arriérés de développement. C’est la raison pour laquelle je vois de plus en plus de sociétés se tourner vers le Coût de Retard (Cost of Delay – CoD). Souvent, j’entends les gens parler du CoD comme si c’est une formule mathématique avec laquelle ils peuvent calculer des revenus tangibles, obtenir un résultat et que chacun va pouvoir facilement comprendre. Selon mon expérience, ce n’est pas le cas.
La réalité est que, dans la plupart des cas, le coût du retard (CoD) est constitué de plus que seulement des Euros ou Dollars. Le coût est d’habitude quelque chose de plus ambigu, comme Jim Hayden l’a indiqué sur son blog et c’est là que les gens s’embrouillent. Ils ont des difficultés à évaluer la valeur des fonctionnalités qui n’ont pas un montant d’argent précis qui leur est alloué.
Les éléments du Coût de Retard (Cost of Delay – CoD)
Comment une organisation détermine-t-elle le coût de retarder un projet, ou le coût de ne pas faire le projet du tout, quand le résultat financier est indéterminé ? Et même s’ils peuvent déterminer ce résultat financier, comment choisissent-ils au final que faire ensuite ?
Dans Principles of Product Development Flow, Don Reinertsen affirme que le CoD peut être défini avec les trois paramètres suivants :
- Valeur business pour l’utilisateur
- Criticité temporelle
- Valeur de la réduction de risque et/ou de la création d’opportunité
Il définit que la somme des 3 paramètres donne le Coût de Retard (Cost of Delay – CoD).
Le travail pondéré le plus court en premier
Dans son livre, Reinertsen présente aussi un modèle qui permettra à votre organisation de peser l’importance de chaque nouveau projet et de prendre une décision informée sur quelle est la chose suivante la plus importante.
Il appelle ce modèle : le Travail Pondéré le Plus court en Premier (ou Weighted Shortest Job First – WSJF). Essentiellement, WSJF = CoD divisé par la taille du travail.
Voici un exemple de table que vous pouvez utiliser pour déterminer vos valeurs de WSJF par projet ou fonctionnalité. Vous évaluerez ainsi chaque élément par rapport aux autres de la liste en utilisant les trois paramètres qui composent le CoD.
|
1 |
2 |
3 |
4 |
5 |
|
|
Fonctionnalité (ou projet) |
Valeur Business pour l’Utilisateur |
Criticité Temporelle |
Valeur de réduction de risque ou création d’opportunité |
Taille du travail à faire |
WSJF (2+3+4)/5 |
Détermination de la valeur
Maintenant que nous avons une formule de base et le moyen de la visualiser :
- Comment déterminez-vous la valeur appropriée de chaque paramètre ?
- Quelle est l’unité de mesure ?
J’aime le faire de la même manière que pour les histoires d’utilisateur (User Stories). Je réunis les propriétaires de produit et quelques responsables techniques principaux autour d’une table et nous commencerons à assigner des points.
J’aime utiliser une Échelle de Fibonacci, en la limitant à 20 et prendre une colonne à la fois. Nous examinons la fonctionnalité et allouons une valeur business, puis une valeur pour la Criticité temporelle et enfin une valeur pour Risque et Opportunité.
Une fois que nous avons déterminé ces valeurs, nous pouvons calculer un total de point pour le CoD, le diviser par la taille du travail à réaliser et obtenir notre valeur de WSJF. Avec celle-ci, nous avons réussi à déterminer la prochaine chose la plus importante à faire.
Très souvent, quand je présente ce modèle à mes clients, ils résistent et me disent qu’il leur semble donner des décisions aléatoires. Cependant, gardons à l’esprit que l’importance de chaque paramètre peut être subjective. La valeur réelle du CoD peut ne pas être mathématiquement quantifiable, et c’est OK.
Compréhension partagée
CoD et WSJF sont seulement des outils pour permettre de faire la priorisation. 
Il n’importe pas vraiment que nous allouions des valeurs avec notre connaissance collective, ce qui importe est la comparaison relative d’une chose avec une autre. L’application de cette technique permet au processus décisionnel d’être influencé par l’équipe. Elle ouvre une conversation sur pourquoi une fonctionnalité est valorisé avec des 20 et une autre avec des 5.
Ce qui importe vraiment est que chacun dans l’équipe soit d’accord sur ce qui est dans la liste et que tous aient une compréhension des valeurs attribuées. Mon expérience est que quand vous avez une équipe de personnes qui sont toutes de l’industrie et focalisées sur le meilleur pour la société, la décision prise sera plus que probablement la décision la meilleure pour l’organisation.
Ce modèle est seulement une façon de réaliser la priorisation, mais il y en a d’autres.
Parfois, particulièrement dans les startups, je vois les gens utiliser des rapports de Gartner ou considérer leur part de marché pour prendre des décisions business. Souvent, ils agissent par instinct et utilisent des chiffres confus pour justifier les investissements.
Le modèle CoD/WSJF est une excellente façon de purger et prioriser un arriéré de produit en l’absence de valeur financière.
Aussi, si vous avez des difficultés à mesurer la valeur, je reprends les paroles de Reinertsen:
“…si vous allez évaluer quantitativement une chose, évaluez également quantitativement le coût de retard à ne pas l’avoir.”
DantotsuPM.com 