Understanding Critical Path

Seth Godin a vraiment l’art d’expliquer très simplement des choses qui pourraient paraître complexes !

http://sethgodin.typepad.com/seths_blog/2013/11/understanding-critical-path.html par Seth Godin

La chaîne la plus longue de tâches dépendantes, non-compressibles est le chemin critique.

Chaque projet compliqué est identique. Beaucoup de personnes travaillent sur beaucoup d’éléments, dont certains dépendent d’autres.

Je veux un jardin, ce qui signifie que j’ai besoin d’ajouter de la terre, d’un bulldozer, d’un permis, de graines, d’engrais, d’irrigation, de sarcler, de planter, d’entretenir et de temps pour que tout pousse. Exécutez ces étapes dans le mauvais ordre, rien ne se produit. Essayez de faire pousser du maïs en une semaine en lui donnant un bonus ou menaçant de le faire brûler, rien ne se passe…

L’analyse du chemin critique fonctionne à l’envers, en regardant l’échéancier et sa réussite à chaque étape depuis la fin jusqu’au début, en déterminant à chaque étape ce que vous attendrez de la précédente.

Par exemple, si dans votre esprit, le jardin a un joli panneau à l’entrée. Le panneau nécessite environ une semaine pour être réalisé par le gars qui les produit et il ne dépend de rien. Vous pouvez commander le panneau n’importe quand jusqu’à une semaine avant d’en avoir besoin. D’un autre côté, vous ne pouvez pas planter jusqu’à ce que vous ayez labouré et vous ne pouvez pas labourer tant que vous n’avez pas reçu la terre et vous ne pouvez pas vous faire livrer la terre tant que vous n’avez pas obtenu un permis de la localité.

Ce qui signifie si vous êtes la personne responsable tant du panneau que du permis: faites le permis en premier.

C’est évident, n’est-ce pas ? Et pourtant…

Et pourtant la plupart des organisations se concentrent sur des objectifs brillants ou des discussions litigieuses ou se laissent dérouter par des urgences au lieu d’honorer le chemin critique.

Il y a trente ans, j’ai mené une équipe de quarante personnes construisant une série incroyablement complexe de produits, lesquels devaient être expédiés à temps pour la période commerciale de Noël. Les enjeux étaient élevés : si nous rations la date même d’un seul jour, la société entière pouvait capoter.

Nous avons fait un peu d’analyse du chemin critique et avons assez rapidement identifié les groupes de personnes sur lesquels d’autres attendraient à chaque étape de développement du projet. C’est une course de relais et à l’instant, ce sont ces quatre personnes qui portent le témoin.

Je suis sorti et ai acheté quelques boutons – verts et rouges.

Le marché était simple : si vous étiez sur le chemin critique, vous portiez un bouton vert. Tous les autres étaient en rouge. Quand un bouton rouge rencontre un bouton vert, il pose à la simple question : « comment puis-je aider ? »

Le président ira chercher du café pour l’illustrateur qui porte un bouton vert s’il lui fait ainsi gagner trois minutes. Autrement dit, les gens aux boutons rouges n’interrompront jamais une personne à bouton vert. Pas si vous vous souciez du chemin critique, pas si vous vous souciez de la date de livraison.

Une fois que vous êtes conscients de ce qui se trouve sur le chemin, vous comprenez la chose suivante : un délai d’une heure sur le chemin critique au début du projet est la même chose qu’un délai d’une heure sur le projet tout entier à la fin de celui-ci.

Dépêchez-vous tôt, pas tard. Cela revient moins cher de cette façon et c’est aussi bien meilleur pour votre tranquillité d’esprit.

Autres billets sur le chemin critique que vous aimerez peut-être (re)lire:

• Chemin critique avec MS Project
• les chemins critiques dans MS Project par Vincent Capitaine
• avantages et inconvénients des diagrammes de Gantt
• Accélerer le projet : oui, mais !!!
• pourquoi attendre ? (par Seth Godin)

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

Si 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.

Il 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.