La méthode
La méthode MoSCoW a été inventée par Dai Clegg, qui en parle pour la première fois, dans un ouvrage qu’il a co-écrit avec Richard Barker : Case Method Fast Track: A Rad Approach. La méthode vise à classer les exigences d’un projet, en fonction de leur importance / criticité.
Cette méthode s’est ensuite développée dans le cadre de la démarche de projet agile Dynamic Systems Development Method (DSDM)
MoSCoW est un acronyme pour
- M - Must have this. Ce qui doit être fait
- S - Should have this if at all possible. Ce qui devrait être fait dans la mesure du possible.
- C - Could have this if it does not affect anything else. Ce qui pourrait être fait dans la mesure où cela n’a pas d’impact sur les autres tà¢ches.
- W - Won’t have this time but would like in the future. Ce qui est exclus dans l’immédiat, mais qui doit être conservé pour un traitement ou une intégration ultérieure.
Les « o » ont un rôle cosmétique, et servent à rendre le mot phonétiquement prononçable.
Attention aux descriptions simplifiées du type Must / Should / Could / Won’t. Cette simplification respecte l’esprit et la hiérarchisation, mais les définitions complètes ont leur importance, notamment quand il s’agit d’arbitrer entre Must / Should, et Should / Could.
| Acronyme | Priorité | Description |
|---|---|---|
| M | 1 | Nous plaçons dans cette catégorie, des éléments critiques, ou vitaux. Sans ces éléments, le projet sera considéré comme en échec. Les éléments classés dans cette catégorie ne sont pas négociables. |
| S | 2 | Ces éléments sont importants, et ils contribuent à la réalisation des objectifs du projet, mais ils sont jugés moins prioritaires que les éléments de la précédente catégorie |
| C | 3 | L’absence de ces éléments ne remet pas en cause la réussite du projet. Ces éléments ne sont pas prioritaires, et peuvent donc être retirés si nous n’avons ni les ressources, ni le temps de les construire. On parle d’éléments de confort |
| W | 4 | Ces éléments peuvent être abandonnés sans aucun impact au niveau du projet. Il peut être bon de les conserver pour un développement ultérieur. |
Les cas d’usage
La description que je viens de faire de la méthode faisait référence à des livrables dans le cadre d’un projet. Mais la méthode MoSCoW s’applique d’une manière générale à la priorisation des besoins ou des exigences d’un produit, des attendus, …
Elle peut donc être utilisée
- Par le chef de projet, pour définir et/ou prioriser les livrables,
- Par le chef de projet, en mode Agile, lors de la définition du contenu des prochains Sprints,
- Par un maître d’oeuvre et un maître d’ouvrage, pour s’aligner sur les exigences des tâches à réaliser.
Dans le cadre d’un appel d’offre, la méthode MoSCoW peut servir à
- Définir plus précisément un cahier des charges, en aidant les utilisateurs à exprimer leur demande,
- Définir les poids des critères de comparaison des propositions des fournisseurs : un critères Must have aura un poids plus important qu’un critère classé Could.
Cette méthode peut également être utilisée comme aide à la gestion de temps. Dans un précédent article, j’ai présenté la matrice d’Eisenhower. Cette matrice comporte 4 zones, que l’on peut faire correspondre aux quatre catégories de la méthode MoSCoW.
Mais cette méthode MoSCoW peut-être plus «subtile» que la matrice d’Eisenhower.
Comme appliquer la méthode
1. Constituer le groupe de travail L’application de la méthode doit se faire collectivement. Cela peut prendre la forme d’un groupe de travail. Les participants doivent être représentatifs des parties prenantes du projet. En fonction de l’objectif visé, ce groupe devra intégrer des profiles plutôt techniques, des décideurs, ou les deux.
2. Lister les éléments à prioriser L’objectif est de construire la liste la plus détaillées possibles, des activités ou des critères à prioriser. A cette étape, il est important d’être exhaustif.
3. Prioriser / classer les éléments Cette étape consiste donc à placer chacune des activités listées pendant l’étape précédente. Cette étape s’articule autour de sessions de brainstorming / discussions. Différents outils peuvent être utilisés
- Une feuille Excel vidéoprojetée,
- Des Post-It,
- Fes applications comme Mural, Klaxoon,
Les parties prenantes peuvent avoir des avis, ou des priorités différentes. Les discussions sont normales à ce stade.
La dérive souvent rencontrée, est de classer une trop grande proportion d’activités dans les catégories « Must have » et « Should have ». Dans ce cas, le rôle de l’animateur des sessions, est de challenger régulièrement ce classement, soit en rappelant la définition des différentes catégories, soit en redonnant la définition de l’activité à classer. Mais il n’y a pas de règles de proportions entre les différentes catégories.
4. Valider la classification
A la fin de l’étape précédente, nous avons une liste d’activités, ou de critères, classées en fonction de leur priorité. Ce classement a été réalisé avec l’aide des parties prenantes, selon leurs critères.
L’étape de validation consiste à confronter cette classification, aux contraintes du projet : le temps de réalisation, les ressources disponibles, et le budget.
Même avec une bonne modération, la répartition des activités / critères à la fin de l’étape 3, reste naturellement et assez logiquement déséquilibrée. Les demandeurs / utilisateurs ont des attentes (c’est bien pour cela que le projet existe), et il est difficile pour eux d’accepter des compromis. Mais en mettant en face cette classification, et les contraintes du projet, on s’aperçoit que l’on ne peut pas tout réaliser (en tout cas, pas en même temps). Cette remarque est valable, autant au niveau d’un projet, comme d’un sprint.
L’étape 4 consiste donc à réajuster la classification en fonction des contraintes du projet. C’est parfois un dur retour à la réalité. On voit ici l’importance de terminer l’étape 3 avec une classification qui ne soit pas trop déséquilibrées.
La tendance naturelle est de commencer par éliminer des éléments qui sont classés en Should have. Ce n’est pas forcément la bonne façon de faire. Il est plutôt recommandé de démarrer par la catégorie Must, puis de descendre.
Avantages / Inconvénients
La méthode apporte plusieurs avantages
- Elle permet une compréhension commune des tâches, activités, critères à classer, et des objectifs du projet finalement.
- Elle permet également une meilleure compréhension des attendus de chaque partie prenante : en écoutant les autres défendre leur priorité, chacun comprend mieux ce dont les autres ont besoins,
- Elle apporte une certaine flexibilité dans les décisions : une fois les 4 étapes passées, chacun à une bonne vision des priorités, et du pourquoi. Si un changement doit s’effectuer, les décisions sont plus faciles à prendre.
- Une fois terminée, le résultat constitue une source d’information extrêmement précieuse pour le chef de projet, pour la construction de son plan, et pour la planification des ressources.
Conclusion
MoSCow est une méthode relativement simple, mais très efficace pour définir les priorités d’un projet. Mais elle ne se restreint pas à ce domaine. Je l’ai, par exemple, utilisé comme aide à la définition d’un cahier des charges : le nombre et la diversité des parties prenantes étant assez larges, il était difficile de définir une description claire des besoins, et les premières tentatives ont conduit à la demande d’un mouton à 5 pattes. Avec la méthode MoSCoW, nous avons d’abord listé les fonctionnalités voulues, que nous avons ensuite classé. La méthode nous a finalement permis de converger vers un cahier des charges clair, car plus simple, en seulement deux sessions de travail.
Références
- Méthode MoSCoW ,disponible sous licence Wikipedia en français
- MoSCoW Prioritisation
Commentaires