L'ABC de la gestion de projet : M comme MOSCOW

Une hiérarchisation efficace des objectifs de projet grâce à la méthode MOSCOW

Qu’est-ce que la méthode MoSCoW ?

La méthode MoSCoW a été développée dans les années 1990 par Dai Clegg, consultant chez Oracle. Elle a vu le jour dans le cadre de la méthodologie de développement rapide d'applications (RAD) et visait à faciliter l'identification et la hiérarchisation des exigences au sein de cycles de développement rapides. Depuis son introduction, la méthode MoSCoW s'est imposée dans divers secteurs et est fréquemment utilisée dans des cadres de gestion de projet agiles tels que SCRUM et DSDM (Dynamic Systems Development Method), où elle aide les chefs de projet à se concentrer sur les tâches ou les objectifs les plus importants et à garantir une hiérarchisation claire. Cela se traduit par une utilisation plus efficace du temps et des ressources, puisque les exigences essentielles sont traitées en priorité. De plus, cette méthode facilite la communication avec les parties prenantes, car elle permet de distinguer clairement les exigences critiques de celles qui peuvent être reportées. Cela favorise des attentes réalistes et une meilleure planification.
Le nom "MoSCoW" est un acronyme qui décrit les quatre principales catégories d'exigences : Must-Have (M), Should-Have (S), Could-Have (C), et Won't-Have (W) - les "O" sont là pour créer un acronyme plus agréable et n'ont pas de signification.

Les catégories de la méthode MoSCoW

Must (M)

Les exigences « Must » sont indispensables et doivent être satisfaites pour que le projet soit couronné de succès. Elles ne sont pas négociables, car si ces points ne sont pas respectés, le projet est considéré comme un échec.

Exemples :

• Les fonctionnalités essentielles d’un produit, sans lesquelles son objectif principal ne serait pas atteint.
• Les fonctions de sécurité nécessaires au respect des dispositions légales.
• Exigences minimales en matière de performances ou de disponibilité d’un système.

Should-Have (S)

Les exigences souhaitées sont également importantes et devraient être mises en œuvre dans la mesure du possible. Leur absence nuit à la qualité ou à l’utilité du résultat du projet. Toutefois, même si elles ne sont pas satisfaites, le projet peut être considéré comme mené à bien, avec certaines restrictions. La priorité des exigences souhaitées vient juste après celle des exigences obligatoires. Cela signifie que, dans le pire des cas, ces exigences peuvent être reportées à un projet ultérieur si tout le temps et toutes les ressources sont nécessaires pour satisfaire aux exigences obligatoires.

Exemples :

• Fonctionnalités supplémentaires d'un produit qui renforcent son avantage concurrentiel, mais qui ne sont pas essentielles.
• Des interfaces utilisateur avancées d’un logiciel qui améliorent l’expérience utilisateur.
• Des améliorations en termes d’efficacité, qui ne sont toutefois pas absolument indispensables.

Could-Have (C)

Les exigences facultatives sont souhaitables car elles permettent, par exemple, d’accroître la valeur ajoutée du projet ou d’offrir davantage de confort. On s’efforce de répondre à ces exigences, mais elles ne sont pas essentielles à la réussite du projet et ne sont donc mises en œuvre que s’il reste du temps et des ressources disponibles après la satisfaction des exigences « indispensables » et « souhaitables ». En cas de conflits de ressources, les exigences facultatives ne sont pas mises en œuvre ou sont reportées à un projet ultérieur.
Ces exigences font souvent une grande différence en termes de satisfaction des parties prenantes. Il est donc important de les garder à l’esprit et de les répertorier. Elles peuvent ainsi être examinées de plus près si elles peuvent être mises en œuvre sans effort supplémentaire important.

Exemples :

• Des options ou paramètres supplémentaires, qui ne sont toutefois que rarement utilisés.
• Améliorations esthétiques de l'interface utilisateur d'un logiciel.
• Améliorations d’un logiciel visant à faciliter sa maintenance ou à accroître son évolutivité, mais qui ne sont pas nécessaires pour le moment.

Won't-Have (W)

Le "W" dans la méthode peut être interprété de différentes manières :

• « Won’t » concerne les exigences qui ne seront pas mises en œuvre.
• Les « Would » désignent les exigences qui seraient souhaitables, mais qui ne peuvent pas être mises en œuvre dans le cadre de ce projet.
• « Want » désigne les exigences qui sont souhaitées, mais qui ne seront pas mises en œuvre dans le cadre de ce projet, mais dans des projets ultérieurs.

Toutes ces interprétations ont en commun le fait que ces exigences ne seront certainement pas mises en œuvre dans le cycle de projet actuel. Elles sont toutefois mentionnées afin d'éviter tout malentendu et de pouvoir soit les mettre délibérément de côté, soit les prendre en considération pour de futurs projets. Cette catégorie permet ainsi de contrôler la portée du projet et de garder à l’esprit les exigences qui pourraient s’avérer importantes pour une collaboration ultérieure avec le donneur d’ordre.

Exemples :

• Des fonctionnalités qui, bien qu'intéressantes, ne sont pas pertinentes pour le moment.
• Des exigences qui pourraient ne prendre toute leur importance que dans des versions ultérieures du produit.
• Des améliorations qui ne peuvent être mises en œuvre en raison de contraintes de ressources ou d’un manque de temps.

Comment les catégories doivent-elles être réparties ?

La répartition des catégories au sein d’un projet doit être équilibrée et réaliste afin de garantir la réussite du projet, sans surcharger l’équipe ni négliger des aspects importants. En effet, si l'on ne prête pas attention à cette répartition, il peut arriver que toutes les exigences se retrouvent dans la catégorie « Must », ce qui rend alors toute hiérarchisation impossible. Une règle empirique stipule donc qu’au maximum 60 à 70 % de l’ensemble des exigences peuvent être considérées comme absolument critiques et donc classées dans la catégorie des exigences « Must ». Cela permet de s’assurer que l’accent est réellement mis sur les exigences essentielles du projet. 20 à 25 % des exigences sont importantes et contribuent de manière significative à la qualité et à l’utilité du projet ; elles sont donc classées dans la catégorie « Should ». 5 à 10 % supplémentaires des exigences peuvent entrer dans la catégorie « Could », tandis que seuls 0 à 5 % doivent être classés dans la dernière catégorie.

Avantages de la méthode MoSCoW

• Une hiérarchisation claire : en mettant d'abord l'accent sur les exigences « indispensables », puis sur les exigences « souhaitables », on s'assure que les objectifs du projet seront atteints. Parallèlement, cela permet d'éviter que l'équipe de projet ne soit détournée de son objectif par des exigences moins importantes.
• Utilisation efficace des ressources : le fait de traiter en priorité les exigences les plus importantes garantit que les objectifs essentiels du projet seront atteints dans tous les cas grâce aux ressources disponibles. Parallèlement, cette méthode permet de prendre en compte les exigences moins importantes (Could-Have) lorsque des ressources supplémentaires sont disponibles.
• Amélioration de la communication : cette classification claire facilite la communication avec les parties prenantes et les membres de l'équipe concernant les priorités et les objectifs du projet, contribuant ainsi à une prise de décision transparente. Parallèlement, cette classification permet aux parties prenantes de mieux comprendre ce à quoi elles peuvent s'attendre, quelles exigences sont réalistes et lesquelles doivent être mises en attente.
• Flexibilité et adaptabilité : cette méthode est flexible et peut être adaptée à l'évolution des exigences et du contexte, ce qui constitue un avantage particulier dans le cadre de projets agiles. Elle permet ainsi une approche itérative des objectifs du projet, les priorités pouvant être réexaminées et ajustées en permanence.

Défis et inconvénients de la méthode MoSCoW

Malgré ses nombreux avantages, il existe également quelques défis et inconvénients potentiels à prendre en compte lors de l'utilisation de la méthode MoSCoW :

• Subjectivité dans la hiérarchisation des priorités : les différentes parties prenantes peuvent avoir des points de vue divergents sur les exigences à considérer comme « indispensables » ou « souhaitables », ce qui peut être source de conflits. Parvenir à un consensus sur la hiérarchisation des priorités peut s’avérer chronophage, en particulier au sein d’équipes nombreuses ou hétérogènes.
• Surcharge de la catégorie « incontournables » : le risque existe que trop d'exigences soient classées dans la catégorie « incontournables », ce qui rend la hiérarchisation des priorités moins efficace. Parallèlement, un nombre excessif d'exigences « incontournables » peut submerger l'équipe et compromettre la réussite du projet.
• Manque de prise en compte des dépendances : La méthode ne prend pas automatiquement en compte les dépendances entre les exigences, ce qui peut entraîner des problèmes de planification, en particulier dans les projets complexes.
• Hiérarchisation statique : dans les projets agiles en particulier, les priorités peuvent évoluer et doivent être adaptées aux nouvelles informations. Dans de tels cas, la liste des priorités ne doit pas être figée, mais doit être réexaminée régulièrement, même si cela implique un surcroît de travail.

Conclusion

La méthode MoSCoW offre un moyen structuré et efficace de hiérarchiser les exigences dans le cadre de la gestion de projet. Grâce à cette catégorisation claire, une équipe de projet peut s’assurer que les objectifs les plus importants sont atteints en priorité, sans pour autant gaspiller de ressources ni perdre de vue l’essentiel. Malgré certains défis, tels que la subjectivité potentielle lors de la hiérarchisation et la nécessité d’ajustements réguliers, la méthode MoSCoW permet une planification de projet transparente et flexible, qui améliore à la fois l’efficacité et la communication au sein de l’équipe et avec les parties prenantes.

En savoir plus sur le logiciel de gestion de projet et de portefeuille myPARM :

Vous souhaitez découvrir myPARM lors d'une démonstration ? Alors prenez rendez-vous dès maintenant !