les mythes d’Agile : « il n’y a aucune planification dans #Agile »

« Il n’y a aucune planification dans Agile, vous improvisez au fil de votre progression »

http://trainings24x7.com/2015/06/22/list-of-free-pmp-sample-questions-websites/ par Leontranter

Je vais aborder certains des mythes persistants sur le Développement logiciel Agile. Le premier et probablement le plus connu est : « il n’y a aucune planification dans Agile, vous improvisez au fil de votre progression ». Ceci n’est pas du tout vrai.

En fait, je vais aller plus loin et poser une affirmation audacieuse :

Beaucoup de projets agiles font plus de planification que des projets en mode Waterfall / Cascade.

En fait, ils peuvent même faire bien trop de planification. J’espère que les gens qui utilisent les méthodes en cascade toussent et recrachent leur café partout sur leur bureau en réponse à cette affirmation. Décomposons cet argument et expliquons pourquoi je dis ça.

Il ne s’agit pas de plans mais de planification

Une de mes citations favorites est celle de Dwight Eisenhower :

« Les plans ne sont rien. La planification est tout. »

protectionCeci est un élément essentiel à la compréhension du rôle que joue la planification dans le Développement Logiciel Agile. En « Waterfall », l’idée est que le chef de projet rédige un grand échéancier au début du projet. Souvenez-vous, le contenu est habituellement fixé dès le départ et vous pouvez produire votre Structure de Répartition de Travail dont vous tirez votre plan de ressources (qui fait le travail) et votre diagramme de Gantt (le séquencement dans lequel il est fait) pour livrer ce contenu. Et avec tout ceci, vous pouvez déterminer vos coûts, parce que ces ressources ont des coûts spécifiques.

Puis, tout le monde signe (Oui ,nous aimons tous les signatures, n’est-ce pas !) le grand plan de projet et il est accepté et bloqué. Puis tout le monde vient travailler, selon le grand plan que le chef de projet a produit. Et que fait le chef de projet maintenant ? Il se contente de surveiller, lisant des revues ? Bien sûr que non ! Son travail est de protéger le plan à tout prix.

Les gens continueront à essayer de déplacer des choses, d’ajouter du contenu, d’allonger les délais, de permuter la personne A pour la personne B, de retarder ceci, de supprimer cela, de remplacer cette technologie pour cette autre et le chef de projet doit donc passer beaucoup de temps à :

  • Essayer d’empêcher tout cela de se produire (parce que le plan est signé), vous vous souvenez ? Ce qui signifie nous ne pouvons pas le changer, OK ?) et
  • documenter les risques s’il ne peut pas empêcher l’événement, laisser les parties prenantes savoir la catastrophe épouvantable qui s’abattra bientôt sur le projet en raison de ces changements non planifiés.

Ceci ne semble-t-il pas être une situation amusante pour tout un chacun et plus encore pour le chef de projet ?

Pourquoi les projets entrent-ils dans une telle spirale ?

Les projets en cascade s’engagent sur un plan quand il n’y a encore aucune information

aveugleLes projets en cascade élaborent un grand plan très complexe au début du projet, quand il y a :

  • Peu ou pas d’informations sur le travail qui a besoin d’être fait
  • Peu ou pas d’informations sur le livrable/produit, ce à quoi il doit ressembler et son fonctionnement
  • Peu ou aucune informations sur les problèmes et risques externes (dépendances, concurrents, partenaires, etc.)

Pas étonnant qu’il y ait autant de changements demandés sur de tels projets : comme les informations commencent à arriver, beaucoup d’entre elles sont en conflit avec le plan, parce qu’il a été basé sur des informations incomplètes (c’est-à-dire il a été composé de conjectures, de suppositions et d’estimations).

Ceci m’amène à une autre de mes citations favorites, cette fois d’un général allemand d’il y a longtemps, Helmuth von Moltke:

« Aucun plan ne survit au contact avec l’ennemi. »

Ce qui peut donner dans notre contexte: aucun plan de projet ne survit au contact avec le projet. Et c’est très bien ainsi, parce que nous ferions mieux de ne pas essayer de tout planifier sur le projet dès le début.

Les projets agiles planifient à plusieurs reprises par petits morceaux

Les projets agiles (utilisant Scrum ou l’une de ses variantes) ne créent pas un grand plan au début, ils font beaucoup de petites activités de planification (à chaque sprint) qui produisent de petits plans (des plans de sprint).

Ainsi au début d’un sprint de deux semaines, vous définissez un plan pour les deux semaines suivantes : c’est appelé la planification de Sprint. À cette réunion, l’équipe sélectionne des articles du Sprint Backlog et discute de combien ils peuvent en compléter pendant ce Sprint et comment le travail sera fait. Plutôt que d’essayer de définir un plan pour un travail que l’on ne connaît pas ou ne comprend pas vraiment, l’équipe élabore un petit plan pour un petit lot de travail qui est :

  • Bien connu et compris (autrement ce ne sera pas un candidat à entrer dans le Sprint Backlog)
  • Pouvant être achevé en un sprint (qui est souvent de deux semaines).

Donc vous définissez un petit plan pour une petite quantité de travail, puis vous faites le travail, puis vous faites le plan suivant pour le travail suivant, et cetera, à plusieurs reprises, encore et encore.

Ceci résonne-t-il comme « aucune planification » pour moi ? Pas du tout. Vous commencerez probablement vite à en avoir assez de planifier en suivant cette approche.

Un si petit plan apporte-t-il vraiment de la valeur ?

Vous pourriez penser « mais c’est complètement bidon ce plan, il ne couvre que deux semaines. Le plan en cascade était grand et beau et le Gantt géant expose graphiquement tout ce tout le monde va faire pendant les six mois à venir ! ».

Bien sûr, mais deux points :

  1. Le plan est en grande partie artificiel puisque créé au début du projet, quand personne n’avait vraiment assez d’informations sur le projet (car nous découvrons des informations au fil de notre progression)
  2. Le plan a été créé presque entièrement par le chef de projet, qui ne fera en réalité presque aucun travail lors de la construction du livrable et pas du tout par l’équipe, qui fera presque tout le travail de production du livrable.

Une grande partie de la valeur réside  dans la Planification, pas dans le Plan.

Rappelez-vous la précédente citation de Eisenhower.

plans are nothingLes membres de l’équipe se réunissent régulièrement et discutent du travail, combien de ce travail ils pensent qu’ils peuvent faire, combien il restera à faire.

  • Ceci apportera-t-il plus de valeur que nous l’avions pensé à l’origine ou moins ?
  • Qu’est-ce qui se révèle être plus facile ou plus difficile que nous ne le pensions de prime abord ?

Ces conversations ont énormément de valeur et aident à guider les développeurs et le propriétaire de produit tout au long du voyage vers l’achèvement du produit ou du projet.

Question: Avez-vous constaté qu’Agile n’apporte pas assez ou bien au contraire trop de planification ?

Enregistrer

Enregistrer

Enregistrer

Enregistrer

comment découper vos « User Stories » #Agile (Histoires Utilisateur) avec la méthode INVEST

Splitting User Stories

http://www.agileadvice.com/2016/06/03/scrumxplean/splitting-user-stories/ par Faisal Ansari

Un défi usuel auquel sont confronté les équipes Scrum inexpérimentées est lié au découpage des « User Stories » (dans Scrum, les articles du Product Backlog) pour qu’elles soient suffisamment granulaires pour le développement. Le modèle INVEST est une bonne façon de tester si les « User Stories » sont bien écrites.

Microsoft est partenaire de DantotsuPM
Microsoft est partenaire de DantotsuPM

I.N.V.E.S.T.

  • IIndépendante
  • N– Négociable
  • V– de Valeur
  • EEstimable
  • SSuffisamment petite
  • TTestable

Indépendante

Chaque « User Stories » doit être indépendante l’une de l’autre. Ceci empêche les chevauchements entre les items; de plus, cela permet à l’équipe de les implémenter dans n’importe quel ordre.

Négociable

Les détails du travail doivent être négociables, tant parmi les parties prenantes que l’équipe. Les besoins spécifiques et décisions de conception seront étoffés pendant le développement. Beaucoup de praticiens agiles recommandent d’écrire les « User Stories » sur une petite fiche – ceci est intentionnel pour qu’une quantité limitée de détails puisse être prescrite.

de Valeur

Chaque « User Stories »doit ajouter un valeur métier/business au produit, au client et/ou à l’expérience des utilisateurs.

Estimable

Une bonne « User Stories » peut être suffisamment bien comprise par l’équipe pour qu’ils puissent l’évaluer – pas précisément – mais qu’à un haut niveau ils en perçoivent la taille. Il est utile de comprendre l’effort relatif en comparaison d’autres « User Stories ».

Suffisamment petite

Une « User Story » n’est pas assez petite si l’équipe ne peut pas la faire faire dans un seul Sprint. Comme des grandes « User Stories » sont divisées en items plus petits, la clarté sur la taille et la mise en œuvre est plus grande, ce qui améliore la probabilité que l’équipe le réalisera en un Sprint.

Testable

Chaque « User Story » devrait être testable; ceci est une caractéristique commune de tout besoin bien écrit. Si l’équipe ne peut pas déterminer comment la « User Story » peut être testée, c’est une indication que la fonction désirée ou la valeur business désirée ne sont pas assez claires.

Découpage vertical ou horizontal

Il y a deux manières communes de découper des « User Stories » : verticalement ou horizontalement. La découpe horizontale divise l’article au niveau d’un composant architectural. Exemple : Interface Utilisateur, bases de données ou services back-end. Tandis que, une découpe verticale aboutit à un résultat logiciel démontrable qui ajoute de la valeur au business. Donc, on recommande de découper verticalement les « User Stories » afin de réduire les dépendances et améliorer la capacité de l’équipe à livrer un incrémentent de produit potentiellement utilisable à chaque sprint.

Des exemples de découpe de « User Stories »

Trop grosse User Story:
Trop grosse User Story: « En tant que client, je peux payer ma commande pour recevoir les produits »
En tant que client, je peux payer ma commande pour recevoir les produits

Si la susdite histoire devait être divisée de façon verticale, elle pourrait se décomposer en fonction des façons de payer pour un client comme suit…

  • En tant que client, je peux faire un paiement par carte pour ma commande et collecter des points de récompense sur ma carte de crédit.

Et/ou

  • En tant que client, je peux faire un paiement PayPal pour ma commande pour que achever mon achat en toute sécurité sans partager les détails de ma carte de crédit avec un autre détaillant.

Le point clé de noter dans les « User Stories » verticalement décomposées comme ci-dessus consiste en ce que chaque « User Story »passe les tests INVEST mentionnés plus tôt et donc un Propriétaire de Produit (Product Owner) peut prioriser ces « User Stories » en fonction des besoins clients. Cependant, si une approche horizontale a été utilisée pour diviser la « User Story » (c’est-à-dire décomposition selon les couches et composants architecturaux) alors la mise en œuvre de tels besoins aboutira à une fonctionnalité utilisable Seulement quand tous les composants horizontaux seront finalement livrés et intégrés.

Découpage par flux de travail

revoir mon panier de courses
revoir mon panier de courses

Une autre approche souvent utilisée sur les « User Stories » est de se concentrer sur les étapes individuelles qu’un utilisateur peut entreprendre pour atteindre son objectif final. C’est-à-dire une « User Story » qui décrit un long parcours ou « flux utilisateur » dans un système peut être décomposé selon les étapes qui en représentent les parties. En reprenant l’exemple précédent d’un client faisant un achat en ligne, la « User Story » peut être décomposée de la manière suivante :

  • Fournir mes informations bancaires
    Fournir mes informations bancaires

    En tant que client, je peux passer en revue les articles que je veux mettre dans ma commande pour être confiant que je paye pour les bons articles.

  • En tant que client, je peux fournir mes informations bancaires pour ma commande pour recevoir les produits que j’ai achetés.
  • Recevoir une notification par SMS
    Recevoir une notification par SMS

    En tant que client, je peux recevoir un avis de confirmation pour mon achat pour suivre et garder une trace de mon achat.

D’autres méthodes

Il y a de nombreuses autres méthodes qui peuvent être utilisées dans le découpage des grandes « User Stories » comme :

Visitez le blog Agilistic
Visitez le blog Agilistic
  • par déroulement heureux / malheureux (ce qui se passe quand tout va bien versus quand il y a des exceptions, déviations ou autres problèmes)
  • par options d’interaction / par plate-forme
  • par types de données ou paramètres
  • par scénarios de test
  • par rôles
  • par ‘j’optimise maintenant ‘ contre ‘ j’optimise plus tard
  • par compatibilité de navigateur

la liste ci-dessus est détaillée (en anglais) dans ce billet: Blog.agilistic.nl.

Autres Ressources Utiles

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

L’approche classique du chef de projet autodidacte peut être dangereuse, voire préjudiciable, au succès du projet

Jean-Baptiste Jourdant
Jean-Baptiste Jourdant

Dans un article intitulé « l’organigramme des tâches en management de projet » publié sur ce blog il y a déjà 5 ans, Jean-Baptiste Jourdant, consultant-formateur et Responsable du département Management de projet pour CSP Formation partait d’un constat simple :

L’approche classique du chef de projet autodidacte est de dire « quand on doit planifier, on planifie. Et quand on doit planifier, on le fait de façon détaillée, tant qu’à faire ! »

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

WBS 3D - OBSEn effet, 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 (qualité, couts, délai)…

WBS 3D - ZBSEnfin, le choix de structuration de ces tâches va structurer le développement et le suivi du projet. Ces groupement par lots de tâches peuvent refléter une organisation du projet par métier (informatique, processus, opérations, commercial, marketing…), ou par région et pays dans ces régions pour le développement et déploiement de nouveaux produits par exemple, ou par cycle du projet : définir la stratégie, configurer, communiquer, implémenter, tester, former, …

Quelle que soit l’option choisie, elle n’est ni bonne ni mauvaise en soi.

CSP est partenaire de DantotsuPM
CSP est partenaire de DantotsuPM
Jean-Baptiste préconisait dans ce billet de respecter quelques précautions dans le choix de l’option :

WBS 3D - PBSÊTRE CHOISIE. Rien de pire qu’un découpage par défaut, par habitude, ou héritée par hasard d’un autre projet (qui pourrait être totalement différent).

• ÊTRE ALIGNÉE avec les enjeux du projet et les objectifs de la société.

• ÊTRE  ÉQUILIBRÉE et « COMPENSÉE ». En fonction du choix de découpage, le chef de projet devra probablement ajouter dans le management de son projet les composantes structurellement manquantes. Il doit par exemple mettre en place des processus, outils, réunions… pour garantir la cohérence métier ou technique si le choix de découpage est géographique. Ou, à l’inverse, veiller à impliquer les régions et pays si le découpage du projet est par métier.

Comment bien démarrer?

Jean-Baptiste propose que le chef de projet organise une réunion d’acteurs  ou d’experts et suive la démarche suivante:
  1. BRAINSTORMER : Lister toute tâche, activité, lot, thème nécessaire au projet.
  2. REGROUPER: Envisager au minimum 2 possibilités de regroupement des tâches pour avoir un choix.
  3. POSER LES AVANTAGES ET INCONVÉNIENTS de chacune de ces possibilités.
  4. CHOISIR UN DÉCOUPAGE et y incorporer les actions permettant d’incorporer les avantages de la solution non retenue.
  5. CRÉER LES LOTS, les sous-lots ou macro-tâches, puis nommer les responsables de ceux-ci.

Ensuite seulement il sera temps de penser à un planning…

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Saviez-vous que 3 des termes de PRINCE2 sont agiles ?

En fait, beaucoup de termes de Prince2 sont en soi agiles et peuvent ajouter un niveau de flexibilité à la livraison de tout projet.

http://www.alctraining.com.au/4-prince2-terms-you-may-not-know-are-agile/ par ALC Group

Dans le monde de l’informatique, beaucoup de praticiens agiles croient que PRINCE2 n’est pas assez flexible pour les demandes business contemporaines. Cependant, pour ceux qui ont passé la formation PRINCE2, la plupart seront conscients que ceci est faux.

3 termes Agile Prince2En fait, beaucoup de termes de Prince2 sont en soi agiles et peuvent ajouter un niveau de flexibilité à la livraison de tout projet. Pour renforcer cette remarque, voici trois termes qui sont plus agiles que beaucoup ne le pensent.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Premier terme Agile – Initiation

A few videos to get started on Agile, Scrum and Kanban
A few videos to get started on Agile, Scrum and Kanban

Quand des projets PRINCE2 sont implémentés, ils comptent sur le cas d’affaires pour garantir qu’ils sont justifiables. Il y a aussi les plans qui décrivent ce qui arrivera, les contraintes budgétaires et les stratégies de livraison. Tous ces éléments sont identifiés et décidés pendant l’étape d’initiation.

Le cas d’affaires est l’espace parfait pour articuler une perspective agile et structurer les besoins de projets et planifiant d’incorporer en mode Agile des jeux de fonctionnalités et sorties de produit. Prenez par exemple le management du projet et de l’approche de livraison, les chefs de projet PRINCE2 peuvent tout à fait utiliser des approches agiles comme Scrum et Kanban.

De plus, les plans pourraient aussi être en « time boxing » plutôt que cascade, tandis que le financement pourrait être basé sur les releases plutôt que les étapes techniques traditionnelles liées à l’effort de livraison.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

En implémentant ces approches dans l’étape d’initiation, le projet peut se concentrer sur la livraison de valeur, diminuant les délais de time-to-market et permettant aux utilisateurs finaux d’utiliser des composants de valeur dès que possible.

Second terme Agile – Work package (Lot de travail)

Une des idées fondamentales des approches Agiles est l’auto-organisation des équipes. Pour que ceci devienne une réalité, les équipes doivent être conscientes de leurs responsabilités et organisées selon des  frontières comprises et communicables.

Le lot de travail PRINCE2 n’écarte pas ces principes de base Agile et peut faciliter cette forme d’organisation. Par exemple, les lots de travail peuvent permettre aux praticiens agiles de communiquer aux parties prenantes leurs rôles, responsabilités et autorité. Ceci permettra aux équipes d’être certaines de ce qu’elles doivent faire pour construire et livrer des produits de valeur.

Troisième terme Agile – Tolérance

prioriser2Avec PRINCE2, le contrôle de la tolérance est sous la responsabilité du chef de projet. La tolérance se réfère à n’importe quelle variation des estimations acceptées lors du cas d’affaires par rapport aux délais, coûts, risques, bénéfices et contenu (périmètre). Si ces tolérances semblent en passe d’être excédées, il est de la responsabilité du chef de projet de remonter ceci au Conseil de Projet pour maintenir un contrôle formel des changements et obtenir une rapide prise de décision.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Les méthodologies agiles ont les mêmes approches, bien que sous l’apparence de mécanismes de priorisation. Par exemple, beaucoup de praticiens utiliseront MoSCoW pour ajuster le contenu de leur projet et rester les délais et budget alloués.

Produit Viable Minimum (MVP)
Produit Viable Minimum (MVP)

La qualité suit une approche similaire. Prenez par exemple la fabrication d’une voiture. Une approche Agile se concentrerait sur le produit viable minimal – le moteur, le châssis et d’autres fonctions centrales, tandis que les fonctionnalités comme le système de climatisation et le toit ouvrant seront inclus seulement si le temps et les coûts le permettent. PRINCE2 peut faire de même. Il a déterminé les tâches requises et le budget alloué qui est accompagné du contenu. Ceci permet aux projets d’être changés en temps réel pour répondre à des éventualités du marché ou dans le périmètre du projet.

Pour beaucoup, PRINCE2 est toujours l’une des plus, sinon la plus, importante des méthodologies de management de projet disponibles.

Assister à un cours de formation PRINCE2 est une excellente façon de comprendre l’agilité inhérente à cette méthode. C’est aussi une bonne façon d’étendre vos perspectives de travail et d’améliorer votre capacité à livrer des projets rentables dans les temps, avec un focus client et des standards élevés.

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

connaissez-vous la règle des 18 mois et pourquoi des projets sont annulés pour de mauvaises raisons ?

Why Projects Are Cancelled For The Wrong Reasons

http://www.fatcat.com.au/news/home/Ask+an+Advisor/418_0.html

Un nombre élevé et disproportionné de projets sont annulés par le management à 18 mois.

Comme dans tout projet, il y a un flux et un reflux naturel. Un rythme naturel. Ce que je trouve intéressant est que le rythme semble s’installer dans ce que j’appelle la Règle des 18 Mois.

La règle des 18 Mois déclare que :

Loi_de_Moore
Loi de Moore
Un nombre disproportionné de projets est annulé par le management à 18 mois.

N’oublions pas que beaucoup de secteurs ont un rythme naturel, par exemple technologique. Le rythme technologique le plus célèbre est la Loi de Moore qui prévoit que la croissance dans le nombre de transistors par puce doublera tous les vingt-quatre mois. D’autres lois technologiques qui ont un rythme naturel incluent la Loi de Kryder pour le stockage sur disque (~12 mois) et la Loi d’Haitz pour la production de LED’s (~18 mois).

Pourquoi y-aurait-il une Règle de 18 Mois pour les projets ?

Y aurait-il une certaine loi naturelle dans le travail ? La réponse est simple : oui. La nature humaine.

En regardant en arrière tous les projets que j’ai managés dans ma carrière, le cycle de 18 mois d’annulation des projets revient à travers industries, contextes, technologies, tailles d’organisations et nationalités. La règle semble universelle. Pourquoi ?

Dix-huit est le nombre maximal de mois pendant lesquels le management peut souffrir. Cette douleur est la répétition des efforts de re-justification d’un projet dont on attend encore de voir les bénéfices.

Pourquoi 18 mois et pas 12 ou 24 ?

monthsPensez à un projet donné. La plupart débutent en milieu d’année avec un financement et des ressources alloués à grand-peine par le management en se basant sur le mérite et les impacts et bénéfices potentiels. Quand le cycle budgétaire suivant arrive, le projet est bien lancé et le financement est presque assuré car le projet a démarré depuis moins d’une année et que personne ne s’attend à ce qu’il ait déjà un impact. Donc, les ressources sont maintenues en place et le projet continue de progresser.

Le deuxième cycle est une question totalement différente.

Quand le cycle budgétaire suivant survient, des questions s’ élèvent sur le projet :
  • Est-ce que ce projet est toujours aussi important ?
  • Y-aurait-il des projets plus importants que nous devrions financer au lieu de celui-là ?
  • Atteignons-nous les progrès escomptés ?
des budget limités, voire compressés...
il faut se battre pour chaque nouvelle année de financement !
Pourquoi ces questions ?

Parce que chacun dans la chaîne de management doit re-justifier le projet pour encore une autre année de financement. C’est ce deuxième tour qui cause toute l’angoisse. Le résultat est que le management arbitrera s’il faut se battre pour une autre année de financement ou laisser le projet mourir et éviter cette peine. Comme nous pouvons tous l’apprécier, éviter la douleur est une réaction humaine naturelle.

Si le management pouvait voir la valeur (quelque chose qui justifie la peine), approuver que le projet continue ne serait pas un problème. Là où la plupart des équipes de projet s’attirent des ennuis est qu’elles ne saisissent pas cette réaction d’évitement de douleur du management. Dans leurs esprits, le management devrait seulement obtenir les financements et avoir confiance en équipe.

Le résultat est qu’un grand pourcentage de projets sont tués à 18 mois parce que l’on n’a pas démontré leur valeur.

Attendez ! Dites-vous. Nous avions un accord que ce serait un projet sur plusieurs années et que les bénéfices ne viendraient qu’à la fin. Ceci ne prouve-t-il pas que la Règle des 18 Mois ne s’applique pas ? NON. Si vous croyez vraiment que vous pouvez éviter le problème en obtenant un accord au départ, alors vous ne comprenez pas la nature humaine. Au cas où votre projet passerait le jalon des 18 mois, la peine grandira avec chaque cycle ultérieur. Ce qui signifie que vous devrez démontrer une valeur et un impact toujours croissants pour pouvoir continuer. La douleur ne part pas avec le temps. En réalité, elle augmente.

Ce n’est pas la faute de la direction. C’est la faute de l’équipe de projet qui échoue à comprendre le désir du management d’éviter la douleur.

Comment une équipe évite-t-elle cette règle ?

règle des 18 moisSuivez les quelques étapes simples suivantes :

1) Comprendre le cycle de votre organisation (ou votre client) pour vous assurer que vous comprenez le timing. Quand les budgets et/ou les stratégies sont-ils bouclés chaque année ?

2) Définir votre portée de projet et de livrables pour être certains que ce que vous livrez a un impact/une valeur avant que la règle ne soit appliquée.

3) Pour les projets qui s’étendent au-delà de 18 mois, découpez-les et faites de chaque partie un projet distinct. Pourquoi ? Pour esquiver le problème d’évitement d’une peine qui s’intensifie avec le temps car chaque projet remet les compteurs à zéro.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Dans mon expérience, j’ai vu la règle des 18 mois appliquée à des projets qui auraient du être tués dès le départ et à d’autres qui n’auraient jamais dus être arrêtés.

Cette apparente prise de décision aléatoire du management peut être perturbante et démoralisante dans une organisation. Si vous êtes dans le management, regardez-vous dans le miroir et comprenez que la nature humaine joue un rôle dans votre prise de décision de tuer des projets. Aidez vos équipes à le comprendre.

Si vous menez un projet, utilisez ces stratégies de management de projet simples afin d’éviter ce que dans le passé vous aviez attribué à des caprices du management.

CSP est partenaire de DantotsuPM
CSP est partenaire de DantotsuPM

En comprenant la Règle des 18 Mois, vous pouvez vous assurer que vos projets auront l’impact que vous désirez.

Bonne chance !

estimations de temps optimistes (par rapport à honnêtes)

Optimistic time (vs. honest time)

http://sethgodin.typepad.com/seths_blog/2015/01/optimistic-time-vs-honest-time.html par Seth Godin

Les estimation de temps optimistes semblent être une bonne idée. « Nous expédierons en janvier. » « La conférence commencera midi. » « Je serai là dans dix minutes. »

L’espoir est que l’attente même de l’événement élèvera nos attentes et augmentera les chances que quelque chose se produise réellement.

courir après la montre - dernières minutesEn fait, il y a cependant des coûts énormes au temps optimiste. Quand vous annoncez des choses basées sur l’optimisme, le reste des personnes avec lesquelles vous vous engagez construit des plans autour de vous et de votre annonce. Et le coût de la personne qui n’a pas votre logiciel au moment promis ou qui reste assise dans une salle de réunion à vous attendre pendant des heures est élevé.

L’alternative est le temps honnête. Temps sans recours ni négociation. Le train part à 5h52 pas 5h55, peu importe combien vous voulez qu’il attende.

Le logiciel est délivré ou la conférence démarre précisément quand nous avons dit que nous allions le faire. Donc, tout le monde planifie pour cela et en dépend et l’efficacité augmente.

executive timeOn n’expédie pas parce que c’est prêt. On expédie parce que c’est promis.

(Étonnamment, cette règle fait que les choses soient prêtes à temps, bien plus souvent).

C’est une position et un contrat avec vous-même. J’expédie quand j’ai dit que le ferai.

On demand – Webinar – Tips and Tricks for More Accurate Scheduling in Microsoft Project

Microsoft Project is a scheduling tool, and if you feed the software with the right information, Microsoft Project will produce an accurate schedule for the project.

Partenaire de DantotsuPM
Partenaire de DantotsuPM
Dale Howard
Dale Howard

However, many project managers fail at the basics of scheduling, which results in an inaccurate and untrustworthy schedule of their projects. A project manager, needs to have an accurate schedule.

In this powerful presentation, Dale Howard, a Microsoft Project MVP, will demonstrate a series of useful tips and tricks that will result in a more accurate and trustworthy schedule in Microsoft Project.

Agenda Highlights:

  • Using calendars effectively
  • Completing task planning as « deliverables » planning
  • Assigning resources properly
  • Understanding the proper use of constraints and deadline dates

Register for this free on demand webinar.

Campana & Schott est partenaire de DantotsuPM
Campana & Schott est partenaire de DantotsuPM

comment approcher un projet à date fixe ?

How To Approach A Fixed Date Project

http://www.pmsouth.com/2013/05/04/how-to-approach-a-fixed-date-project/ par Harry Hall

Beaucoup de chef de projets haïssent les projets aux dates de fin fixées à l’avance. Les managers décident d’une date et disent « respectez-la ». Souvent, le manager a peu ou aucune compréhension du niveau d’effort requis.

Pourquoi les chefs de projets n’aiment pas les dates fixes

  • dateManipulation. Les chefs de projets estiment qu’ils sont manipulés. LE management donne une date empirique. Plus tard, ils changent la date quand elle ne peut pas être respectée. Ce syndrome amène de la méfiance entre PMs et direction.
  • Manque de contrôle. Le chef de projets veut avoir le contrôle sur leur univers de projet. Quand quelqu’un dicte une date fixe, ils perdent un peu du contrôle désiré.
  • La réputation du chef de projets. Le chef de projets sait que sa réputation est basée sur sa capacité à livrer les projets dans les temps. Naturellement, nous n’aimons pas être mis dans une position où nous n’allons probablement pas rencontrer le succès.
  • Stress. Le chef de projets se sent coincé. Le sponsor pousse le chef de projet à faire pression sur l’équipe projet. L’équipe projet pousse le chef de projets à résister aux demandes du sponsor.
Partenaire de DantotsuPM
Partenaire de DantotsuPM

Manager un Projet à Date Fixe

Quand vous êtes mis au challenge de manager un projet à date fixe, voyez-y une opportunité. Vous pouvez livrer le projet dans les temps avec la bonne approche.

Voici certaines choses à considérer:
  • go signEngagez-vous. Faites savoir à votre sponsor que vous mettrez tout en œuvre pour livrer le projet à la date demandée. Établissez un rapport de travail positif avec votre sponsor. Exprimez le besoin de collaboration entre le sponsor et l’équipe.
  • Négociez les ressources compétentes. Formez une équipe avec la bonne alchimie. Les personnes, plus que quoi que ce soit d’autre, sauront faire la différence.
  • Choisissez votre cycle de vie de projet. Utiliserez-vous une approche traditionnelle en cascade ou quelque chose comme un cycle de vie adaptatif (avec les méthodes agiles) ? La réponse à cette question a des implications significatives dans l’aide ou l’entrave à la réussite de projets plus courts.
  • Définissez la charte de projet.
  • Rassemblez et priorisez les besoins.
  • Définissez le périmètre/le contenu.
  • wbs
    Un manuel de référence

    Créez la structure de répartition de travail (WBS).

  • Développez votre échéancier. Si votre chemin critique s’étend au-delà de la date fixée, travaillez avec votre sponsor et votre équipe pour réduire le contenu ou reporter certaines fonctionnalités sur de futures étapes ou itérations.
  • Complétez l’identification et l’évaluation initiales des risques.
  • Construisez des fonds de contingence. Cette réserve n’est pas un amortisseur artificiel. Le fond de contingence est basé sur les risques résiduels connus.

(Gardez à l’esprit qu’une bonne gestion des risques raccourcit souvent le projet. Les risques sont éliminés ou diminués. Cependant, il y a toujours les risques résiduels qui devraient être reconnus dans vos fonds de prévoyance. Par exemple, vous pouvez spécifier que le projet exige que des six semaines supplémentaires pour manager les risques identifiés sur le projet.)

Campana & Schott est partenaire de DantotsuPM
Campana & Schott est partenaire de DantotsuPM

Astuces pour la compression de planningcar-pound-compression-destroy-leeroy

  • Ajoutez des ressources (c’est-à-dire, compression des délais ou « crashing ») et considérez d’utiliser des heures supplémentaires. Soyez prudent. L’ajout de ressources ou mise en des ressources existantes peut causer plus de mal que de bien. Réduire les délais résulte aussi souvent en un accroissement des coûts.
  • Accélérez l’exécution par chevauchement des tâches (« fast tracking ») : Cherchez des façons d’exécuter des tâches qui sont sur le chemin critique en parallèle ou en chevauchement. Cela peut provoquer des choses à refaire et des risques plus importants.

success 2Votre approche envers un projet à date fixe déterminera votre succès.

Le Chef de projets doit avoir la bonne attitude, s’assurer que les engagements envers le sponsor et l’équipe sont appropriés et choisir les bons processus, outils et techniques.

Question : quelles autres astuces proposeriez-vous pour permettre aux PMs de manager des projets à date fixe ?

La gestion agile de votre projet d’innovation avec Claude Emond

Nouvel atelier de Claude Emond en Gestion de Projet Agile des projets d’innovation et de développement de produits, en collaboration avec L’IDP.

Une approche comme toujours originale de notre ami Claude Emond: Sur 3 journées (4, 9 et 16 nov 2015) incluant, pour chaque participant, 3 heures de coaching personnel sur un projet de leur choix, pendant, entre et après chaque jour de formation.

Inscriptions et Détails
Inscriptions et Détails

Objectif de cette formation-action

Outiller les gestionnaires de projets en développement de produits sur les techniques de gestion agile. Cette formation leur permettra d’accélérer leur projet, de mieux mobiliser leur équipe de développement et ainsi maximiser les bénéfices et le retour sur investissement.

Bénéfices pour les entreprises participantes

  • Claude Emond FormateurPréciser le rôle du chef de projets, en mode agile
  • Augmenter le taux de succès de vos projets de développement de produits
  • Maîtriser le savoir-faire qui permettra d’accroître votre efficacité en gestion de projets
  • Développer vos compétences pour mobiliser et guider les équipes de projets agiles vers le succès
  • Intégrer de nouvelles connaissances par la formation-action dans le cadre d’un projet en cours dans votre entreprise
  • Profiter de l’encadrement des formateurs entre les rencontres pour maîtriser les nouveaux outils et mener à bien votre projet ;
  • Développer les habiletés de leadership de vos chefs de projets implanter des outils de suivi pour livrer vos projets en respectant les coûts  et les délais.

Claude Emond formationQui devrait participer à ce programme de formation ?

Ce programme de formation spécialisé (voir la brochure détaillée) s’adresse aux personnes jouant le rôle de chefs de projets, ou membre d’équipe de projet, dans le cadre de projets de développement de produits et/ou de services.

Il est destiné à tous ceux qui désirent approfondir par l’action leurs connaissances en gestion de projets de développement de produits.

Une méthodologie ancrée dans l’action !

Ce programme unique de formation combine la présentation de notions théoriques et d’outils pratiques. Des exercices permettent d’appliquer les enseignements et d’utiliser les nouveaux outils dans le cadre d’un projet actuellement en cours dans votre entreprise. Entre les rencontres, vous devrez accomplir différentes tâches avec les membres de votre équipe de projet tout en bénéficiant d’une aide personnalisée de la part  du formateur.

De précédents billets de Claude sur l’Agilité:

nouvelle référence du management des ressources dans les organisations matricielles

Microsoft Project 2016 : nouvelle référence du management des ressources dans les organisations matricielles par Campana & Schott

La sortie de Microsoft Project Server 2013 il y a un peu plus de deux ans permettait pour la première fois un accès optimisé aux données projet depuis des appareils mobiles, facilitant ainsi la communication et la collaboration au sein des équipes.

La possibilité d’utiliser l’étendue des fonctionnalités de Microsoft Project Server en tant que service en ligne depuis le cloud avait elle aussi suscité un grand intérêt car elle permettait de simplifier le déploiement de l’outil dans toute l’entreprise, allégeant ainsi la charge du département IT. Bien que la nouvelle version Microsoft Project 2016 semble moins innovante, les apparences sont trompeuses, comme a pu le constater Campana & Schott au cours de ses nombreux tests. Les fonctionnalités étendues de management des ressources ont notamment fait très bonne impression car elles permettent de coordonner une organisation matricielle nettement plus efficacement qu’auparavant. En fonction de la spécialité de chaque entreprise, la mise à niveau avec la nouvelle version promet non seulement un gain de productivité significatif, mais aussi une gestion multi-projets plus souple, ce qui s’accompagne évidemment d’une plus grande réactivité face à la concurrence.

Les versions actuelles de Microsoft Project Server et Project Online offrent d’ores et déjà un aperçu global de l’évolution des projets en cours, depuis différentes perspectives. Les responsables de ressources et supérieurs hiérarchiques peuvent ainsi voir à tout moment sur quels projets leurs ressources sont affectées. Cependant, dans la pratique, ces affectations sont sujettes à de nombreuses modifications : certains employés peuvent subitement ne plus être disponibles pour raison de maladie ou parce qu’ils sont appelés ailleurs pour une urgence. Par conséquent, les chefs de projet sont amenés à replanifier leurs projets et il devient alors difficile pour les supérieures hiérarchiques d’évaluer rapidement et précisément les répercussions possibles de ces modifications sur les autres projets. L’engagement pris lors de l’affectation initiale est alors rompu. De ce fait, les supérieurs hiérarchiques manquent d’une base de décision valide pour accepter ou refuser les nouvelles demandes de projet affectant les membres de leurs équipes. Cette difficulté est principalement due au fait que la précédente version de Microsoft Project Server ne prévoyait aucun process officiel de validation d’affectation de ressources par les responsables hiérarchiques.

Campana & Schott est partenaire de DantotsuPM
Campana & Schott est partenaire de DantotsuPM

Les défis dans la pratique

Dans la pratique, on trouve des exemples typiques de ce genre de problématiques aussi bien dans les entreprises de services que dans le génie logiciel et l’ingénierie, secteurs dont la croissance est souvent soudaine et qui implique le déploiement rapide de nombreux sites. Il n’y a, dans les premières années, que peu de projets multi-sites : il est alors facile de garder une vue d’ensemble précise de la répartition des tâches parmi les employés. Mais à mesure du développement de l’entreprise et de l’augmentation du nombre de projets, cet aperçu devient de plus en plus compliqué : le personnel d’un site en particulier sera-t-il sur ou sous-occupé le mois suivant ? Où se trouvent les spécialistes les plus compétents pour le prochain projet ? Dès lors, les demandes urgentes de gros clients ne peuvent plus être traitées dans un délai suffisamment court, un inconvénient de taille dans la relation client. Il est en effet impossible de déterminer directement si la commande concernée pourra être prise en charge dans le délai imparti. Dans de tels cas, il devient finalement indispensable de procéder à une optimisation des outils pour le management des ressources. Cet exemple est typique dans la mesure où, souvent, une infrastructure de gestion de projet qui fonctionne bien à la base ne parvient néanmoins pas à tenir le rythme de croissance de l’entreprise sur le long terme.

Solutions complémentaires face à l’improvisation Excel

Par le passé, les utilisateurs de MS Project Server se servaient souvent de solutions complémentaires spécialisées réconciliant les besoins des projets et les engagements des équipes métiers au sein des organisations matricielles. D’autres ont essayé de modéliser la planification des ressources inter-projets au sein de fichiers Excel complexes. Malheureusement, ces solutions sont rarement pérennes et la double saisie engendrée entraîne d’inévitables incohérences. Résultat : davantage de coûts au lieu de davantage de transparence.

Une planification plus souple pour une productivité accrue

La version Microsoft Project Server 2016 offre de nouvelles perspectives dans la gestion des capacités et des ressources. Les nouvelles fonctionnalités « demande de ressources » et « engagement de ressources » remédient en effet au problème décrit plus haut : l’outil historise l’intégralité des accords et refus délivrés par les responsables hiérarchiques vis-à-vis des demandes d’affectations émanant des chefs de projet. Cela crée ainsi un socle solide sur lequel peut se baser la communication entre toutes les parties prenantes – y compris les responsables hiérarchiques.

c&s1_Resource_Engagement_PWA_Proposed_Request_Generic_Role_Timephased_DataIl s’agit là d’une fonctionnalité à forte valeur ajoutée pour le métier, attendue depuis longtemps par de nombreux clients de Campana & Schott. La capacité de décision ainsi acquise au niveau du responsable des ressources peut à elle seule générer un gain de productivité d’environ 10 % dans les entreprises de services. Autre avantage : ces fonctionnalités étendues de Microsoft Project Server 2016 en management de ressources sont directement disponibles, aucune configuration additionnelle n’est nécessaire.

Capacité immédiate de décision

Par ailleurs, la nouvelle version Microsoft Project Server 2016 favorise la prise rapide de décisions par le biais des dites « heat maps » – une fonctionnalité qui impliquait par le passé le recours à un partenaire d’implémentation : des graphiques de couleur permettent maintenant d’identifier d’éventuelles ressources en sur-utilisation ou à contrario en sous-utilisation entre différents projets, et ce même avec un important volume de données et des interdépendances extrêmement complexes.

c&s2_Resource_Engagement_PWA_Engagement_HeatmapLes cartes utilisent les couleurs des feux tricolores, avec des seuils à définir librement. Cela permet aux supérieurs hiérarchiques d’agir avec un maximum de flexibilité lors de la planification des interventions et de prévenir ainsi des situations d’impasse au niveau d’un projet ou d’une ressource critique.

D’autres nouveautés côté client riche

La fonctionnalité « Timeline » (frise chronologique) permettait déjà dans Project 2013 de visualiser le déroulement du projet le long d’un axe de temps. La version Microsoft Project 2016 propose à présent dans le client riche l’option de gérer plusieurs axes de temps pour un projet et de les afficher sous forme de barres superposées. Par exemple, la barre supérieure peut représenter le projet dans son ensemble, tandis que celle du dessous décrit plus précisément un lot spécifique du projet. Il est ainsi possible de différencier précisément les phases du projet, sans que les détails ne brouillent la vue d’ensemble du projet.

c&s3_MultipleTimelineEn outre, l’intégration d’une nouvelle fenêtre de recherche directement dans l’interface du client riche réduit considérablement le temps nécessaire pour trouver des fonctions rarement utilisées.

c&s4_Tell_me_what_you_want_to_do

Version Cloud : des innovations plus rapides à utiliser

Avec Project 2016, Microsoft poursuit sa route vers le cloud. Bien que Project Online ne soit disponible que depuis le début de la sortie de Project 2013, la plupart des nouveaux clients britanniques par exemple misent sur la version Online, le plus souvent en association avec Office 365. La France en revanche se montre encore hésitante vis-à-vis des solutions cloud et continue de privilégier la version on premise. Toutefois, l’interaction de Project Online avec d’autres offres de Microsoft dans le cloud devient de plus en plus importante en termes de productivité et d’efficacité – par exemple avec SharePoint Online, Power BI, Skype Entreprise Online, Dynamics CRM Online, ou encore avec la plateforme sociale dédiée aux entreprises Yammer, qui fait partie de Microsoft depuis 2012.

Microsoft est Partenaire de DantotsuPM
Microsoft est Partenaire de DantotsuPM

D’un point de vue utilisateur, le grand avantage d’une solution cloud comme Project Online est sans doute sa disponibilité immédiate évitant de longs et fastidieux accords avec le département IT. Comme les versions en ligne sont conçues et mises à disposition des utilisateurs de manière incrémentielle, les cycles d’innovation se raccourcissent. Inutile à présent d’attendre la version suivante : les nouvelles fonctionnalités sont immédiatement disponibles et utilisables. Cela réduit considérablement la charge de travail du département IT puisque le portefeuille d’applications gérées en interne n’augmente pas et les contraintes liées à un changement de version n’ont plus lieu d’être. Pour les PME notamment, qui n’utilisaient jusqu’à présent que le client riche en local, Project Online devient une possibilité simple de passer à Project Server, sans nécessiter d’investissements en nouveau matériel. De même, pour les entreprises utilisant à présent Project Server 2003, 2007 ou 2010 qui envisagent une migration, l’option Online mérite d’être étudiée. Microsoft a d’ores et déjà mis un terme au support global pour les versions 2003 et 2007 et le support devrait s’arrêter d’ici la fin de l’année pour Project Server 2010.

Conclusion

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Dans les entreprises dotées d’une organisation matricielle, les avancées significatives en termes de management des ressources de Microsoft Project Server 2016 apportent davantage de transparence entre la planification de projet et la planification hiérarchique. L’historisation des validations concernant les demandes d’affectation de ressources permet une meilleure visibilité et communication entre les différentes parties prenantes. Les outils complémentaires pour la planification des ressources tels que les tableurs Excel deviennent ainsi superflus. Par ailleurs, des rapports standards et des « heat maps » intégrés facilitent l’analyse d’éventuelles sur-affectations ou sous-affectations des ressources entre les différents projets de l’entreprise. Dans l’ensemble, la solution avancée de gestion des ressources proposée par Microsoft Project Server 2016 agit comme un important levier pour l’amélioration de la répartition des activités parmi les acteurs projet et donc pour l’augmentation de la productivité de l’entreprise. En effet, plus la part de chiffre d’affaires générée par ressource est élevée, plus l’impact d’une planification optimisée influe sur le résultat commercial. Néanmoins, il ne faut pas oublier qu’un outil de management, aussi performant soit-il, ne portera aucun fruit s’il n’est pas accompagné de procédures, règles et rôles appropriés afin de l’ancrer dans l’organisation.

Microsoft Project 2016: Milestone for resource management in matrix organizations

With the new version of Project 2016, Microsoft makes the use of resources in projects more transparent.

The utilization is improved, productivity increases.

balancer les ressources allouéesOverall, managers can better plan – this has been observed in a first test by the Campana & Schott experts.

White paper excerpt:

« In companies with matrix organizations, the significant expan sion of capacity and resource management in Microsoft Project 2016 brings additional transparency to the interaction between project planning and line planning.

Microsoft est Partenaire de DantotsuPM

The seamless documentation of all resource approvals makes agreements between team and project managers much more reliable than is the case now.

Additional tools for resource management are no longer required – particularly with respect to Excel shadow planning.

In addition,the standard reports and integrated heat maps also facilitate the analysis of possible excess planning and under-utilization. »

A Campana & Schott whitepaper available for free.

Campana & SChott est partenaire de DantotsuPM
Campana & Schott est partenaire de DantotsuPM

Nouveau dans MS Projet 2016: les chronologies multiples

New in Project 2016 Multiple timelines

http://msprojectnow.com/blog/new-in-project-2016-multiple-timelines Par Melinda Schultz

Les chronologies de projet sont d’excellentes façons de visualiser nos progrès sur un projet.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Bientôt, dans MS Projet 2016 davantage de fonctionnalités pour les Chronologies :

1) Chronologies multiples :

chrono1Si vous utilisez Projet 2016, vous pouvez créer une deuxième barre de chronologie, pour afficher des chronologies multiples, puis vous pouvez changer les dates de début et de fin de chaque chronologie.

2) Réarranger les tâches, les couleurs et plus encore

Vous pouvez utiliser la chronologie en l’état, ou vous pouvez réarranger les tâches de toute façon qui vous sied, ajouter du texte et même changer les couleurs pour qu’elles se détachent mieux.

Avant :

chrono4 before

Après :

chrono5 after

chrono share3) Partager et imprimer la chronologie

Il est aussi devenu beaucoup plus facile de partager et d’imprimer vos chronologies.

Lire l’article dans sa totalité sur Microsoft blog.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

que trouve-t-on dans un bon plan de projet du point de vue de la planification ?

Quand le projet atteint la fin de la phase de planification que vous attendriez-vous à voir dans un bon plan de projet du point de vue de la planification ?

8 éléments clés:

  1. PM PlanTous les livrables sont représentés dans la structure de découpage de projet (SDP) ou « Work Breakdown Structure » (WBS).
  2. On a répondu toutes les questions sur le périmètre/contenu du projet : risques, contraintes, suppositions.
  3. Les estimations sont détaillées
  4. Les estimations sont acceptées par les parties prenantes clés ET les membres de l’équipe d’équipes projet, en particulier ceux qui vont devoir les réaliser.
  5. Il y a une marge suffisante incorporée dans le plan.
  6. Nous avons mis en place des mécanismes adéquats de suivi des temps.
  7. Nous avons des lignes de bases bien établies et partagées.
  8. La complétude et l’accord de tous sur les estimations sont clés.

Question complémentaire que l’on pourrait vous poser…

time valueSur votre dernier projet, comment suiviez-vous et teniez-vous à jour les données réelles sur les temps passés et progrès réalisés par rapport aux prévisions ?

Soyez prêt à répondre même si ceux-ci ont été suivis dans un simple tableur et basés sur la saisie de données déclaratives de la part des membres de l’équipe.

Ceci est mieux que ce que j’ai pu observer sur bien des projets sur lesquels j’ai travaillé…

Qu’est-ce qu’une WBS (ou SDP), quand est-elle construite et que vérifiez-vous quand elle a été développée ?

Voici une question qui peut vous être posée en entretien pour un poste de Chef de projet ou de PMO.

Car-WBSLa « Work Breakdown Structure (WBS) » ou Structure de Découpage de Projet (SDP) en français est développée pendant la phase de planification. Elle décrit tout le travail qui doit être fait pour compléter le projet. C’est une décomposition orientée produit de toutes les tâches qui organise et définit le périmètre total du projet. Elle reflète aussi souvent la façon dont les coûts et le progrès du projet seront regroupés, sommés et rapportés. C’est une structure hiérarchique qui devient plus détaillée comme vous détaillez les tâches, attributions, durées, coûts, produits/livrables, dépendances et contraintes de votre projet.

1 tâche = 1 personne + 1 action + 1 livrable

Diagramme de Gantt affichant les différentes tâches et leur progrès
Diagramme de Gantt des différentes tâches de la WBS et de leur progrès

Ma recommandation personnelle en passant en revue une WBS en sus de sa complétude et de sa structure, est de vérifier qu’une tâche représente clairement une action  à réaliser par une personne pour produire un livrable afin que la responsabilité et ce qui est à réaliser soient 100% limpides. Je vérifie aussi que les durées de chaque tâche n’excèdent pas 2 semaines sur un projet de 12 mois pour faciliter un suivi de progrès régulier.

Pour davantage de détails (re)lisez:

votre message d’absence en anglais pour partir en toute sérénité !

Cette semaine, Christina Rebuffet nous propose une brève vidéo qui nous donne un modèle de message d’absence en anglais !

Partez en vacances l’esprit tranquille sachant que vos collègues étrangers (qui prennent peut-être moins de congés que nous…) n’attendront pas de réponse immédiate de votre part ! En 5 minutes vous serez prêt pour le départ…

N’oubliez pas: Il semble que ce ne soit jamais le bon moment pour que le chef de projet prenne des congés.

Cependant les vacances ne sont en rien facultatives et elles sont même absolument nécessaires.

vacances !!!

Comme les chefs de projet carburent souvent à 150 % de leurs capacités pendant des périodes prolongées, leur motivation et performance risquent for de montrer des signes de fatigue…

…alors, déculpabilisez, positionnez votre message d’absence et déconnectez (tout en continuant à suivre DantotsuPM pour le plaisir 🙂 bien sûr)

Bonnes vacances !!!

Question d’entretien PM et PMO: Que trouve-t-on dans un Plan de Management de Projet ?

Sans vouloir paraître trop bureaucratique et inflexible dans votre approche, ce document contient d’habitude:

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Une erreur clé serait de confondre l’échéancier, WBS/ Diagramme de Gantt avec Le Plan de Management de Projet car ceci pourrait dénoter un manque de maturité de votre part (le WBS est seulement une partie du PMP). Le Plan de management de Projet (PMP) décrit comment des sujets interconnectés seront gérés (risques, communications, approvisionnements, changements …). Sans oublier les parties prenantes et les communications.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Work Breakdown Structure (WBS) ou Structure de Découpage du Projet (SDP) par PMGS

WBS -Work Breakdown Structure ou Structure de Découpage

La WBS ou Structure de Découpage est une décomposition hiérarchique du contenu total du projet. Elle définit et organise les livrables du projet et supporte le chef de projet dans la planification de ses activités.

La WBS – Épine dorsale du projet

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Une WBS bien construite est la base du projet dans son ensemble. En effet, elle peut être la source de :

  • la définition du contenu de projet (livrables)
  • la planification
  • l’estimation des coûts et du budget
  • la délégation et l’allocation des ressources
  • la gestion des risques et de la qualité du projet
  • la communication avec toutes les parties prenantes du projet

Format de la WBS

La WBS peut prendre différentes formes. En effet, elle peut être construite sous forme de table ou être représentée en mapping hiérarchique.

WBS Standard Practice
Le PMI a publié un guide des meilleures pratiques dédiées au WBS disponible sur Amazon

Les règles de construction

La première règle fondamentale d’une WBS est qu’elle doit être composée uniquement de phases ou de livrables. Elle sera donc composée de NOMS et non de verbes ! Aucune activité ne doit être dans la WBS même.

Car-WBSUne règle très importante à respecter est la Règle des 100% qui peut être énoncée en deux points :

  • la WBS doit inclure 100% des livrables à fournir durant le projet
  • la WBs est construite de telle sorte que chaque niveau de décomposition contient 100% des livrables du niveau supérieur.

La WBS est aussi construite pour faciliter la communication avec les parties prenantes. Pensez donc à la construire avec elles et pour elles et prévoyez des niveaux intermédiaires simples et compréhensibles par tout le monde.

Enfin, sachez que votre WBS ne se construira pas en une seule session mais de manière itérative et progressive. Elle sera continuellement enrichie pendant la phase de planification et très certainement mise à jour suite à des changements pendant l’exécution de votre projet.

Pour avoir une idée d’un découpage vous pouvez télécharger notre modèle: Télécharger le template – PMGS WBS

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Précédents billets sur le sujet important des WBS

20 Novembre – Paris – Qu’est-ce qui freine l’exécution fluide de vos projets ? 1er atelier TOC France !

L’association TOC France (Theory Of Constraints) a le plaisir de vous convier le 20 novembre 2014 à son premier atelier

Les freins à l’exécution fluide des projets et comment obtenir un consensus sur ces freins ?

Toc FranceÊtes-vous insatisfaits d’avoir du mal à livrer vos projets complets dans les délais initiaux ? Vos projets sont-ils souvent en retard ? Vos clients en sont-ils insatisfaits ? Vos concurrents sont-ils plus fiables que vous ? Avez-vous du mal à tenir le budget de vos projets ? Vos équipes projet sont-elles stressées ?

Si vous répondez oui à l’une ou plusieurs de ces questions et aimeriez comprendre et éradiquer les causes de ces insatisfactions, sachez que la théorie des contraintes en a analysé les causes racines et propose une solution : le management de projet par la chaîne critique.

Comme il vaut mieux d’abord se mettre d’accord sur les causes des dysfonctionnements, TOC France vous propose un atelier de simulations (« serious games ») sur les pratiques qui freinent ou accélèrent l’exécution des projets. Nous explorerons les effets de la gestion des priorités entre tâches et ceux de la maîtrise de l’encours grâce à quelques simulations.

Eric Belpaire
Eric Belpaire

Ces simulations sont en général très appréciées : elles permettent de faire l’expérience des effets de certaines pratiques de l’approche traditionnelle et des bénéfices de l’approche chaîne critique.

Souvent, les participants les proposent ensuite à leurs collègues pour promouvoir les principes de la chaîne critique. Chaque simulation sera suivie d’un temps d’échanges où les participants tireront les leçons de la simulation : bénéfices et inconvénients, conséquences, pratiques à éviter ou à favoriser, façons de promouvoir ces leçons, etc.

Si la réussite de votre activité passe par celle de vos projets, que vous soyez déjà convaincu par le bon sens des principes de la chaîne critique ou curieux d’en savoir plus, venez participer à notre premier atelier « expérientiel » ! Si cet atelier satisfait les participants, d’autres suivront.

Directeur de projet, certifié par TOCICO en management de projet par la chaîne critique, Eric Belpaire animera cet atelier interactif.

 Date et lieu Jeudi 20 novembre 2014 de 18h00 à 20h00Bureaux de Marris ConsultingTour Montparnasse 27e étage – 33 avenue du Maine     75015 PARIS
Programme 18h00 – Accueil des participants18h15 – Présentation de l’association TOC France18h30 – Simulation sur la gestion des priorités entre tâches

19h00 – Simulation sur la maîtrise de l’encours

19h30 – Conclusion & échanges entre participants

20h00 – Fin de l’atelier

Pour s’inscrire   fr.amiando.com/ToCFr141120

Atelier limité aux 15 premiers inscrits

Participation aux frais Gratuits pour les membres, 10 € pour les non-membres.

 

Cubix360 est désormais distribué par Projects Partners

myAMS, éditeur du logiciel Cubix360 et partenaire de DantotsuPM, confie la distribution du produit à son partenaire, Projects Partners.

Projects Partners Cubix360Projects Partners est une société de services et d’ingénierie informatique (SSII) constituée d’une équipe de consultants, formateurs et développeurs qui offrent des prestations, des outils et des solutions informatiques pour le chiffrage performant et la réalisation maîtrisée et rentable de projets et chantiers.

Projects Partners va désormais prendre en charge la partie commerciale et marketing de Cubix360 . Ils animeront notamment les webinars à partir du 18 septembre 2014. Le site internet sera également pris en charge, et mis à jour régulièrement.

Pour toute information, contacter:

Visitez leur site: www.projects-partners.net

Partenaire de DantotsuPM
Partenaire de DantotsuPM

pourquoi un plan B est-il toujours nécessaire ?

Danny Hillis: The Internet could crash. We need a Plan B

« En ce moment, je pense qu’il est littéralement vrai que nous ne savons pas quelles seraient les conséquences d’une attaque de déni de service efficace sur Internet , et quelle qu’elle soit, elle sera pire l’année prochaine, et encore pire l’année suivante et ainsi de suite. 

Alors il nous faut un plan B. A l’heure actuelle, il n’y a pas de plan B.

Nous n’avons aucun système de sauvegarde clair que nous ayons soigneusement maintenu indépendant d’Internet, fait d’ensembles de blocs de construction complètement différents. Donc ce qu’il faut, c’est quelque chose qui n’a pas nécessairement besoin d’avoir la performance d’Internet, mais la police doit être en mesure d’appeler les pompiers même sans Internet, ou les hôpitaux doivent pouvoir commander du mazout. Pas besoin que ce soit un projet gouvernemental de plusieurs milliards de dollars.

C’est en fait relativement simple à faire, sur le plan technique, parce qu’il peut utiliser les fibres existantes qui sont dans le sol, les infrastructures sans fil existantes.

Il s’agit essentiellement de décider de le faire. »

Partenaire de DantotsuPM
Partenaire de DantotsuPM