un rapide aperçu de la Matrice de Structure de Dépendance (Dependency Structure Matrix: DSM)

A Quick Guide to Dependency Structure Matrix (DSM)

http://project-management.com/a-quick-guide-to-dependency-structure-matrix-dsm par Balaji Viswanathan

Microsoft Project
Partenaire de DantotsuPM

Introduction

Quand le projet grossit en taille, le nombre d’interactions et de dépendances grandit exponentiellement. Les tâches indépendantes sont moins nombreuses et la majorité des tâches deviennent plus dépendantes de l’achèvement d’autres tâches.

Par exemple, prenez le cas d’un lancement de nouveau produit. L’équipe de commercialisation doit produire son message et identifier les canaux sur lesquels le communiquer à son marché cible. L’équipe de développement doit finir le produit, l’équipe de test doit certifier la qualité du produit, les équipes de support doivent être prêtes à répondre à toutes les requêtes et l’équipe des relations presse doit être prête à fortement communiquer.

À un moment, il devient très difficile de gérer toutes les interdépendances qu’implique le lancement et il y a besoin d’une représentation élégante des dépendances du projet.

Voici où la Matrice de Structure de Dépendance (DSM) entre en jeu. La DSM est une matrice carrée utilisée pour représenter les dépendances de projet. Un coup d’œil rapide à la DSM devrait renseigner sur quelles tâches dépendent du ou des livrables d’une tâche donnée. Sa façon visuelle et compacte de représenter des systèmes complexes est un de ses plus grands avantages. La DSM est largement utilisée dans les projets d’ingénierie qui nécessitent des boucles de retour d’information et des dépendances cycliques.

Les industries comme le développement immobilier, la construction, l’aérospatiale, l’automobile et les semi-conducteurs utilisent activement la DSM pour leur management de projet.

Une matrice DSM typique

Laissez-nous prendre l’exemple du lancement de produit et construire une matrice de dépendance simple. Les lignes et les colonnes portent les tâches. Pour chaque cellule, nous inscrivons X si la tâche dans la colonne dépend de la tâche dans la ligne. Dans l’exemple ci-dessous, la sortie du communiqué de presse est dépendante du développement de livrables alors que le marketing sur les médias sociaux et le contrôle qualité dépendent seulement du développement de produits.

Une fois que nous construisons cette matrice nous pouvons voir que les lignes représentent les tâches qui ont un impact sur une tâche donnée et les colonnes représentent quelles tâches dépendent d’une tâche donnée. Ceci nous permet de planifier de façon plus efficace.

En construisant une matrice DSM bien pensée, nous pouvons utiliser des outils informatiques pour donner la priorité aux tâches dont les lignes portent le maximum « X”.

Sortie comm presse

Market.  Médias Sociaux

Dével. produit

Contrôle Qualité

Support client

Sortie comm presse

 

Market. Médias Sociaux

 X

Dével. produit

 X

 X

 X

 X

Contrôle Qualité

 

 X

Support client

 X

X

En résumé, quand la DSM est utilisée correctement, elle fournit une façon très compacte et visuelle de regarder les tâches et nous permet de réaliser une conduite de projet plus efficace.

6-9 May – New York – 9th Annual Conference PMI Scheduling Community of Practice

The PMI Scheduling Community of Practice (SCoP) is pleased to announce our 9th Annual Conference being held at the New York Marriott at the Brooklyn Bridge, NY, May 6-9, 2012. The only conference focused exclusively on Scheduling.

planning, jalons, datesAn exciting and informative 3-day conference and see how organizations everywhere are obtaining remarkable business value from Project Scheduling. Learn how worldwide organizations are advancing the techniques, practice and profession of Project Scheduling and establishing practice standards for the Project Management profession.

Main reasons to attend:

  • LEARN how other scheduling professionals develop baseline schedules, create Work Breakdown Structures, cost load schedules, and perform schedule risk management with over 50 different breakout sessions
  • EMPOWER yourself with essential ROI for your company by having the opportunity to participate in ask the scheduling experts sessions, town hall meetings and Scheduling Excellence Initiative Updates from the Best Practices Group
  • EARN up to 20 hours towards professional development units (PDUs) or continuing education credits for such certifications as PMI’s PMP & SP, AACEi’s PSP, CMAA’s CCM, etc.
  • EXPERIENCE state-of-the-art Scheduling Solutions in the Partner Pavilion
  • GROW your global network of scheduling resources and connect with professionals from various industries
  • LEARN about the new Scheduling Community of Practice
  • UNDERSTAND best practices in use by Schedulers from around the world
  • LEARN about new standards available for the growing Scheduling discipline

Scheduling Event

pourquoi les chefs de projet luttent-ils en permanence contre la loi universelle de la gravité ?

Lyssa Adkins est une chef de projet expérimentée, certifiée PMP, qui a mené des projets pendant 15 ans de manière « traditionnelle », basée sur les plans et l’exécution rigoureuse de ces plans avant de découvrir l’approche Agile.

EscaladeSelon son expérience, certaines choses dans notre environnement de travail sont aussi immuables que la loi de la gravité dans notre environnement physique :

  • Les besoins des clients changent
  • Ce que l’équipe est capable de faire n’est connue que d’elle-même et cette capacité évolue avec le temps.
  • L’environnement du projet évolue de manière imprévisible.
  • Il est impossible de prendre des engagements pour une autre personne et de s’attendre raisonnablement à ce que cette personne les respecte.

Hors, le problème est que la méthode traditionnelle de conduite de projet par la planification lutte en permanence contre ces lois naturelles alors que l’approche pratique d’Agile s’en accommode et en fait même une partie intégrante de la méthode.

Alors, comment adapter certains des principes fondamentaux de l’approche par les plans de la plupart des chefs de projet pour qu’ils puissent utiliser la réalité au lieu de la combattre ?

pourquoi attendre ?

Why wait? par Seth Godin

http://sethgodin.typepad.com/seths_blog/2011/09/why-wait.html

Qui se soucie de quand c’est dû ?

Si vous êtes sur le chemin critique, si quelqu’un attend votre contribution, délivrez maintenant.

Nous avons des délais impératifs (« deadlines ») pour une raison, mais le mot clé est « impératifs » (le « dead » de « deadlines »). Dans les faits, vous n’avez pas à attendre la fin du délai ni même de vous en approcher, en particulier si vous voulez accélérer des choses.

Trop souvent, nous nous trouvons entrain d’utiliser le délai comme le levier afin de surmonter notre crainte. Si vous vous reposez sur les dates butoirs pour vous dépasser, le projet en paye le prix.

Le biais est de ralentir parce qu’autrement le patron vous donnera tout simplement plus de travail à faire. Êtes-vous bloqués sur dichotomie entre eux et nous du travail en usine ?

Toutes choses considérées, la rapidité gagne.

PS: le défi avec être un initiateur de projets est que vous n’avez jamais, jamais fini.

 

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.

un guide de planification de sprint

A Guide to Sprint Planning de Derek Huether

http://thecriticalpath.info/2011/07/22/a-guide-to-sprint-planning

En réalisant une évaluation de Agile, l’autre jour, j’ai pris place dans une réunion de planification de sprint. Bien que nombreux soient  projets Agile qui en aient au début de chaque sprint, obtiennent-ils le meilleur du temps et des efforts investis ? En tant que partie intégrante du service fourni à mon client, je lui fournirai une petite antisèche pour la planification de sprint. Ce sera à la fois un guide et un ordre du jour, pour les aider à rester concentrés.

Qu’est-ce que la planification de Sprint (d’itération) ?

Le but de la réunion de planification de sprint est pour que l’équipe s’accorde à compléter un ensemble d’articles de plus forte valeur du «product backlog» (l’arriéré de produit ou liste des articles demandés pour un produit). Cet accord définit le contenu du sprint et est basé sur la vélocité ou la capacité de l’équipe et la longueur du sprint qui est limité dans le temps.

Qui le fait ?

scrum methodologie agileLa planification de sprint est un effort collaboratif impliquant :

  • ScrumMaster – Facilite la réunion
  • Propriétaire de Produit (Product Owner) – Présente le détail des items du product backlog et leurs critères d’acceptation
  • Équipe Agile – Définit les tâches et l’effort nécessaire pour accomplir l’engagement

Avant que vous ne commenciez

Avant de commencer nous ne devons assurer que :

  • Les items dans le product backlog ont été estimés par l’équipe qui leur a assigné une valeur de points d’histoire relative
  • Le product backlog est trié pour refléter les priorités du Product Owner
  • Il y a une compréhension générale des critères d’acceptation pour ces items

Les Backlogs

Le product backlog peut adresser aussi bien une nouvelle fonction que des corrections à une fonctionnalité existante. Pour la planification de sprint, les items du product backlog doivent être assez petits pour être achevés dans le sprint et que l’on puisse vérifier qu’ils ont été implémentés correctement. Cette liste d’item du product backlog deviendra le sprint backlog.

Bien calibrer les items du backlog

Les items de product backlog trop grands pour être complétés dans un sprint doivent être divisés en morceaux plus petits. La meilleure façon de les diviser est de se baser sur leur valeur et non pas sur le processus.

Plan basé sur la capacité

Des équipes matures peuvent utiliser la vélocité pour déterminer sur quels items du product backlog s’engager pour le sprint. Des équipes récentes ne peuvent pas connaître leur vélocité ou celle-ci peut ne pas être suffisamment stable pour l’utiliser comme une base de calcul dans la planification du sprint. Une approche pour de nouvelles équipes est de prendre des engagements basés sur la capacité de l’équipe.

Détermination de la capacité

La capacité d’une équipe est tirée de trois mesures simples pour chaque membre de l’équipe :

  • Nombre d’heures idéales dans un jour ouvrable
  • Nombre de jours pendant le sprint où la personne sera disponible
  • Le pourcentage de temps que la personne dédiera à cette équipe

Les étapes de planification

  1. Le Product Owner décrit l’item du product backlog de plus forte valeur
  2. L’équipe détermine les tâches nécessaires de compléter cet item du product baclog
  3. Les membres de l’équipe se portent volontaire pour être propriétaire de certaines tâches
  4. Les propriétaires de tâche évaluent les heures dont ils ont idéalement besoin pour réaliser leur tâche
  5. La planification continue tant que l’équipe peut s’engager à délivrer sans excéder sa capacité
le site de microsoft projet en français
Partenaire de DantotsuPM

le saviez-vous ? Il est possible de comparer 2 plans MS Project très facilement par Vincent Capitaine

Merci à Vincent Capitaine qui nous donne un truc utile pour tous les chefs de projet qui utilisent MS Project 2010.

En tant que chefs de projets, nous imaginons souvent plusieurs scénarios pour planifier nos projets. En créant un fichier MS Project par scénario par exemple, nous pouvons ensuite facilement comparer ces versions du planning tout comme nous comparerions plusieurs versions d’un document Word afin d’en comprendre les différences.

Visuellement, le diagramme de Gantt va indiquer les différence avec des couleurs différentes par scénario et il sera aussi possible de comparer l’impact sur les ressources du projet.

Lisez le billet de Vincent qui nous donne tous les détails.

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

nivellement de ressources dans un mode « excel like » grâce aux vues d’utilisations

Publié par Équipe PCO DexterIT sur leur blog.

La fonctionnalité de nivellement automatique de ressources de MS Project peut, malgré sa puissance, entraîner sur votre plan des modifications dont il est difficile de comprendre les impacts, surtout lorsque le plan est complexe.

Voici une méthode qui vous permet de faire un nivellement manuel des ressources grâce aux vues « excel-like » d’utilisation.

La vue d’utilisation des ressources permet de visualiser les tâches affectées à chaque ressource. La partie de droite de votre écran présente un tableur dont on peut changer l’échelle (jour, semaine, mois) pour changer la valeur du travail.

lire les détails sur le blog dexerit

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

les chemins critiques dans MS Project par un pro

Vincent Capitaine, Consultant Senior – Management de projet et de portefeuille – MCTS, MCITP & Microsoft Project MVP, nous propose sur son blog un article sur la gestion des tâches critiques et des chemins critiques dans Microsoft Project.

Vous y apprendrez, si (comme moi-même) vous ne le saviez pas encore, qu’ il est possible dans l’outil d’afficher le chemin critique de chaque sous-projet et non seulement le chemin critique global grâce à l’option « Calculer les chemins critiques multiples ».

Ou encore de mettre en place votre propre définition de ce qu’est une tâche critique en fonction par exemple de la marge disponible sur une tâche. L’option « Tâches critiques si la marge est inférieure ou égale à x jours » permet en effet de considérer comme critiques des tâches qui ont une marge libre inférieure au nombre de jours que vous fixez (0 jour est le défaut).

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

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

pourquoi des projets sont-ils 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 avec 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 déclare que :

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

N’oublions pas que beaucoup de secteurs ont un rythme naturel. Un exemple est 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 Kydler pour le stockage sur disque (~12 mois) et la Loi d’Haitz pour la production de LED’s (~18 mois).

Pourquoi y-a-t-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 derrière moi les projets que j’ai managés dans ma carrière, le cycle de 18 mois d’annulation des projets réapparaît à travers les industries, le contexte, la technologie, la taille d’organisation et les nationalités. La règle semble universelle. Pourquoi ? Dix-huit est le nombre maximal de mois pendant lesquels le management peut souffrir. La douleur est la répétition de re-justification d’un projet dont on attend toujours les bénéfices.

Pourquoi est-ce 18 et pas 12 ou 24 ?

Pensez à 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 l’impact potentiels. Quand le cycle budgétaire suivant arrive, le projet est bien en route et le financement est presque assuré étant donné que 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. Le résultat est que les ressources sont maintenues en place et le projet continue à progresser.

Le deuxième cycle est une question différente. Quand le cycle budgétaire revient, il y a des questions levées sur le projet : est-ce que ce projet est toujours important ? Y aurait-il des projets plus importants que nous devrions financer au lieu de celui-là ? Atteignons-nous les progrès escomptés ?

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 simplement laisser le projet mourir et éviter cette douleur. Comme nous pouvons tous l’apprécier, éviter la douleur est une réaction humaine naturelle.

douleurSi le management pouvait voir la valeur (quelque chose qui justifie la douleur), 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 l’obtenir 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 de plusieurs années et que les bénéfices viendraient à la fin. Est-ce que ceci ne prouve 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 douleur grandit avec chaque cycle ultérieur. Ce qui signifie que vous devez montrer une valeur et un impact toujours croissants pour continuer. La douleur ne part pas. En réalité, elle augmente .

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

Comment une équipe évite-t-elle la règle ? Par les quelques étapes simples suivantes :

Remettre les horloges à zéro1) 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 produits 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 ? Esquiver le problème d’évitement d’une douleur qui s’intensifie avec le temps. Chaque projet remet l’horloge à zéro.

Dans mon expérience, j’ai vu la règle appliquée à des projets qui devraient avoir été tués au départ et à d’autres qui n’auraient jamais dus être tués. Cette apparente prise de décisions 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 les stratégies de management de projet simples afin d’éviter ce que dans le passé vous aviez attribué à des caprices du management.

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

Bonne chance !

de beaux calendriers sous Excel

Vous trouverez sur Excel Downloads un fichier Excel présentant 4 calendriers dynamiques réalisés avec Excel par Daniel Demilly. Tous soignés et gratuits.

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

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:

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

PMP Exam Tip: The Work Breakdown Structure (WBS)

Posté par Cornelius Fichtner

Work Breakdown StructureUne Structure de Découpage du Projet (Work Breakdown Structure : WBS) dans le management de projet et l’ingénierie de systèmes, est un outil utilisé pour définir et grouper les lots de travail individuels d’un projet d’une manière qui aide à organiser et définir le contenu du travail total du projet. Un élément de structure découpage du projet peut être un produit, des données, un service, ou n’importe quelle combinaison. Un WBS fournit aussi la structure nécessaire pour l’évaluation de coût détaillée et le contrôle avec des conseils pour le développement et le contrôle de l’échéancier. De plus le WBS est un outil dynamique et peut être révisé et mis à jour autant que nécessaire par le chef de projet.

Un des principes de conception de Structure de Découpage du Projet les plus importants est appelé la Règle des 100 %. Cette Règle établit que le WBS inclut 100 % du travail défini dans le périmètre du projet et capture tous les livrables – internes, externes, provisoires – en termes de travail à réaliser, y compris le management de projet. La règle des 100 % est un des principes les plus importants guidant le développement, la décomposition et l’évaluation du WBS. La règle s’applique à tous les niveaux de la hiérarchie : la somme du travail au niveau « des enfants » d’une tâche doit égaler 100 % du travail de la tâche « parent » et le WBS ne devrait pas inclure de travail externe au périmètre réel du projet, c’est-à-dire qu’il ne peut pas inclure plus de 100 % du travail. En même temps, il ne peut pas en contenir seulement 95 %. Il doit contenir 100 % du travail. Cela s’applique au niveau de l’activité. Le travail représenté par les activités de chaque lot de travail doit s’élever à 100 % du travail nécessaire pour compléter le lot de travail.

La 4ème Édition du guide PMBOK déclare que créer le WBS est le processus de subdiviser des livrables de projet et le travail de projet en des composants plus petits, plus faciles à manager. Le WBS est une décomposition hiérarchique orientée à réaliser par l’équipe projet pour accomplir les objectifs du projet et créer les produits requis, avec à chaque niveau plus bas du WBS la représentation d’une définition de plus en plus détaillée du travail du projet. Le WBS organise et définit le contenu total du projet et représente le travail indiqué dans le document approuvé de déclaration de portée du projet. Le travail planifié est contenu au niveau le plus bas WBS des composants, qui sont appelés des lots de travail. Un lot de travail peut être planifié, estimé en coûts, surveillé et contrôlé. Dans le contexte du WBS, le travail se réfère aux livrables de travail ou aux produits qui sont le résultat de l’effort et pas à l’effort lui-même.

Lisez en davantage sur le WBS dans le PMBOK en commençant par la section 5.3.

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

les réunions de démarrage de Projet

Project Kickoff Meetings de Philip Diab

project launch kickoff lancement projetBien démarrer le projet donne le ton pour tout le projet et positionne souvent l’équipe pour la réussite. Même si cela ne peut pas garantir le succès, avoir un mauvais démarrage de projet est dans la plupart des cas un premier signe d’alarme que le projet se dirige droit dans le fossé. L’événement le plus important pendant le processus d’initiation est la réunion de démarrage/de lancement. C’est cette rencontre entre l’équipe et les parties prenantes qui lance officiellement le projet. Cela pourrait bien être la réunion la plus importante parce que c’est souvent un test du chef de projet et de l’équipe par l’organisation pour voir si chacun est bien en place ou non.

Les bénéfices de la réunion de démarrage incluent :

  • Affirmation de l’appui du sponsor exécutif et des leaders seniors aux objectifs du projet.
  • L’explication de l’autorité et de la responsabilité du chef de projet à l’organisation pour obtenir l’appui et demander la coopération.
  • Une occasion pour l’équipe de se réunir sous la bannière du projet.
  • Donner les attentes des parties prenantes et de l’organisation quant à ce qui est couvert ou pas dans le périmètre du projet.
  • Recevoir les réactions sur toute omission dans les bénéfices potentiels du projet et commencer à construire/raffiner les exigences.

Il est important dans cette partie du processus de planification que le chef de projet travaille avec les parties prenantes pour assurer leur bonne représentation pendant la réunion.

Les participants à la session de démarrage devraient inclure :

  • Le sponsor exécutif et le chef de projet
  • Membres clefs du comité de direction
  • Tous les membres de l’équipe projet
  • Les représentants de l’organisation du client (interne ou externe)
  • Les représentants d’autres leaders de projets qui pourraient interagir avec ce projet (dans le cas d’un programme)

Puisque c’est la première occasion pour le chef de projet de démontrer sa force et ses compétences, il est important pour le PM de bien mener/faciliter cet événement. Cependant, pour que cette activité soit perçue positivement, le PM doit passer du temps avant la réunion pour la préparer.

Voici quelques suggestions pour aider le PM à bien se préparer pour l’événement et mener une réunion efficace :

  • commentairesLa préparation d’une présentation qui est partagée avec les participants décrivant le « business case » pour le projet et la description de la portée à un haut niveau.
  • Discussion avec les membres de l’équipe des responsabilités et partager cette information pendant la réunion.
  • Mettre l’accent sur les éléments clefs de la charte de projet ou de la déclaration de travail ou du contrat client. Cela peut inclure des processus comme l’approbation de livrable ou le contrôle des modifications.
  • Discussion sur la terminologie pour parvenir à un accord sur un jeu de définitions communes.
  • Établir et/ou revoir les règles de vie d’équipe pour donner des attentes appropriées.
  • Fournir les détails de contact pour des parties prenantes clefs et exposer les étapes suivantes.
  • Détailler la suite proposée dans le processus et mettre en évidence les événements marquants prévus ou jalons pour le projet et s’assurer que chacun comprend ce qui arrivera ensuite.
  • L’identification d’une personne qui servira de preneur de notes de réunion pendant la session (autre que le PM) pour que les questions business, décisions et problèmes soient capturés.
  • La revue des éléments clefs du produit/service à livrer sur le projet afin de déterminer s’il y a bien une compréhension commune.
  • La conduite d’une session de « Team Building » si le temps permet et/ou si c’est approprié.

Une fois que l’on conclut la réunion avec succès, le processus de la réunion de démarrage n’est pas fini.

Il y a des activités de suivi que le PM et l’équipe doivent adresser pour assurer que la crédibilité se poursuive :

  • à retenirRevoir et distribuer les notes de la rencontre de démarrage incluant les points d’action.
  • Ajuster les composants clefs de la portée si certains ont été identifiés et mettre à jour la charte s’ils ont été agréés.
  • Communiquer sur le lancement du projet aux personnes non présentes ou non invitées à cette réunion.
  • Lancer une vérification de la portée détaillée et des sessions de validation des objectifs pour commencer la planification.
  • Documenter les modes opératoires et règles de vie avec l’équipe.
  • Communiquer les responsabilités convenues pour les divers membres d’équipe et parties prenantes.
  • Mettre à jour la documentation officielle comme la charte, SOW, etc …

Comme je l’ai mentionné, il n’y a peut-être aucune réunion plus importante que celle de lancement dans la vie du projet. Je m’en rappelle une, dans une organisation que j’ai rejointe, où le chef de projet est arrivé en retard et a quitté la réunion pendant 15 minutes pour faire les copies de l’ordre du jour (qu’il aurait du avoir au départ). Comme vous pouvez l’imaginer, cette réunion était peut-être la meilleure réunion de l’équipe projet qui a ensuite poursuivi sa descente aux enfers. Le projet ne s’est pas bien terminé.

Je suis sûr qu’il y a d’autres trucs que les praticiens ont relevé pendant leurs réunions de démarrage, donc merci de vos commentaires.

CSP Formation
Partenaire de DantotsuPM