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…

La vision du produit, c’est quoi ?

Toute organisation doit être guidée par une vision. Pour réussir, une des choses indispensables est de savoir où l’on veut aller, c’est la cible à atteindre. La vision est relative à la raison d’être et elle fixe le cap pour l’ensemble des équipes. Cela s’applique aussi à une transformation, à un projet ou à un produit.

La vision du produit est un des objectifs majeurs recherché dans le cadre d’un projet ou pour une équipe, et elle représente souvent un ou plusieurs objectifs des parties prenantes. La vision est l’état futur attendu.

La vision du produit permet d’engager l’équipe vers l’atteinte d’un résultat et également d’aligner l’équipe sur une compréhension commune et partagée des objectifs et de donner du sens. La vision va éliminer par conséquent certaines des ambiguïtés pouvant être à l’origine de sérieux problèmes à venir. Elle guide l’effort nécessaire à la réalisation du produit, tout en laissant de la place à la créativité.

Que se passe-t-il si la vision du produit n’est pas définie ?

Dans certains cas, il peut arriver que l’organisation ou l’équipe se lance dans l’étude et la réalisation d’un produit sans que sa vision soit définie. Que peut-il se passer dans ce cas ?

Premièrement, la cible n’étant pas définie, l’organisation ne sait pas où elle va. L’objectif global n’étant pas fixé, les équipes vont partir dans des directions différentes sans savoir si les choix seront les bons et sans pouvoir mesurer l’atteinte de l’objectif, ni même le succès du projet. Il y a un risque de dilution de l’effort et de perte de sens sur le long terme.

Dans d’autres cas, si la vision n’est pas communiquée ni partagée entre les équipes, la situation peut devenir conflictuelle. Certaines équipes essayeront d’imposer leur propre vision sans accord préalable et chaque équipe aura sa propre stratégie.

En savoir plus sur la vision du produit : https://www.editions-eni.fr/livre/gestion-de-projet-agile-de-la-definition-du-besoin-a-la-livraison-d-un-produit-de-qualite-9782409033391

Publication d’un nouvel ouvrage sur l’agilité

Je suis très heureux de vous annoncer la sortie officielle de mon nouveau livre aux Editions ENI sur la gestion de projet agile, et plus précisément sur l’expression des besoins dans un contexte agile.

Le sous-titre « De la définition du besoin à la livraison d’un produit de qualité » résume bien le contenu de cet ouvrage. J’espère qu’il apportera toutes les informations utiles aux personnes impliquées dans un projet agile. Il s’adresse particulièrement aux responsables de produit et aux analystes qui sont au contact avec les utilisateurs et en charge de la définition d’un produit…

Envie d’en savoir plus… Consultez le sommaire et des extraits dès maintenant sur https://lnkd.in/ebPauHmx

J’ai hâte de lire vos premiers retours !