DantotsuPM.com

Clarifying the Usage of Schedule Dependencies, Constraints & Deadlines

Kiron D. Bondale

http://www.pmhut.com/clarifying-the-usage-of-schedule-dependencies-constraints-deadlines

Par Kiron D. Bondale

Alors qu’un échéancier de projet correctement développé est un objet d’art, mal créé il peut être une source de frustration pour l’équipe projet et un risque pour le succès du projet.

Le développement d’un échéancier avant d’avoir passé du temps à décomposer le contenu d’un projet est probablement le péché primaire de la plupart des faibles planificateurs, mais il est suivi de près par l’utilisation incorrecte de dépendances d’échéancier, des contraintes et des délais.

1. Les dépendances dans l’échéancier représentent une connexion logique entre deux activités discrètes.

Partenaire de DantotsuPM

De telles relations devraient être rapprochées de la nature des activités elles-mêmes et PAS de qui exécutera les tâches ou d’autres contraintes similaires.

Les dépendances le plus généralement fournies incluent:

• Fin-à-début (Finish-to-Start): La relation causale la plus commune et pour laquelle aucune explication n’est nécessaire à son utilisation.
• Début-à-fin (Start-to-Finish): Rarement utilisée mais utile en développant un échéancier en arrière à partir d’une date finale fixe (rétro-planning).
• Début-à-début: Cela représente une vraie relation entre deux activités et n’a aucun rapport avec leurs prédécesseurs. Si j’ai deux tâches qui commencent en même temps à cause d’un prédécesseur, ce sera mieux représenté par deux relations de fin-à-début (par exemple les tests des systèmes et la documentation peuvent tous les deux commencer une fois que le développement est terminé, mais il n’y a aucune relation entre les tests et la documentation donc nous ne voudrons pas utiliser une dépendance de Début-à-début dans ce cas). Cette dépendance est souvent utilisée avec un retard pour représenter la connexion entre deux activités qui fonctionnent en parallèle, mais ne peuvent pas commencer exactement en même temps (par exemple appliquer la première couche de peinture et appliquer la deuxième couche de peinture). Un vrai exemple de Début-à-début est une course entre deux coureurs où chaque coureur est représenté comme une activité séparée – tandis qu’ils finiront probablement à des moment différents, tous les deux doivent commencer exactement en même temps.
• Fin-à-fin (Finish-to-Finish): C’est généralement utilisé pour représenter les activités qui doivent s’achever en même temps afin de pas avoir un impact sur leurs successeurs ou sur un ou plusieurs des objectifs pour le projet. Un exemple en dehors des projets est de préparer la nourriture dans un restaurant. Les chefs doivent s’assurer que le plat principal et les garnitures sont prêts exactement en même temps pour que la présentation puisse être faite sans  impact sur la qualité.

2. Les contraintes représentent une limitation dans le monde réel

Limitation qui empêche une activité de commencer ou de s’achever quand elle le devrait normalement (par rapport à la date de début de projet ou ses dépendances). Les contraintes sont souvent employées improprement quand la tendance naturelle pour un planificateur novice est de forcer manuellement des dates de début ou des dates finales de tâche. Les exemples valables de contraintes incluent des dépendances de ressource (par exemple l’indisponibilité d’une salle pour recevoir une formation) ou des facteurs externes (par exemple les périodes de d’interdiction de maintenance qui affecteraient les certains types de tâches). Des calendriers de ressource ou de tâche si supportés par le moteur de l’outil de planification fournissent une alternative à l’utilisation des contraintes. Cependant, même avec ces fonctionnalités c’est une bonne idée de documenter la condition spécifique qui a nécessité l’utilisation de la contrainte ou du calendrier pour que si la condition ne s’applique plus à un moment ultérieur, la contrainte puisse être supprimée aboutissant à une performance de planning potentiellement améliorée.

3. Les contraintes et les dates impératives "deadlines"

Les contraintes sont de temps en temps utilisées (particulièrement "finir le" “finish on” ou "ne pas finir plus tard que" “finish no later than”) quand un délai impératif "deadline" marcherait mieux. Tandis que des dépendances et les contraintes impactent la logique et les dates de début ou de fin des tâches, les délais impératifs fournissent un affichage visuel au planificateur qu’un délai "du monde réel" va probablement être manqué. Sur de grands échéanciers, alors qu’il pourrait y avoir de nombreux jalons, il peut y avoir seulement quelques vrais délais impératifs qui doivent être observés. Pour s’assurer que le planificateur est conscient des conséquences négatives potentielles d’un changement de planification, les délais impératifs fournissent les moyens "doux" de notification qui n’empêcheront ni les tâches de se déplacer librement ni l’optimisation de l’échéancier.

4. Les retards(lag)

Ils sont parfois évités en faveur de tâches artificielles insérées entre deux activités dépendantes. Par exemple, une fois que j’ai passé une commande avec mon vendeur, une période de temps passera avant que l’équipement soit livré. L’utilisation d’une tâche pour représenter ce délai de livraison est incorrecte à moins que l’activité ne soit exécutée par l’équipe projet et de plus cela faussera le calcul de pourcentage de complétude du projet tout entier. Une meilleure approche est d’introduire un retard entre les deux activités représentant le nombre de jours ou de semaines prévu pour la livraison.

Je n’ai pas essayé de fournir un aperçu complet de chacune de ces fonctionnalités, mais j’ai  bon espoir que cela clarifie leur utilisation pour que le bon outil soit utilisé pour le bon travail!

Tags:planning, WBS

What Does A Good WBS Look Like?

http://herdingcats.typepad.com/my_weblog/2011/10/what-does-a-good-wbs-look-like.html par  Glen B. Alleman

Il y a de nombreux livres et des conseils pour construire une bonne Structure de Découpage du Travail (Work Breadown Structure : WBS). Mais il y a un principe sous-jacent qui guide, ou devrait guider cet effort. C’est le MECE ( Mutuellement Exclusif, Collectivement Exhaustif).

Mutuellement Exclusif

Aucune sous-catégorie ne devrait représenter une autre sous-catégorie ("aucun chevauchement"). Dans le WBS cela signifie que les produits sont uniques donc nous pouvons leur assigner le coût et déterminer qui va les développer.

Collectivement Exhaustif

L’ensemble de toutes les sous-catégories, prises ensemble, devrait entièrement caractériser la plus grande catégorie dont les données font partie ("aucun trous"). Le WBS représente le "tout le travail". Si ce n’est pas dans le WBS, cela ne va pas être fait.

WBS 3D de Jean-Yves Moine. Cliquez sur l’image pour lire l’article.

Construire un bon WBS, ne commence pas par la définition du niveau du WBS, cela commence par le principe MECE et l’architecture résultant du produit (ou du service). L’architecture du produit ou du service est développée par une approche de systèmes, la construction de WBS est de l’architecture de systèmes, et ce pour plusieurs raisons :

1. Nous avons besoin de connaître les composants du système qui sont ME (Mutuellement Exclusifs).
2. Les enfants de ces composants doivent être CE (collectivement exhaustifs). Des parties peuvent être partagées dans le WBS, si le travail pour ces parties peut être partagé, mais elles doivent avoir un numéro différent dans le WBS, donc elles sont ME, tout en étant CE.
3. Puis le WBS peut être utilisé pour rassembler les coûts et répondre à la question, "quel est le coût de cette partie, sous-ensemble, combinaison, système.
4. Les ressources sont alors assignées nominativement et forme la RAM (la Matrice de d’Affectation des Responsabilités) pour voir qui travaille sur quoi, à quel coût.
5. Ce système de codage peut être positionné dans l’IMS (Integrated Master Schedule) dans des colonnes séparées (WBS et peut-être CWBS : Contract Work Breakdown Structure) et avec la Catégorie de Ressource pour montrer quand la chose est construite, combien elle coûte et dans quelle catégorie de travail.

Partenaire de DantotsuPM

Tags:planning, WBS

What Does A Good WBS Look Like?

http://herdingcats.typepad.com/my_weblog/2011/10/what-does-a-good-wbs-look-like.html par  Glen B. Alleman

Partenaire de DantotsuPM

Il y a de nombreux livres et des conseils pour construire une bonne Structure de Découpage du Travail (Work Breadown Structure : WBS). Mais il y a un principe sous-jacent qui guide, ou devrait guider cet effort. C’est le MECE ( Mutuellement Exclusif, Collectivement Exhaustif).

Mutuellement Exclusif – Aucune sous-catégorie ne devrait représenter une autre sous-catégorie ("aucun chevauchement"). Dans le WBS cela signifie que les produits sont uniques, donc nous pouvons leur assigner un coût et déterminer qui va les développer.

Collectivement Exhaustif – L’ensemble de toutes les sous-catégories, prises ensemble, devrait entièrement caractériser la plus grande catégorie dont ces données font partie ("aucun trous"). Le WBS représente "tout le travail". Si ce n’est pas dans le WBS, cela ne va pas être fait.

Construire un bon WBS, ne commence pas par la définition des niveaux du WBS, cela commence par le principe MECE et l’architecture résultant du produit (ou du service). L’architecture du produit ou du service est développée par une approche de systèmes, la construction de WBS est de l’architecture de systèmes, et ce pour plusieurs raisons :

1. Nous avons besoin de connaître les composants du système qui sont ME (Mutuellement Exclusifs).
2. Les enfants de ces composants doivent être CE (collectivement exhaustifs). Des parties peuvent être partagées dans le WBS, si le travail pour ces parties peut être partagé, mais elles doivent avoir un numéro différent dans le WBS, donc elles sont ME, tout en étant CE.
3. Puis le WBS peut être utilisé pour rassembler les coûts et répondre à la question, "quel est le coût de cette partie, sous-ensemble, combinaison, système.
4. Les ressources sont alors assignées nominativement et forme la RAM (la Matrice de d’Affectation des Responsabilités) pour voir qui travaille sur quoi, à quel coût.
5. Ce système de codage peut être positionné dans l’IMS (Integrated Master Schedule) dans des colonnes séparées (WBS et peut-être CWBS : Contract Work Breakdown Structure) et avec la Catégorie de Ressource pour montrer quand la chose est construite, combien elle coûte et dans quelle catégorie de travail.

Si le sujet vous intéresse, ne manquez pas ces quelques billets publiés précédemment:

• la structure de découpage du projet (Work Breakdown Structure: WBS)
• Astuce pour l’examen PMP: la Structure de Découpage du Projet (Work Breakdown Structure : WBS)
• l’organigramme des tâches (OT)
• le “Practice standard for Work Breakdown Structures” de PMI a été examiné mais pas changé
• conseils pratiques sur le WBS/practical tips on WBS

Tags:planning, WBS

Jean-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 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

Partenaire de DantotsuPM

La figure suivante représente un projet.

Tags:planning, WBS