Organisation agile : oubliez le WBS… adoptez le PBS !

Depuis la nuit des temps, en gestion de projet, les hommes ont organisé le travail suivant les étapes de construction d’un produit.

C’est le WBS…

Dans une décomposition de type WBS (Work Breakdown Structure), le travail est décomposé suivant les activités à réaliser et axé sur les livrables. Cette décomposition rend le travail plus accessible et plus maîtrisable. Le Project Management Institute (PMI) définit la structure WBS en tant que « découpage hiérarchique en livrables spécifiques des travaux à exécuter ».

Dans le bâtiment, nous sommes dans ce type d’approche. Par exemple, les projets respectent en général les phases suivantes : le terrassement, le gros-œuvre, le second-œuvre, la coordination et le pilotage du chantier. Lors des appels d’offres, les entreprises sont consultées sur une ou plusieurs phases, et les équipes sont constituées en conséquence.

Prenons un autre exemple d’un produit dans le domaine de la relation client qui consiste à acquérir de nouveaux clients en allant jusqu’à la signature d’un contrat. Les conseillers de clientèle sont les principaux utilisateurs d’un tel produit.

Dans une approche informatique traditionnelle, dite séquentielle, en cascade ou en cycle en V, il faut recueillir le besoin des utilisateurs, concevoir le produit, développer le produit, tester le produit, déployer le produit et maintenir le produit.

Dans ce processus, les équipes créées sont spécialisées par type d’activité à mener : équipe d’analyse et de spécification, équipe de conception, équipe de développement, équipe de test, etc… et chaque membre d’une équipe possède un rôle et un ensemble de compétences communs à tous les membres de l’équipe.

Dans cette approche, la réalisation d’une activité n’est possible que si l’activité précédente est terminée. Il faut par conséquent définir le produit de manière détaillée et exhaustive au début du processus pour que les activités s’enchainent bien. Pour ce faire, les équipes travaillent de manière prédictive pour faire en sorte que tout soit prévu à l’avance. Les retours en arrière sont impossibles, voire difficiles à réaliser. Si un changement est demandé, il faut l’analyser et mesurer les impacts sur les activités en cours. Le changement doit être mis sous contrôle avec un processus robuste de gestion du changement.

La chaine de valeur est celle du processus de fabrication du produit. La valeur est produite au fur et à mesure de l’avancement des travaux, mais n’est délivrée aux utilisateurs qu’à la fin du processus.

Dans ce contexte, une fonctionnalité du produit qui doit être développée nécessite le travail de toutes les équipes. Le résultat final dépend énormément du passage de relais entre les activités.

Et le PBS alors…

Pour la construction d’un produit, il existe une autre manière d’organiser et de répartir le travail entre des équipes. Il s’agit de décomposer le produit en éléments fonctionnels et techniques, et d’affecter une équipe à la réalisation d’un élément du produit, c’est ce qu’on appelle le PBS (Product Breakdown Structure).

Dans l’exemple du produit de gestion de la relation client à destination des conseillers de clientèle, nous pourrions imaginer une équipe en charge de l’acquisition du client, une équipe en charge de la conversion avant-vente (menant à l’établissement d’un devis) et une équipe en charge de la conversion vente (menant à la signature du contrat).

Dans ce type d’organisation, les équipes sont définies non pas en suivant le cycle de fabrication du produit, mais en suivant :

  • soit une décomposition fonctionnelle et/ou technique du produit,
  • soit un parcours utilisateur (Customer Journey). Les équipes sont organisées suivant une chaine de valeur proche d’un processus métier de l’entreprise (Business Process).

Dans ce contexte, une fonctionnalité qui doit être développée nécessite le travail d’une seule équipe. Par exemple, la prise de rendez-vous pour l’établissement d’un devis sera développée par l’équipe en charge de la conversion avant-vente. Bien évidemment, dans certains cas, le développement de fonctionnalités pourra nécessiter une synchronisation et une gestion des dépendances entre plusieurs équipes. Par exemple, la gestion du référentiel des prospects / clients sera réalisée de manière transverse aux équipes.

Chaque équipe est autonome et dispose de l’ensemble des compétences utiles pour réaliser les fonctionnalités dans leur globalité. Chaque membre d’équipe possède un rôle et des compétences pluridisciplinaires l’amenant tantôt à faire de la conception, tantôt du développement, tantôt du test… etc.

Depuis quelques années, et pour répondre à un environnement changeant rapidement, des approches agiles sont apparues. Grâce à des cycles courts de fabrication, l’organisation du travail préconisée par ces approches permet de construire un produit de manière itérative et incrémentale, tout en favorisant l’adaptation au changement. Vous l’aurez compris, cette organisation agile s’inspire d’une décomposition de type PBS (Product Breakdown Structure), une organisation orientée produit.

Dans un second article, je vous présenterai d’autres différences importantes entre les deux approches…

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.