Le WBS a pour but d’aider à organiser le projet, à établir la planification de référence et le budget prévisionnel. Il permet également de déléguer et de contractualiser la mission confiée à chaque acteur.

Le Work Breakdown Structure (WBS ou OT Organigramme des Tâches) est un arbre représentant la liste structurée de tous les travaux du projet. Les travaux sont à ce stade uniquement identifiés.

Ce graphe, utilisant la notation de précédence, représente les relations entre les tâches du type « Fait partie de ». C’est une vision maîtrise d’œuvre des tâches afin de déterminer les niveaux de visibilité du projet.

Pour construire cette vision, il faut …

• Effectuer l’inventaire exhaustif des tâches à réaliser
• Identifier les lots de travaux (LT)
• Attribuer à chaque LT un responsable unique
• Définir de façon claire les niveaux de responsabilités et leurs limites

Une codification des tâches peut être mise en place pour faciliter la lecture et l’identification de chaque tâche du projet. Ceci s’avère très utile lors de gros projet.

Il y a plusieurs façons de construire un WBS selon la manière de regrouper les travaux (regroupements par produits, types, phases, tâches, responsabilités, certitude, réutilisation). Les durées recommandées pour les tâches sont de 10 jours minimums et de 2 à 3 mois maximum.

Dans la Figure : Exemple d’Organigramme des Tâches (WBS) pour un projet informatique, on constate que le projet a été découpé en lots. L’objectif est de simplifier la structure de suivi du projet, car il s’agit d’un projet important de développement. En effet, nous le verrons dans la suite de l’étude, que chaque lot est suivi par un responsable différent. La donnée importante à prendre en compte lors de la création du WBS, est la durée qui est représentée par chaque tâche. Il faut donc estimer cette durée, et ensuite y affecter des ressources, cette étape est nécessaire pour la phase de réalisation du PERT(1) . Voici un exemple de tableau permettant d’affecter à chaque tâche une durée et des ressources :

L’Organigramme des Tâches n’est pas uniquement conditionné en fonction du nombre de tâches et des Lots de Travaux, en effet il est possible d’affiner le niveau de détail en prenant en compte les aspects humains.

Le niveau de détail de l’OT peut être déterminé par :

• La nécessité de responsabiliser les acteurs, confier des tâches parcellaires est déresponsabilisant
• Trop de détail sur le travail à réaliser peut être considéré comme un manque de confiance et être une source de conflit
• L’impossibilité pour le chef de projet d’assurer le suivi d’un trop grand nombre de tâches

Un des principales objectifs de l’OT étant d’engager les acteurs, on a toujours intérêt à mener cette étape de façon participative. Il est préférable de construire l’OT avec l’équipe projet en prenant en compte les remarques de chacun que de proposer un OT définitif, élaboré seul dans lequel l’équipe ne reconnaîtra pas sa contribution.

L’identification des livrables du projet (le PBS)

Une autre manière de représenter le résultat visé du projet, c’est à dire le produit, est le Product Breakdown Structure (PBS ou Organigramme Technique des produits OTP) qui se représente également sous la forme d’un arbre. Ce graphe est une vision maîtrise d’ouvrage des produits à fournir. Ces produits sont des états stables et mesurables ayant une valeur ajoutée par rapport aux tâches. Le Product Breakdown Structure a pour objectifs de définir la nomenclature des objets du projet, de décomposer l’objet du projet en sous-ensembles et de définir les compétences nécessaires à la mise en place du projet.

Pour bien comprendre le processus de planification du projet, j’ai choisi d’illustrer mes propos avec le même exemple de découpage du projet en tâches (le WBS), c’est pourquoi voici-ci dessus la vision PBS du projet informatique. A chaque tâche identifiée dans le WBS y est associé un produit dans le PBS. Certains de ces produits pourront constituer des livrables pour des dates jalons du projet, ce qui permettra de fixer des objectifs intermédiaires aux acteurs projets et ainsi structurer le temps du projet.

L’affectation des ressources et l’organisation (le RBS et l’OBS) La gestion des ressources dans un contexte multi-projets est fondée sur le Resource Breakdown Structure (RBS ou Structure de Décomposition des Ressources). Il représente la hiérarchie des ressources de l’équipe projet.

Le Resource Breakdown Structure a pour objectif de décomposer le projet en ressources et de regrouper ses ressources par nature ou en équipes. Le chef de projet doit, à travers le RBS, mettre en place des calendriers de travail, vérifier la disponibilité en termes de compétences et affecter les responsabilités hiérarchiques.

Le RBS permet d’évaluer la quantification des ressources nécessaires au projet, dont la charge est issue des estimations du temps à passer par tâche et par profil. On associe ensuite au RBS l’Organisation Breakdown Structure (OBS ou Organigramme Fonctionnel OF) pour identifier les différents niveaux de responsabilités des acteurs. L’OBS consiste à croiser les acteurs du RBS avec les rôles et responsabilités suivantes :

• R : Responsabilité (obligatoire et unique)
• E : Encadrement
• P : Production (ou participation)
• V : Validation
• C : Certification / Approbation
• S : Support

Il est possible de représenter l’OBS sous forme de matrice, comme ci-dessous :

Légende :

• DBS : Définition des Besoins
• AF : Analyse Fonctionnelle
• CAS : Conception Architecture Système
• SIS : Spécifications Internes Système
• PRG : Programmation
• INT : Intégration

Cette matrice associe le WBS et le RBS pour affecter les rôles et responsabilités des différents acteurs. Elle se veut le reflet de l’organisation à mettre en place dans le cadre du projet. A ce stade, nous disposons de l’ensemble des outils nécessaire pour réaliser la planification proprement dite, à savoir : le WBS, le PBS, le RBS et l’OBS. Il est donc possible de procéder à l’ordonnancement des tâches (PERT) puis au Gantt6 . 5 L’ensemble des acteurs n’est pas représenté sur cette matrice par manque de place. L’objectif principal étant de montrer son utilisation et non de coller strictement à la réalité.

(1) PERT : Program Evaluation and Review Technic

Auteur : Hervé Jacquiau management-projet.org – Article sous licence Creative Commons – Publication originale Jeudi 15 mars 2007, par Hervé Jacquiau