WBS/OTP : work breakdown structure
Attendez un peu !
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.
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 »
- Évaluer sa VMA
- 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
- Obtenir un plan 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
- Vérifier sa condition physique
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.
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.
Lectures conseillées
Practice Standard for Work Breakdown Structures
Work Breakdown Structures for Projects Programs and Enterprises
Testez-vous !
- 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
- Au milieu
- Au tout début
- À la fin du projet
- 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.
- 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 »
- 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.