Lorsqu'il s'agit de gestion de projet, comprendre la notion de valeur est essentielle pour faire les bons choix entre des méthodes telles que le Cycle en V et l'approche agile. Le Cycle en V, qui suit une approche séquentielle, a longtemps été privilégié dans de nombreux secteurs, mais l'agilité gagne en popularité avec ses méthodes itératives et collaboratives.
Selon une étude récente [1], les projets agiles ont montré une augmentation de 28% de la réussite par rapport aux approches traditionnelles.
Cependant, il est important de comprendre les avantages et les limitations de chaque méthode pour choisir celle qui convient le mieux à votre projet. Dans cet article, nous explorerons en détail la notion de valeur et les considérations clés pour prendre une décision éclairée entre le Cycle en V et l'approche agile.
La notion de valeur dans la gestion de projet est un aspect essentiel qui permet de mesurer l'utilité, la satisfaction et les bénéfices qu'un projet apporte à ses parties prenantes, qu'il s'agisse de l'organisation, des clients ou des utilisateurs.
La valeur d'un projet peut être définie comme les avantages et les résultats positifs qu'il génère. Par exemple, dans le développement d'une application mobile pour enfants, la valeur pour le client serait la capacité de divertissement et d'apprentissage offerte par l'application, tandis que la valeur pour l'utilisateur serait la facilité d'utilisation et l'expérience agréable qu'il en retire.
Pour garantir la création de valeur, il est essentiel de comprendre les besoins et les attentes du client et de l'utilisateur. En intégrant ces éléments dès le début du projet, il est possible de concevoir et de développer des fonctionnalités qui répondent directement à leurs demandes.
Il est également crucial d'évaluer régulièrement la valeur générée par le projet tout au long de son déroulement. Cela permet d'apporter des ajustements et des améliorations en fonction des retours du client et de l'utilisateur, afin de maximiser la satisfaction et les bénéfices obtenus.
L'analyse de la valeur est un outil qui peut être utilisé dans la gestion de projet pour optimiser l'efficacité et l'efficience. Cette méthode consiste à identifier les fonctions clés du projet, à évaluer les coûts associés à ces fonctions, et à explorer des alternatives pour maximiser le rapport coût-efficacité. Par exemple, dans le développement d’une application mobile, l'analyse de la valeur pourrait permettre de déterminer les fonctionnalités qui apportent le plus de valeur par rapport à leur coût de développement.
La Work Breakdown Structure (WBS), ou Structure de Découpage en Paquets en français, est un outil essentiel en gestion de projet. Il permet de décomposer le travail nécessaire pour mener à bien un projet en plusieurs composants plus petits et plus gérables. La WBS offre une vue hiérarchique du périmètre d'un projet, traduisant les objectifs et les stratégies globales en objectifs spécifiques, en flux de travail, en phases de projet et en plans d'action.
Descartes nous dit d’ailleurs bien [8] à propos de l’un de ses 4 principes:
Le second, de diviser chacune des difficultés que j’examinerais, en autant de parcelles qu’il se pourrait et qu’il serait requis pour mieux les résoudre »
Descartes, les règles de la méthode.
La décomposition ne date pas donc d’hier, et est le mot clé central de la WBS. Elle consiste à diviser le projet en tâches plus petites et plus faciles à gérer. Cela facilite la planification, l'affectation des ressources, le suivi et le contrôle du projet.
Par exemple, en reprenant l'exemple du développement d'une application mobile pour enfants, la WBS permettrait de décomposer le projet en tâches telles que la conception des interfaces utilisateur, la programmation des fonctionnalités, les tests de qualité, etc. Chaque tâche peut ensuite être attribuée à un membre de l'équipe en fonction de ses compétences et de son expertise.
La WBS trouve son origine dans la gestion de projet traditionnelle, également connue sous les noms de "cycle en V" ou "waterfall". Ces approches de gestion de projet mettent l'accent sur une planification détaillée et une séquence linéaire des activités. La WBS est utilisée pour organiser les livrables et les tâches dans ces méthodologies, permettant ainsi de visualiser les dépendances et les relations entre les différentes parties du projet. Par exemple, dans le développement de l'application mobile, la WBS pourrait montrer comment les interfaces utilisateur doivent être conçues avant que la programmation puisse commencer.
Plusieurs approches sont possibles pour la décomposition en privilégiant :
Les Tâches : permet de décomposer tout le travail qui est à faire
Les Phases : permet de montrer séquentiellement ce qu’il y à faire,
Les Livrables : permet de focaliser sur la valeur
L’organisation selon les sites R&D …
Le backlog joue un rôle essentiel dans la gestion de projet agile. Pour comprendre son importance, commençons par définir ce qu'est un backlog.
Dans le contexte de la méthodologie Scrum, le backlog produit, également appelé "Product Backlog", est une liste ordonnée de toutes les fonctionnalités, les améliorations et les tâches à développer dans un produit[2][4]. Il permet de garder une vue d'ensemble des éléments à réaliser et de prioriser les travaux.
Le backlog trouve son origine dans l'approche agile, qui vise à favoriser la flexibilité et l'adaptabilité dans la gestion de projet. Contrairement aux méthodes traditionnelles, telles que le "cycle en V" ou "waterfall" mentionnées précédemment, l'approche agile reconnaît l'incertitude et l'ambiguïté inhérentes aux projets. Plutôt que de chercher à tout planifier à l'avance, l'agilité encourage une approche itérative et collaborative, où les exigences et les priorités peuvent évoluer au fur et à mesure de la réalisation du projet.
Dans le contexte de la gestion de projet agile, le backlog produit est étroitement lié à la notion de valeur. La priorisation est un aspect clé de la gestion du backlog, car elle permet de déterminer quelles fonctionnalités et quelles tâches doivent être réalisées en premier, en se basant sur leur valeur pour le client ou l'utilisateur final. La valeur peut être définie en termes de bénéfices pour l'utilisateur, de retour sur investissement ou d'impact commercial. La priorisation aide à maximiser la valeur livrée en concentrant les efforts sur les éléments les plus importants[3].
Le backlog est caractérisé par l'acronyme "DEEP" qui signifie :
- Detailed Appropriately (détaillé de manière appropriée) : Les éléments du backlog doivent être suffisamment détaillés pour être compris par l'équipe de développement.
- Estimated (estimé) : Chaque élément du backlog doit avoir une estimation de l'effort nécessaire pour le réaliser.
- Emergent (émergent) : Le backlog est un outil évolutif qui peut être ajusté et modifié au fil du temps.
- Prioritized (priorisé) :
Les éléments du backlog doivent être classés par ordre de priorité en fonction de la valeur qu'ils apportent[2][3].
Les points communs et les différences entre le Work Breakdown Structure (WBS) et le backlog sont nombreux, tous deux adoptent une approche centrée sur la planification.
1. Gestion des changements : Le WBS et le backlog sont tous deux sujets à des changements au cours du projet et toutes les parties prenantes peuvent soumettre des demandes de changements. Ils doivent être capables de gérer efficacement ces changements, que ce soit en raison de nouvelles exigences, de l'évolution des priorités ou de la découverte de problèmes pendant la réalisation du projet. A noter que la WBS peut être soumise à une gestion stricte des changements de type CCB (Change Control Board) où les changements significatifs sont soumis à l’approbation des contributeurs les plus importants et influents sur le projet. En revanche, le backlog n’est pas soumis au CCB et relève de l’autorité ultime du Product Owner[5].
2. Niveaux hiérarchiques : Le WBS et le backlog utilisent tous deux une approche hiérarchique pour organiser les éléments du projet. Le WBS décompose le projet en tâches de plus en plus détaillées, créant ainsi une structure en arborescence. Le backlog, quant à lui, hiérarchise les fonctionnalités en fonction de leur importance ou de leur priorité au moyen de fonctionnalités, décomposées en user stories, elles-mêmes décomposées en tâches. Cette approche hiérarchique permet une meilleure compréhension et gestion des différentes composantes du projet.
3. Représentation graphique :
La WBS peut être représentée sous la forme d'un diagramme arborescent qui illustre la structure du projet, montrant ainsi les différentes tâches et leur relation hiérarchique. Le backlog peut être représenté sous la forme d'une liste ordonnée des fonctionnalités ou des tâches à réaliser. Les représentations graphiques varient, mais l'objectif est de fournir une vue claire et organisée des éléments du projet.
Les différences entre le Work Breakdown Structure (WBS) et le backlog sont nombreux, tous deux adoptent une approche centrée sur la planification.
1. Décomposition des tâches : Le WBS se concentre sur la décomposition détaillée du projet en sous-tâches, créant une vue complète, la plus exhaustive possible et détaillée de toutes les activités nécessaires à sa réalisation. Le backlog, en revanche, se concentre sur la décomposition des fonctionnalités clients en éléments plus petits et gérables.
2. Priorisation : Le WBS ne met pas l'accent sur la priorisation des tâches ou des éléments. Il se concentre plutôt sur la structure et la décomposition du projet. Le backlog, en revanche, est principalement axé sur la priorisation des fonctionnalités ou des tâches en fonction de leur importance ou de leur valeur.
Enfin, il est important de comprendre que tant la WBS que le backlog visent à maximiser la valeur du projet. Le WBS permet de mieux comprendre les tâches nécessaires à la réalisation des objectifs du projet, tandis que le backlog permet de prioriser les fonctionnalités ou les tâches en fonction de leur valeur[6].
Voici un tableau récapitulatif pour comparer le WBS et le backlog :
Critères | WBS | Backlog |
---|---|---|
Gestion des changements | Doit pouvoir être modifié avec traçabilité | Doit pouvoir être modifié, pas de traçabilité |
Représentation graphique | Diagramme arborescent | Liste ordonnée |
Décomposition des tâches | Détaillée | Pas forcément, les tâches apparaissent au sprint planning |
Priorisation | Non priorisé | Basée sur la valeur |
Pour choisir entre le WBS (Work Breakdown Structure) et le backlog, plusieurs critères peuvent être pris en compte :
1. Culture agile : Si votre équipe adopte une approche agile dans la gestion de projet, le backlog est souvent privilégié. L'agilité favorise la flexibilité, l'adaptabilité et la réactivité face aux changements, ce qui est plus compatible avec un backlog qui permet une gestion itérative et une priorisation dynamique des fonctionnalités.
2. Ambiguïté : Si votre projet présente un grand niveau d'ambiguïté ou une incertitude élevée quant au résultat final, le backlog peut être plus approprié. Sa nature flexible permet d'ajuster les fonctionnalités au fur et à mesure que le projet progresse, offrant ainsi une meilleure réponse aux besoins changeants[7].
3. Type de produits ou de services : Le choix entre la WBS et le backlog peut également dépendre du type de produits ou de services que vous développez. Dans l'industrie manufacturière, par exemple, où la gestion de projet est souvent axée sur des projets prédictifs, un WBS structuré peut être plus adapté pour décomposer les tâches et suivre l'avancement. En revanche, dans l'industrie du logiciel où l'agilité est couramment utilisée, le backlog peut offrir une approche plus flexible et itérative pour la gestion des fonctionnalités.
Il est important de noter que la décision entre le WBS et le backlog dépendra de la nature spécifique de votre projet, de votre équipe et de votre contexte. Il est recommandé d'évaluer ces critères, et d'impliquer les membres de votre équipe pour prendre une décision éclairée.
La compréhension de la valeur dans la gestion de projet et le choix entre le WBS et le backlog sont des éléments clés pour mener à bien un projet et maximiser son impact. En intégrant ces concepts dans votre approche de gestion de projet, vous pourrez prendre des décisions éclairées et créer des projets qui apportent une réelle valeur ajoutée à vos parties prenantes.
[1] Agile vs. Waterfall. https://www.exactestimating.com/agile-vs-waterfall-project-management/
[2] Rôles Scrum dans Agile. https://www.atlassian.com/fr/agile/scrum/roles
[3] Comment développer un backlog produit scrum exceptionnel. https://www.lucidchart.com/blog/fr/comment-developper-un-backlog-produit-dans-agile
[4] Qu'est-ce Qu'un Backlog Produit ? Comprendre Son Rôle Dans La Gestion De Produits - Blog Du Scrum Master. https://scrum-master.org/gestion-du-backlog-produit-developpement-agile/
[5] Le rôle du Product Owner en gestion de projet agile : une nouvelle approche pour le chef de projet https://www.mbcs.fr/le-role-du-product-owner-en-gestion-de-projet-agile
[6] Work Breakdown Structure (WBS): Overview, Uses, Software. https://www.coursera.org/articles/work-breakdown-structure
[7] Alberto Dominguez. WBS vs. Backlog - When, how and why? - Alberto Dominguez. https://www.albertodominguez.co/en/wbs-vs-backlog/
[8]La régle de la Méthode, Descartes.
https://www.philolog.fr/les-regles-de-la-methode-descartes/
Un projet agile favorise des itérations flexibles et une collaboration continue avec les parties prenantes, tandis qu'un projet classique suit généralement une planification linéaire et rigide avec des phases distinctes.
La méthode en V suit un modèle séquentiel avec des phases distinctes, tandis que la méthode agile privilégie des itérations continues et l'adaptation aux changements.
Le management traditionnel est plus directif et planifié, tandis que le management agile encourage l'autonomie et la réactivité des équipes.
La méthode de gestion de projet dite classique est appelée "cascade" ou "Waterfall".
Scrum est une méthodologie spécifique qui fait partie de l'approche agile plus large, en se concentrant sur des itérations courtes et des équipes auto-organisées.
MBCS est un organisme de formation à taille humaine certifié QUALIOPI. Nous sommes spécialisés dans la gestion de projet (agile, hybride ou traditionnel) et avons accompagné plus de 250 stagiaires.
Fort de ses 25 ans d’expérience en gestion de projet, et Professeur en IAE et Grande Ecole auprès de centaines d'étudiants, Martial Bellec (seul coach formateur agile certifié SAFe SPC, PMP, PgMP et PMI-ACP en France) a créé MBCS il y a 2 ans dans le but de rendre la formation en gestion de projet accessible à tous. Nos 5 formateurs sont extrêmement expérimentés et capables d'illustrer la théorie, à tout moment, au moyen des centaines de projets qu'ils ont dirigé , dans les secteurs du digital, de l'industrie (aéronautique, télécoms, ...) ou de la banque.
De par notre expertise et notre structure, nous serons donc à mêmes de vous accompagner tout au long de votre carrière au plus près, en vous accueillant parmi nos stagiaires !
PMP
Préparation à la certification PMP®
Intermédiaire - Hybride
La certification la plus répandue dans le monde pour les chefs de projet expérimentés.
PMFUN
Fondamentaux en management de projet
Débutant - Traditionnel
3 jours pour découvrir la gestion de projet.
CDA
Comprendre la démarche agile
Débutant - Agile
LA formation pour découvrir simplement les notions agiles les plus fondamentales.
CAPM
Préparation à la certification CAPM®
Débutant - Hybride
La certification idéale pour bien démarrer avec la gestion de projet.
Autres posts: