Gestion de projet – Vers les méthodes agiles
104
Quelle que soit la technique utilisée, une fois le product backlog ou le référentiel
d’exigences renseigné, il s’agit de déterminer les priorités.
Hiérarchiser les besoins
L’un des motifs d’échec de nombreux projets réside dans le fait que les fonctionnalités ne
sont pas développées par ordre de priorité ; en effet, dans une approche classique, le planning est établi en amont du projet avec la certitude que tous les besoins recensés seront
satisfaits. Partant du principe que le périmètre est défini et figé, l’équipe hiérarchise et
planifie ses activités, non pas en fonction de la valeur ajoutée pour le client, mais de
considérations techniques. Si elle prend du retard (ce qui est, hélas, souvent le cas !), elle
sera tentée de faire l’impasse sur certaines fonctionnalités, peut-être plus importantes
pour le client que celles déjà développées.
Si l’on admet que l’on a rarement assez de temps pour tout faire, que des changements
surviennent inévitablement au cours d’un projet, il faut, dès lors, qualifier et valoriser
les besoins pour les prioriser afin de faciliter les arbitrages sur les modifications de périmètre.
Comment valoriser les besoins ?
On dispose de plusieurs modèles, disponibles quelle que soit l’approche retenue ; il y a
cependant des questions incontournables à se poser :
• « Quel est le bénéfice financier à développer cette fonctionnalité ? »
• « Quel est le coût de développement ? De maintenance ? De formation des utilisateurs ? » ;
« Quel est le coût d’un changement ? »
• « L’implémentation de cette fonctionnalité nous permet-elle d’apprendre ou de développer de nouvelles compétences ? »
• « Cette fonctionnalité nous expose-t-elle à davantage de risques ? Ou, au contraire,
nous permet-elle de nous confronter au risque ? »
• « Cette fonctionnalité va-t-elle impacter les processus métier ? »
• « Cette fonctionnalité va-t-elle améliorer la productivité de mon personnel ? »
Les PBI de haut niveau sont, ici, des cas d’utilisation (colonne Niveau 1 de granularité), décomposés ensuite en items plus fins (colonne Niveau 2 de granularité). Ce niveau de raffinement
concerne les 20 % d’items qui seront prochainement traités.
Dans la colonne Priorité, les items sont hiérarchisés sur l’échelle de Moscow ; la colonne
Risque indique un niveau de complexité technique ; la colonne Valeur précise l’importance de
l’item pour le client et, enfin, la colonne Effort estime, pour chaque item, l’effort d’implémentation. Il ne s’agit pas d’une valeur absolue, mais d’un ordre de grandeur relatif. (Ces éléments
de qualification et de hiérarchisation sont détaillés ci-après dans le paragraphe « Hiérarchiser
les besoins ».)
GestProjInform Livre Page 104 Vendredi, 3. avril 2009 12:07 12
104
Quelle que soit la technique utilisée, une fois le product backlog ou le référentiel
d’exigences renseigné, il s’agit de déterminer les priorités.
Hiérarchiser les besoins
L’un des motifs d’échec de nombreux projets réside dans le fait que les fonctionnalités ne
sont pas développées par ordre de priorité ; en effet, dans une approche classique, le planning est établi en amont du projet avec la certitude que tous les besoins recensés seront
satisfaits. Partant du principe que le périmètre est défini et figé, l’équipe hiérarchise et
planifie ses activités, non pas en fonction de la valeur ajoutée pour le client, mais de
considérations techniques. Si elle prend du retard (ce qui est, hélas, souvent le cas !), elle
sera tentée de faire l’impasse sur certaines fonctionnalités, peut-être plus importantes
pour le client que celles déjà développées.
Si l’on admet que l’on a rarement assez de temps pour tout faire, que des changements
surviennent inévitablement au cours d’un projet, il faut, dès lors, qualifier et valoriser
les besoins pour les prioriser afin de faciliter les arbitrages sur les modifications de périmètre.
Comment valoriser les besoins ?
On dispose de plusieurs modèles, disponibles quelle que soit l’approche retenue ; il y a
cependant des questions incontournables à se poser :
• « Quel est le bénéfice financier à développer cette fonctionnalité ? »
• « Quel est le coût de développement ? De maintenance ? De formation des utilisateurs ? » ;
« Quel est le coût d’un changement ? »
• « L’implémentation de cette fonctionnalité nous permet-elle d’apprendre ou de développer de nouvelles compétences ? »
• « Cette fonctionnalité nous expose-t-elle à davantage de risques ? Ou, au contraire,
nous permet-elle de nous confronter au risque ? »
• « Cette fonctionnalité va-t-elle impacter les processus métier ? »
• « Cette fonctionnalité va-t-elle améliorer la productivité de mon personnel ? »
Les PBI de haut niveau sont, ici, des cas d’utilisation (colonne Niveau 1 de granularité), décomposés ensuite en items plus fins (colonne Niveau 2 de granularité). Ce niveau de raffinement
concerne les 20 % d’items qui seront prochainement traités.
Dans la colonne Priorité, les items sont hiérarchisés sur l’échelle de Moscow ; la colonne
Risque indique un niveau de complexité technique ; la colonne Valeur précise l’importance de
l’item pour le client et, enfin, la colonne Effort estime, pour chaque item, l’effort d’implémentation. Il ne s’agit pas d’une valeur absolue, mais d’un ordre de grandeur relatif. (Ces éléments
de qualification et de hiérarchisation sont détaillés ci-après dans le paragraphe « Hiérarchiser
les besoins ».)
GestProjInform Livre Page 104 Vendredi, 3. avril 2009 12:07 12