Les informaticiens connaissent bien cette manière de travailler : avant de faire, on prépare.
Un développeur code-t-il des fonctionnalités de but en blanc, sans être passé par une phase d’analyse, par la production de modèles (UML par exemple), de tests unitaires (TDD, ATDD, BDD…), etc. ? Assurément non (ou il faut peut-être revoir votre staff…).
Il en va de même pour le chef de projet (CP) : avant de travailler, nous allons préparer le terrain.
Le chemin est long du projet à la chose… Molière
Diviser pour mieux régner
Le work breakdown structure, ou WBS (que l’on traduit parfois en français par « OTP » : organigramme des tâches du projet), est une technique simple qui s’inspire d’une manière de faire bien connue de la vie courante : plutôt que de s’attaquer à une tâche très compliquée, il est toujours possible (et généralement plus pertinent) de la découper en plusieurs tâches plus simples.
Définition du WBS
Le PMBOK définit le WBS comme un « découpage hiérarchique en livrables spécifiques des travaux à exécuter » (« a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and created the required deliverables »).
Le terme hiérarchique est ici intéressant : il s’agit concrètement d’un arbre, dont les ramifications sont les différentes tâches à exécuter pour venir à bout d’un projet.
Il s’agit donc en quelque sorte de l’architecture du projet. On commence par identifier les tâches les plus générales, puis on découpe ces tâches en tâches plus restreintes, et on répète ce processus de manière récursive.
Structure d'un WBS/ODT
Ne confondez pas WBS et PBS. Le PBS (pour product breakdown structure) représente une décomposition du produit (par exemple le logiciel, la maison, ou n’importe quoi d’autre) en composants de granularité plus fine (exemples pour la maison : les fondations, les murs, le circuit électrique, la toiture, etc.). C’est aussi un arbre.
À retenir — Le PBS fournit une liste exhaustive et hiérarchisée des livrables du projet, alors que le WBS fournit une liste exhaustive et hiérarchisée des tâches permettant de produire ces livrables.
En route pour un exemple…
Pour illustrer cette notion de WBS, imaginons que notre projet soit de… courir un marathon ! Et non, les chefs de projet n’ont pas le monopole de la folie.
Ce projet implique quelques sacrifices, une bonne dose de volonté… et surtout de l’organisation.
En l’occurrence, il faudra veiller à se préparer sportivement (s’entraîner dur…), mais aussi à s’équiper (on ne court par 42km avec des baskets de tennis), se préparer mentalement, mais aussi régler quelques détails administratifs et s’assurer que le moteur est en bon état de fonctionnement.
Exercice – Essayez d’écrire le WBS de ce projet avant de déplier la solution ci-dessous.
OK, vos runnings sont bien lacées ?
Voici donc un exemple de WBS pour notre projet marathon (cliquez pour déplier) :
Courir un marathon
Vérifier sa condition physique
Prendre rendez-vous chez un médecin du sport
Prendre rendez-vous chez un podologue
Se connaître
Évaluer sa VMA
Réaliser un test du Demi Cooper
Réaliser une séance de VMA type 30⁄30
Définir un objectif de temps
Définir un objectif de temps principal
Définir un objectif de temps « de secours »
S’équiper
Acheter des chaussures de running
Faire réaliser des semelles orthopédiques
Acheter une ceinture porte-gourdes
Acheter des vêtements de course
Acheter un cuissard
Acheter un tee-shirt de course
Acheter des chaussettes adaptées à la course
S’entraîner
Obtenir un plan d’entraînement
Lire des ouvrages spécialisés
Définir la durée du plan
Faire valider le plan par un marathonien expérimenté
Valider que l’on est toujours d’attaque pour commencer l’entraînement !
Réaliser les séances d’entraînement
Tenir un carnet d’entraînement
Régler les détails administratifs
Obtenir un certificat médical de non contre-indication
S’inscrire à la course
Réserver un hôtel sur place
Acheter les billets de train
Aborder le jour J
Adapter son régime alimentaire en dernière semaine
Confirmer son objectif de temps
Courir le marathon
Quelques remarques plus ou moins sportives avant de continuer…
Sur cet exemples simple, vous avez appris à décomposer le travail d’un projet en sous tâches. Vous avez du vous rendre compte que cet exercice n’est pas si simple qu’il n’y paraît : être capable de classer correctement les choses est une compétence qui demande une certaine faculté d’abstraction et de la rigueur dans les choix de structuration. Cela se travaille : faite l’exercice sur d’autres projets de la vie courante !
En outre, ce premier exemple devrait vous avoir interloqué, et amené à mettre le doigt sur certains éléments encore imprécis et non traités par le WBS.
On se rend notamment bien compte que certaines tâches sont « reliées entre-elles », selon des liens de différentes natures :
On ne peut raisonnablement pas définir un objectif de temps sans avoir au préalable estimé sa VMA : certaines tâches sont systématiques précédées par d’autres (on parlera plus tard de la notion de prédécesseur dans MS Project).
On ne peut pas obtenir un certificat médical de non contre-indication si le médecin du sport n’a pas jugé que l’on était apte à courir en compétition : au delà de la notion d’ordonnancement, l’exécution de certaines tâches dépend du résultat d’autres tâches !
Le fait de valider que l’on est toujours d’attaque avant de commencer effectivement le plan d’entraînement marathon n’est pas une tâche qui prend du temps (il s’agit d’une simple validation, un « check ») : certaines tâches n’ont pas vraiment de durée, mais ne sont que des jalons, permettant de donner un go/nogo pour la suite du projet.
S’inscrire à la course sera bien moins fatiguant (et prendra beaucoup moins de temps) que de se taper 3 moins d’entraînement : certaines tâches demandent assurément beaucoup plus de travail que d’autres. Il va nous falloir estimer l’effort nécessaire pour réaliser chaque tâche.
Un peu d’agilité ne fait jamais de mal ! Même si on raisonne en terme de « planification up-front » pour réduire l’incertitude, gardons en tête que vouloir absolument tout planifier d’entrée de jeu est une aventure… périlleuse. En lisant la solution de l’exercice ci-dessus, vous vous êtes probablement dit « Roh, ce bon à rien a oublié de prévoir l’achat d’un ceinture cardio ! ». Pour le coup, je l’ai fait exprès, et on l’ajoutera plus tard : il y aura toujours des imprévus, et il faut absolument adopter un mode de travail qui nous permettra de gérer ceci plutôt que de le subir. D’où l’intérêt d’une planification dynamique, comme nous allons le voir un peu plus tard.
Exercice – Essayez d’identifier quelques tâches liées dans notre projet marathon.
Nous allons à présent voir comment préciser les choses, et notamment ces liens de dépendance entre tâches, grâce à la technique Pert.
Préparer la planification du projet en décomposant les tâches en sous-tâches
Estimer les tâches à réaliser en début de projet
Estimer les tâches à réaliser en priorité
Affecter des ressources aux différentes tâches
Souvenez-vous que le but du WBS est de diviser pour mieux régner : tout problème compliqué peut être décomposé en problèmes plus simples que lui…
À quel moment du projet est-il judicieux de réaliser un WBS ?
Au milieu
Au tout début
À la fin du projet
Quel est la différence entre un WBS et PBS ?
Le WBS est une décomposition du produit, alors que le PBS est une décomposition du travail.
Les deux sont équivalents.
Le WBS est une décomposition du travail, alors que le PBS est une décomposition du produit.
Un WBS doit être réalisé avant de planifier sous MS Project, avec qu’un PBS doit être réalisé après la planification sous MS Project.
Dans un ODT, que représentent les feuilles de l’arbre ?
Les tâches les moins bien identifiées
Les tâches les plus « atomiques »
Les tâches d’encre
Les tâches les moins « atomiques »
Dans un WBS, en haut de l’arbre (racine), on trouve la tâche de plus faible granularité, la plus grosse : en d’autre terme, le projet en lui même. Plus on descend dans l’arbre en se dirigeant vers ses feuilles, plus les tâches sont granulaires, bien définies, et « simples ».
Pourquoi le WBS est limité et doit être complété par d’autres modèles ?
Le WBS ne permet pas de représenter les liens de dépendances entre tâches.
Le WBS ne permet pas de modéliser toutes les tâches.
Le WBS doit être complété par un WPS pour être pertinent.
Aucune estimation n’est fournie par le WBS.
Les tâches conditionnelles ne sont pas explicitées dans le WBS.