la structuration 3D des projets par Jean-Yves Moine

Jean-Yves MoineJean-Yves Moine, consultant en gestion de projet depuis plus de 15 ans, a exercé pour de grands groupes industriels sur des projets allant de la fabrication de boîtes de vitesses, jusqu’au terminal méthanier ou les tramways, en France et à l’international.

Il est l’auteur des ouvrages « Manuel de gestion de projet », « Le pilotage de portefeuilles de projets » et « Gestion de projet avancée » parus chez AFNOR éditions. Il participe régulièrement à l’ouvrage « Management des projets » de l’AFNOR, à la revue « La cible » de l’AFITEP, ainsi qu’à de nombreux forums spécialisés sur l’Internet.

La structuration 3D des projets

Après quelques années de réflexion, j’ai mis au point un outil me permettant de créer bien et rapidement des plannings. Le but initial était de me simplifier la tâche, lors de mes missions de conseil. J’en ai déduis une approche théorique et générale à tous les projets : Le WBS 3D.

La structuration 3D est une méthode permettant de :

  • Mieux comprendre ce qu’est un projet,
  • Construire bien et rapidement la planification d’un projet,
  • Identifier mathématiquement les interfaces d’un projet,
  • Disposer d’un management de projet intégré.

Le principe du modèle 3D, c’est de comprendre que sur un projet industriel de type EPC (Engineering, Procurement, Construction), par exemple  en phase construction : on « installe/construit » des « composants » « quelque part ». Chacun des mots de cette phrase est une dimension ou un organigramme hiérarchique. On trouve dans cette phrase :

  • Des activités (ABS, Activity Breakdown Structure), « Installer/construire », au sens actions ou processus;
  • Des produits (PBS, Product Breakdown Structure),  « composants », c’est-à-dire des équipements, des matériels ou des ouvrages de génie civil aux plus fins niveaux de l’arborescence. Sur ses étages supérieurs, le PBS est composé de systèmes fonctionnels (SBS, System Breakdown Structure);
  • Et des zones (GBS, Geographical Breakdown Structure), « quelque part », qui peuvent être géographiques ou fonctionnelles en fonction des phases du projet.

Le WBS (Work Breakdown Structure) résulte du croisement entre le GBS, le PBS et l’ABS, on écrit :

WBS = GBS x PBS x ABS

Par exemple : « Tronçons n°1 – Voie ferrée – Installation » est une tâche du projet.

Ceci se généralise, le WBS d’un projet peut être traduit en bon Français dans toutes les phases du projet.

De plus, la démarche s’applique sur tous les types de projets, qu’ils soient industriels de type EPC, de développement produit/process, IT ou de service.
Les trois arborescences possèdent une chronologie, elles sont projetées sur les axes d’un repère 3D. Il en résulte des petits cubes 3D qui constituent les tâches du projet.

D’autre part, il y a l’organisation qui travaille (OBS, Organization Breakdown Structure), elle représente une quatrième dimension que l’on symbolise par les couleurs des petits cubes 3D (tâches).

La figure suivante représente un projet. L’image du Rubik cube est amusante mais elle est aussi bien appropriée.
La figure suivante représente un projet.

La position des petits cubes 3D dans le cube du WBS permet d’identifier les interfaces du projet, tout simplement en mesurant les distances entre les petits cubes 3D, puisque les  trois arborescences qui sont projetées sur les axes du cube possèdent une chronologie.

Toutes les intersections ou petits cubes 3D ne sont pas des tâches du projet, il existe un algorithme permettant d’extraire les tâches du cube du WBS : c’est la matrice WBS.

Toutes les disciplines du management de projet tournent autour du cube du projet, que ce soit la gestion documentaire via sa codification, la planification des coûts et des délais, la qualité, etc.

Pour en savoir plus, je vous invite à visiter mon blog sur le sujet : http://3d-wbs.blogspot.com/

J’ai écrit un livre « Management de projet 3D – Le cube projet » qui sera publié et disponible dans 2 mois aux éditions Cépaduès.

Jean-Yves Moine, http://www.jymoine.fr

le site de microsoft projet en français
Partenaire de DantotsuPM

La figure suivante représente un projet.

articles les plus lus de DantotsuPM en janvier 2011

2 articles sur les WBS :

la structure de découpage du projet (Work Breakdown Structure: WBS)

Work Breakdown StructureSi Philip Diab (former PMI Chair Person) devait identifier un seul outil, méthode ou processus qu’il faut maîtriser parfaitement pour les chefs de projet, ce serait la structure de découpage du projet (WBS).

Astuce pour l’examen PMP: la Structure de Découpage du Projet (Work Breakdown Structure : WBS)

J’ai plusieurs fois abordé ce sujet critique de la construction du WBS en management de projet, notamment dans les billets: « conseils pratiques sur le WBS/practical tips on WBS »; « 20 erreurs courantes faites par les chefs de projet nouveaux ou inexpérimentés Par Harold Kerzner, Ph. D., PMP » et « Dix Choses à regarder lors d’une revue de planning (d’échéancier) de projet ».

Cornelius Fichtner nous fournit ici un éclairage personnel et insiste sur la règle des 100% qui est trop souvent oubliée.

Plusieurs articles sur les compétences et attitudes ont également été appréciés par les lecteurs.

protectionun chef de projet devrait-il se soucier de Politique de Bureau ?

La « politique politicienne » qui n’a pour intérêt que de servir quelques personnes qui en usent et en abusent est elle négative et c’est souvent dans ce sens que l’on se réfère à la « politique de bureau » qui ne sert que quelques individus dans l’entreprise à des fins personnelles.

à propos de différences inter culturelles…

La sensibilité aux cultures et à la communication inter cultures est un élément clé de réussite des chefs de projet qui travaillent à l’international. Je pense que cette petite vidéo amusante vous rappellera des souvenirs de situations similaires qui vous sont arrivées. Lesquelles ?

je retiens - team buildingcomposer des équipes comme si les personnes importaient

Les projets sont avant tout une affaire de personnes. Alors que cette affirmation semble tomber sous l’évidence, elle est souvent incroyablement oubliée. L’homo economicus a longtemps été discrédité et a prouvé être beaucoup moins rationnel que beaucoup de philosophes le voudraient. Les gens ne sont pas universellement interchangeables et on ne peut pas s’attendre à ce qu’ils se comportent dans les limites logiques et prévisibles de leur intérêt personnel étroit, mais nous continuons à faire comme si c’était le cas. Comment nous fonctionnons dans une équipe est critique. La raison même d’existence des équipes est que nous ne pouvons pas réussir tout seul; nous avons besoin d’un peu d’aide, nous avons besoin de l’expertise de spécialistes et nous avons besoin des gens pour soulever des montagnes. Cependant, mettez plusieurs personnes dans une même pièce et les défis de communication, de collaboration, de confusion et de conflit adviennent rapidement.

Une bonne dose d’agilité également…

spécialistes et généralistes dans une équipe projet

La spécialisation dans Scrum est un sujet chaud depuis de nombreuses années. Les questions sur la spécialisation arrivent quand j’explique aux gens que d’après la définition de Scrum, une équipe doit être cross-fonctionnelle. Je recommande aussi aux membres d’être à 100 % dédiés à une équipe (ne pas être membres de multiples équipes). La plupart des personnes qui sont nouvelles sur Scrum l’acceptent sans considérer les implications. Parfois quelqu’un demandera : « mais alors, que fera la personne des tests au début du Sprint ? »

Vélocité (dans le développement logiciel)

La Vélocité est une mesure de productivité souvent utilisée dans le développement de logiciel, en particulier avec les méthodes Agile.

Des nouvelles du management de projet au niveau international.

PMI a créé une nouvelle liste de questions/réponses sur les certifications

Bonjour, je pense que vous trouverez cette page « Certifications FAQs » fort utile si vous vous posez des questions sur les certifications proposées par le Project Management Institute.

10 tendances principales du management de projet pour 2011 selon ESI : les Qualités de leader sont en tête de liste

Le 4 janvier, ESI International, a révélé ses 10 Premières Tendances Mondiales de Management de projet pour 2011. Des thèmes clefs qui incluent construire l’influence du chef de projet, l’accélération d’un nouveau leadership et des compétences de communication et l’utilisation accrue d’approches d’étude informelles comme des médias sociaux et la formation résultant de l’expérience.

le management de projet reçoit enfin un réel respect

Selon cet article, des bonnes priorités aux salaires plus élevés, le management de projet et les PMOs reçoivent enfin plus qu’un intérêt de pure forme dans beaucoup de sociétés.

Et pour terminer, quelques meilleures pratiques.

ordre du jour de la session de lancement du projet

Il est à noter qu’il y a diverses réunions de lancement de projet. Celle à laquelle se réfère cet article est interne à l’équipe projet. Elle a pour objectif principal d’établir les normes, partager la même vision des livrables, comprendre les rôles et responsabilités de chacun, avec un clair focus sur le mode de communication que l’on souhaite utiliser entre membres de cette équipe.

quelles sont les clés du succès des leaders ?

J’ai bien aimé dans cet article les cinq compétences que McKinsey a identifié comme étant au cœur du leadership:

1. trouver et donner une signification dans le travail
2. convertir des émotions telles que le stress et la peur en opportunités
3. savoir tirer partie de ses connections et de sa communauté
4. agir face aux risques
5. soutenir l’énergie qui est la force vive du changement

La réflexion disant que toute personne maîtrisant au moins une de ses compétences double sa capacité à conduire le changement me semble un peu excessive et l’autosatisfaction de ceux qui posséderaient les 5 tout autant. Pourtant….

cultivez vos talents – l’organigramme des tâches (OT)

Article écrit par Jean-Baptiste Jourdant, consultant-formateur et Responsable du département Management de projet pour CSP Formation et partenaire de DantotsuPM. Retrouvez cet article sur le blog Management de Projet de CSP Formation à l’adresse suivante : http://www.cultivezvostalents.fr/management-projet/

« – Tiens voilà le planning détaillé.

– T’as utilisé quoi comme logique de découpage de l’OT?

– ???

– Ben oui, pour créer les lots, t’as fait quels choix?

– Tu ne veux pas regarder mon planning plutôt que de me poser des questions métaphysiques? »

Work Breakdown Structure
Livre de référence sur Amazon

Le constat

Approche classique du chef de projet autodidacte : « quand on doit planifier, on planifie. »

Et quand on doit planifier, on le fait de façon détaillée, tant qu’à faire!

Le problème

Si mon chef me demande « la logique de mon découpage », c’est que dans la planification, cette opération doit servir a quelque chose…

Attaquer directement par la planification détaillée, c’est se couper d’une réflexion structurelle sur la dynamique interne de son projet.

Le découpage va impliquer tout d’abord un regroupement de tâches a l’intérieur de lots. Ensuite cela va nécessiter pour chacun de ces lots un responsable auquel la réalisation sera déléguée. Objectif spécifique, moyens adaptés, contraintes QCD (qualité, couts, délai), et aussi les modalités de réplétive seront définis. Enfin, le choix de structuration de ces taches va imprimer un mode particulier de déroulement, de suivi, et de gestion des problèmes.

Un exemple

Si mon projet est le déploiement d’une solution sur l’Europe. Je peux découper géographiquement (lots FR, SP, IT, GB…), ça tombe sous le sens. Mais choisir un découpage par métier (lots marketing, gestion du changement, production, formation, etc…) est aussi possible.

Pourquoi pas aussi un découpage par cycle : lots définition de la stratégie, configuration, communication, implémentation, test, formation, …

Et alors?

Quelle que soit l’option choisie, elle n’est ni bonne ni mauvaise en soi. Elle doit toutefois respecter quelques précautions:

ÊTRE CHOISIE. Rien de pire qu’un découpage par défaut, habitude, issue par hasard d’un autre projet

• ÊTRE ALIGNÉE avec les enjeux du projet. Quand une entreprise « choisit » d’organiser le projet de construction de son avion en affectant le cockpit à un pays européen, le fuselage à un deuxième et les ailes à un troisième, c’est l’enjeu politique qui prend la main : construire l’Europe.

• ÊTRE  « COMPENSÉE ». Là, il s’agit de  prendre en compte la spécificité de son choix et des risques inhérents à cette solution particulière. Pour cela, je vais introduire dans mon management de projet les composantes structurellement manquantes. Si j’ai choisi un découpage géographique, des risques émergent quant à la cohérence métier, technique ou fonctionnelle trans-lots. Je dois donc mettre en place des processus, outils, réunions, de telle sorte que la cohérence métier ou technique soit garantie.

Bien démarrer

A partir d’une lettre de mission, le chef de projet organise une réunion d’acteurs  ou d experts

1. BRAINSTORMING SUR POST-IT : toute tache, activité, lot, thème nécessaire au projet

2. REGROUPEMENT de ces éléments en catégorie. A cette étape, il est indispensable d’envisager au minimum 2 possibilités pour avoir un choix

3. LISTER LES AVANTAGES ET INCONVÉNIENTS de chacune

4. CHOISIR UN DÉCOUPAGE en mettant en œuvre les actions permettant de garantir les avantages de la solution non retenue

5. CRÉER LES LOTS, les sous-lots ou macro-taches, puis nommer les responsables,

Ensuite seulement il sera temps de penser à un planning…

CSP bannière 2016
CSP est partenaire de DantotsuPM

Enregistrer

le « Practice standard for Work Breakdown Structures » de PMI a été examiné mais pas changé

PMI revoit très régulièrement ses standards pour s’assurer qu’ils continuent de coller à la réalité du terrain et de s’enrichir des meilleures nouvelles pratiques. Pour autant, le standard des meilleures pratiques pour le découpage en tâches du projet ne change pas cette année suite à un examen détaillé par trois experts praticiens du management de projet.

Pour d’autres articles sur les WBS consultez:

le site de microsoft projet en français
Partenaire de DantotsuPM

la structure de découpage du projet (Work Breakdown Structure: WBS)

The Work Breakdown Structure (WBS) par Philip R. Diab

Philip DiabSi je devais identifier un seul outil/méthode/processus qu’il faut maîtriser parfaitement pour les chefs de projet, ce serait la structure de découpage du projet (WBS). Encore, je suis toujours stupéfié que dans certains des ateliers de travail poussés que je conduis sur la gestion de projet très peu de praticiens comprennent ce qu’est un WBS et comment développer un bon WBS qui aidera dans la planification de projet.

Heureusement, cette semaine j’enseigne « les essentiels du management de projet » donc mes attentes du savoir des participants sur le WBS sont assez faibles. C’est l’un des sujets que j’essaye de ne pas couvrir à toute vitesse, même si cela signifie que je déborde le temps qui lui est imparti dans l’agenda de l’atelier. L’endroit où je commence d’habitude est par la définition standard du WBS selon le PMBOK, qui expose :

“A deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables.  It organizes and defines the total scope of the project.”

Dans la communauté de management de projet il y a deux vues du développement de WBS. Un groupe se concentre sur l’identification des tâches qui sont nécessaires à accomplir sur le projet. Ce que cela signifie est qu’ils aiment identifier tous « les verbes » associés au projet. Dans ce cas, l’argument est qu’en identifiant les activités, on est capable de produire l’échéancier à partir du WBS. Dans certains outils de planification, il y a même une option pour produire une vue imagée de l’échéancier comme un WBS.

Il y a un autre groupe qui est concentré sur l’identification de tous les livrables qui doivent être produits par l’équipe projet. Ce que cela signifie est qu’ils identifient tous « les noms » associés au projet. Je suis un partisan de cette dernière vue. En travaillant sur la définition de tous les livrables, nous sommes capables de produire une liste des éléments à fournir par le projet. L’identification des tâches, l’évaluation et la planification sont donnent en effet des activités qui suivent mais à mon avis ne font pas partie du développement du WBS.

Voici quelques bons trucs qui m’ont servi bien dans le développement du WBS

  • Concentrez-vous le quoi pas le comment. ”Qu’essayons-nous de faire, pas comment ?”
  • Le WBS est une activité d’équipe, il devrait impliquer les parties prenantes du projet, pas seulement le chef de projet.
  • Donnez l’occasion à l’équipe de « remuer ses méninges » (brainstorm) en utilisant des post-it pour qu’ils puissent travailler tant de haut en bas que de bas en haut. Cela permettra de prendre en compte de multiples styles de travail. Ceux qui aiment commencer par la vue d’ensemble et ceux qui aiment les détails peuvent être satisfaits de cette réflexion en commun d’une façon qui les met à l’aise.
  • “Les mauvaises idées” devraient être encouragées pendant le remue-méninge et prises en compte lors de regroupements de livrables plus tard. L’avantage d’identifier un livrable qui est en dehors du périmètre projet est que cela peut être parqué sur une feuille séparée et documenté plus tard en tant que tel.
  • Assurez-vous de documenter les suppositions faites par l’équipe et d’utiliser ensuite ces suppositions comme une entrée potentielle dans l’identification des risques.
  • Ne vous contraignez pas à essayer de fournir les éléments dans l’ordre, cela viendra plus tard.
  • Assurez-vous que l’équipe documente les livrables internes et externes. Chez IBM nous utilisions le terme « produit de travail » pour des livrables internes pour les distinguer des livrables qui entrent dans un énoncé des travaux (statement of work).
  • Capturez les deux types de livrables. Beaucoup d’équipes oublient souvent qu’une une charte de projet et un plan projet sont en réalité des livrables qui devraient apparaître dans le WBS.
  • Utilisez le développement du WBS comme une opportunité de construction d’équipe en rassemblant les membres du projet et en accélérant les étapes de développement d’équipe.
  • Rappelez-vous la règle de 80 heures par lot de travail. À un bas niveau dans le WBS, on trouve les lots de travail. Ces lots de travail sont des livrables composés de tâches dont la somme devrait atteindre environ 80 heures d’effort.

Les bénéfices et utilisations du WBS sont multiples.

En identifiant la portée totale du projet par une décomposition par livrables, le WBS aide l’équipe de projet à réaliser les choses suivantes :

  • Comprendre ce qui est « à l’intérieur » et ce qui est « à l’extérieur » du périmètre du projet. Ce qui n’est pas listé, est en dehors. Ce processus peut permettre l’équipe de projet de documenter qu’un livrable donné est à l’extérieur du périmètre.
  • Envisagez les secteurs potentiels de risque, en vous servant des suppositions documentées.
  • Construisez une fondation pour développer une référence de base solide de projet et chaque lot de travail peut être utilisé pour identifier des tâches principales selon règle des 80 heures.
  • Communiquez avec des parties prenantes sur les besoins potentiels qui pourraient être demandés en croisant exigences et livrables.
  • Établissez une responsabilité claire pour les lots de travail et assignez des propriétaires/champions.

Work Breakdown StructureIl y a beaucoup d’autres trucs et bénéfices pour le WBS, tels que le système de codage qui peut être utilisé ou comment se servir du WBS pendant la phase d’exécution et dans le processus de contrôle. Même si chacun de ceux-ci est une considération importante, mon focus pour ce billet a été en utilisation du WBS comme un robuste point d’ancrage pour l’équipe pendant le processus de planification.

Je conclurai en soulignant qu’un bon WBS peut en effet être un facteur différenciant entre un projet réussi et un échec. Ceux qui ne sont pas familiers avec le WBS ou ne savent pas comment le créer doivent passer du temps à parcourir le PMBOK Guide et autres livres qui contiennent les appropriées.

le site de microsoft projet en français
Partenaire de DantotsuPM

Tirer parti des Tâches Inactives dans MS Project 2010

Article original: Leveraging Inactive Tasks in Project 2010


utiliser les taches inactives dans MS ProjectL’une des nouvelles fonctionnalités de Microsoft Project 2010 est de pouvoir inclure des Tâches Inactives dans un planning. Des Ressources Inactives (nous en connaissons tous quelques unes) sont disponibles depuis quelque temps quand on utilise MS Project avec Project Server.

Vous pouvez vous demander pourquoi faire cas de ces Tâches Inactives. Il va probablement y avoir beaucoup d’utilisations ingénieuses de celles-ci qui seront inventées par des utilisateurs comme ils se familiarisent avec la dernière version de Microsoft Project. La ligne officielle assez vague de Microsoft en annonçant cette fonctionnalité était qu’elle permet une planification simplifiée et de jouer des scénarios d’analyse.

Voici deux scénarios où des Tâches Inactives pourraient apporter un avantage significatif.

Changement de contenu :

changement planningUne chose dont vous pouvez être assuré de dans un projet est que les choses changeront et qu’elles changeront à nouveau. Combien de fois avez-vous dû supprimer et rétablir ensuite des tâches en raison de changements introduits puis enlevés ? Avec des tâches inactives vous pouvez simplement marquer une tâche comme étant inactive si elle devait être supprimée du contenu de votre projet. Un enregistrement de celle-ci est conservé dans le planning mais il n’a aucun impact sur les délais, le travail ou les coûts dans le plan de projet. Si la tâche est rétablie, elle est simplement marquée comme étant active à nouveau.

Cette approche élimine le besoin pour le chef de projet de maintenir des versions différentes du planning. Un autre aspect utile de cette fonctionnalité est que vous pouvez voir facilement combien de tâches sont identifiées comme étant inactives sur le cycle de vie d’un projet, ce qui peut être une puissante illustration des effets perturbateurs de changements incessants.

Gestion des risques :

risk managementLes projets ont invariablement des risques associés; Project Server fournit un moyen utile pour suivre les risques associés aux projets dans un espace de travail SharePoint. Dans l’Analyse de Risque, nous identifions des risques potentiels et planifions en conséquence. Notre liste de risques dans SharePoint peut identifier l’impact du risque, notre stratégie de réduction et de contingence.

Des tâches inactives peuvent être incluses dans le planning du projet pour modéliser les actions de réduction qui peuvent être exigées si un risque devait se manifester. Dans le management des risques les mots qui l’indiquent sont “cela ne devrait pas se produire, mais cela arrive …” des tâches inactives peuvent être employées pour permettre la réduction du risque et peut-être encore plus important pour rappeler aux personnes ce risque potentiel et les actions proposées et acceptées pour atténuer le risque. Si un risque se produit, activer les actions dans planning revient simplement à activer la tâche inactive appropriée.

Il n’y a aucun doute que les utilisateurs expérimentés de Microsoft Project inventeront des utilisations encore plus imaginatives de cette nouvelle fonctionnalité de Microsoft Project, faites-les nous connaître. Nous vous ferons bien sûr également part de ce que nous inventerons.

le site de microsoft projet en français
Partenaire de DantotsuPM

conseils pratiques sur le WBS/practical tips on WBS

trucs et astuces

Bonjour,

Voici ce que j’utilise comme principes de base lorsque je conçois ou revois le niveau de détail d’un Work Breakdown Structure (WBS):

1. Une tâche devrait être nommée avec un unique verbe actif. Exemple: Réaliser le design et développer un bout de code informatique devrait être séparé en 2 tâches: une pour le design et une pour le développement.

2. Une tâche devrait résulter en la production d’un unique livrable (une documentation, un document d’analyse, un programme informatique…)

3. Une tâche devrait être la responsabilité d’une seule personne.

4. Une tâche devrait permettre une évaluation d’effort/de temps avec un niveau de confiance très élevé

plus de détails sur: http://blogs.orange-business.com/live-france/2009/09/une-approche-pour-construire-une-structure-de-decoupage-de-projet-efficace.html

Hello,

Here a few principles I use when building or reviewing the level of details of a Work Breakdown Structure (WBS):
1. A task should be named with a unique active word. Example: Design and code a software programme should be split in 2 tasks: one for the design and one for the coding.

2. A task should produce a single deliverable (a documentation, an analysis paper, a software programme…).

3. A task should be the responsibility of a single person.

4. A task should enable an estimate of time and effort with a very high degree of trust

further details at:

http://blogs.orange-business.com/live/2009/09/simple-advice-to-build-efficient-ptoject-work-breakdown-structure.html