comprendre les thèmes PRINCE2

Getting to grips with Prince2 themes

thèmes Prince2http://blog.prince2.com/2012/07/getting-to-grips-with-prince2-themes sur PRINCE2.com Blog

Tout un chacun peut avoir une idée brillante pour un produit ou un service. Le truc est de vous assurer que vous suivez les bonnes étapes pour transformer l’idée en réalité. Les thèmes PRINCE2 vous aident à le faire. Ils représentent les sept aspects critiques de management de projet qui, pris en compte et considérés partout dans le projet, en feront un succès.

1. Êtes-vous sur l’affaire ?

Vous avez une grande idée, mais comment savez-vous qu’elle paiera ? Le cas d’affaires, le « business case », vous permet d’équilibrer les bénéfices attendus avec les risques et les coûts estimés. Tant que les bénéfices dépassent coûts et risques, vous continuez avec le projet. Quand ils ne le font pas, vous arrêtez le projet. Voici un exemple simplifié : imaginez que vous avez décidé de réaliser X dans un an parce qu’il aboutira à Y. Vous avez regardé les risques et les coûts et ils semblent acceptables. Imaginez maintenant que vous êtes cinq ans et des milliers de dollars ou d’euros plus tard et, bien que vous n’ayez pas toujours X opérationnel, le projet avance en trébuchant. Et bien, si vous aviez seulement soumis votre idée à la rigueur du cas d’affaires PRINCE2, cela aurait réduit les chances de cette tournure d’événements.

2. Qui fait quoi ?

QRP International France
Partenaire de DantotsuPM

Avez-vous jamais organisé un événement où chacun pensait que quelqu’un d’autre était responsable et que quelqu’un d’autre faisait ce qui être fait pour qu’à la fin rien n’ait été fait ? Si seulement chacun avait su comment utiliser PRINCE2. En termes très simples, le thème Organisation permet de s’assurer que les gens connaissent leurs rôles (rôles pas job, parce que les rôles peuvent être partagés et combinés) et savent à qui il reporte. En fait, il s’assure que certaines personnes dirigent, certaines managent et certaines livreront un projet. Résultat? Absolument!

3. Cela répond-il aux attentes ?

Nous avons tous acheté quelque chose avec des caractéristiques et des résultats spécifiques promis et ensuite quand nous contemplons ce que nous avons reçu, ce n’est pas en accord avec nos attentes. PRINCE2 peut s’assurer que votre client ne subit pas de telles déceptions. La qualité est un thème clé de PRINCE2 qui peut s’appliquer à un produit, une personne, un processus, un service et/ou un système. En utilisant la méthodologie, vous pouvez être clairs sur ce que le client veut, que ce que vous et le client avez accepté sera acceptable, sur comment atteindre le résultat requis, sur ce que devrait être dans la description de produit et, vous pouvez aussi créer un registre de qualité qui récapitule les activités de qualité planifiées et complétées.

4. Quel est le plan ?

Microsoft Project
Partenaire de DantotsuPM

Nous utilisons tous des plans chaque jour, qu ce soit pour planifier notre journée, planifier comment faire quelque chose ou planifier comment aller quelque part. Le business n’est pas différent. La beauté de PRINCE2 consiste en ce que son thème Plans rend la planification d’un projet effective et efficace. Simplement dit, son approche de planification à base de produit/livrable dit à chacun qui est impliqué ce qui est exigé, comment cela sera réalisé, qui le réalisera, ce qu’ils utiliseront, quand les choses arriveront et si vous pouvez produire le livrable selon les paramètres impartis.

5. Quel genre de pari est-ce?

Si nous planifions un barbecue en été il y a un risque qu’il pleuve et d’arrêter l’événement; si nous construisons quelque chose qu’il y a un risque que notre fournisseur d’un composant ne livre pas à l’heure. Le risque est tout autour de nous et cela peut être positif et négatif. Le but avec le thème Risque de PRINCE2, est de le manager selon des étapes comme avoir une stratégie, un registre de menaces et d’opportunités et une procédure de management des risques.

6. Tout change ?

Vous avez créé un produit et avez tout bien fait et ensuite, le croirez-vous, quelqu’un décide qu’il veut changer l’emballage. Eh bien, peut-être le croiriez-vous. Les projets, comme la vie, sont sujets au changement. Tout que vous pouvez faire est manager le changement. L’utilisation d’une approche systématique et commune du thème de Changement de PRINCE2 permet d’identifier, localiser et contrôler des changements inattendus ou attendus par rapport aux lignes des références établies pour les livrables. (Vous avez besoin de lignes de référence, sinon vous ne saurez pas quel est le changement.)

7. Progressons-nous?

Ceci est en quelque sorte une évidence. Après tout, à quoi bon nous féliciter de nos accomplissements si ceux-ci ne répondent pas aux besoins du projet. Ainsi, le thème de Progrès PRINCE2 vous aide à garder un œil vigilant sur comment les choses avancent. Il implique le contrôle et la comparaison du réalisé avec les résultats planifiés, fournissant une prévision des objectifs et de la viabilité du projet et implique le contrôle de tout écart inacceptable. Les sortes de choses que l’on regarde sont les coûts , les délais et la qualité et celles-ci permettent alors des décisions informées comme s’il faut arrêter un projet en cours.

Partenaire de DantotsuPM

Session de revue du Parlement Britannique en Juillet 2007 sur les Jeux de Londres 2012 par Vincent Coustillac

Les Jeux Olympiques de Londres 2012 – Project Management

Introduction d’une série d’articles sur le thème du Project Management tel que pratiqué pour les Jeux Olympiques de Londres 2012.

Session de revue du Parlement Britannique en Juillet 2007

Vincent Coustillac
Vincent Coustillac

Mon intention est de proposer une série d’articles couvrant les pratiques de projet et programme management utilisées lors de l’organisation des Jeux Olympiques. Je  présente pour ce premier de la série un document révélateur de l’approche utilisée par les organisateurs et le Gouvernement Britannique pour faire face au challenge incommensurable que représente l’organisation des Jeux Olympiques.

Il ne fait aucun doute que l’organisation des Jeux Olympiques de Londres 2012 fut un succès sans précédent, et je pense que nombreux sont les professionnels du management de projet qui comme moi sont fascinés par de tels projets, se demandant quelles pratiques de management de projet ont dû être mises en place pour un tel résultat.

Ce sujet a déjà été proposé dans DantotsuPM.com – voir l’article posté le 2 Aout : JOs 2012 – “A learning legacy” en matière de management de projet et de programme . La série d’articles que je propose prendra sa source dans cette référence qui fournit de nombreux exemples de pratiques professionnelles de management de projet, et place le management de projet au sommet des préoccupations des organisations en charge de ce projet « pharaonique ». Ces articles constitueront une sorte de « reader’s digest » sur le sujet et mettront l’accent sur les pratiques de management de projets et programmes dans le cas précis des JOs 2012.

Session de revue du Parlement Britannique en Juillet 2007

jeux olympiques de Londres 2012Pour ce premier article, je fais référence au document « Preparations for the London 2012 Olympic and Paralympic Games – Risk assessment and management »

Ce document est la propriété du Parlement Britannique – « House of Commons ». Il a ceci de passionnant qu’il montre la réaction du comité parlementaire (Committee of Public Accounts ) en réalisant que le projet n’était pas sur la meilleure voie pour atteindre son objectif, en mettant en évidence l’analyse des risques du projet et les décisions prises.

Il donne une bonne démonstration que la mise en place de pratiques de management de projet est nécessaire au succès d’un évènement de cette ampleur même si ce n’est évidemment pas suffisant. Le fait que cet effort d’analyse ait été fait au moins 5 ans avant l’échéance des JOs (et seulement 20 mois après l’annonce officielle du choix de Londres pour les JOs 2012), ainsi que les actions correctives énoncées dans ce document sont une preuve de plus que le management de projet a été mis en bonne place dans les méthodes de management de ce projet qui engage la responsabilité du gouvernement britannique.

Le document en référence compte 49 pages. Cependant seulement les pages 3 à 7 donnent le cœur de la discussion avec les constatations et les actions correctives qui font l’objet de l’analyse que je donne en dessous. Les pages 9 à 19 donnent le développement des arguments.

Le reste fournit les minutes des discussions parlementaires, mais n’en demeure pas moins passionnant car on peut suivre les discussions dans leur détail.

La suite de cet article propose un certain nombre d’éléments que je qualifie de bonnes pratiques de management de projet, mais ne constituent pas bien-sûr une liste exhaustive de pratiques à extraire de ce document.

Avant cela, quelques mots sur le contexte du projet :

  • Bien évidemment, ce projet comprend une date de livraison fixe, sans possibilité de négociation – comme mentionné dans le document. S’il apparaît que l’objectif ne peut être atteint, les seuls éléments pouvant faire l’objet d’une déviation, sont la réduction de la qualité et l’augmentation des coûts
  • L’organisation globale est très complexe. (On peut s’y attendre – voir les détails en page 9 du document). Outre les organisations gouvernementales (dont le « Department for Culture, Media and Sport »), l’exécution du projet revient à 2 groupes clés :
    • Le LOCOG (London Organising Committee of the Olympic Games and Paralympic Games), responsable de la gestion opérationnelle et le déroulement des Jeux
    • Olympic Delivery Authority (ODA), responsable de l’infrastructure et de la construction des nouveaux sites. Le consortium CLM (entité privée) apporte un support en management de programme.

Les bonnes pratiques que je retiens de ce document :

1. En premier lieu, le comité a ordonné un audit du projet, comprenant une analyse des risques suffisamment en amont dans le cycle du projet.

2. La première action couvre l’établissement de la gouvernance globale du projet, avec des rôles et responsabilités clairs :

Olympic delivery structures

  • L’équipe gouvernementale dirigeante des Jeux (appartenant au ‘Department  for Culture, Media and Sport’), avec le Board Olympique, contrôlent les 2 acteurs principaux (le LOCOG et l’ODA) en assurant une coordination avec les services gouvernementaux, et prennent en compte leurs conseils. « L’efficacité de la pléthore des organismes impliqués sera conditionnée par le fait que les projets individuels et le programme progressent comme prévu ».
  • Le Department, l’ODA et le LOCOG doivent identifier les fonctions essentielles à la réussite des Jeux, indiquer les compétences requises pour ces fonctions, et élaborer des stratégies pour retenir les individus, les connaissances et les compétences pour la durée du projet olympique. « La continuité des personnes clés sur les grands projets est la clé de la réussite »

3. Une action consiste à faire face à la date de livraison fixe et non négociable :

  • L’ODA (responsable des infrastructures) devra établir des accords d’incitation avec leurs sous-traitants qui traitent spécifiquement des risques accrus de dépassements des coûts et des insuffisances de qualité.

4. Le contrôle des coûts et l’établissement des budgets prévisionnels seront renforcés, en établissant des règles plus strictes sur la globalité des coûts et des revenus des Jeux.

5. Mise en place de pratiques de sous-traitances et achats efficaces. Les processus mis en place par l’ODA semblent être satisfaisant, cependant le contrôle des partenaires et des achats devra être rigoureux. Le LOCOG devra mettre en place une politique rigoureuse des achats et de sous-traitance dès le début de l’année 2009.

6. L’accent est mis sur la réutilisation des infrastructures après les Jeux. Ce point ne semble pas assez clair au moment de l’analyse et n’atteint pas le degré de satisfaction escompté. Un plan détaillé incluant les bénéfices à long terme des équipements devra être fourni au plus vite.

7. Mise en place du contrôle des progrès et des risques. L’accent est mis sur ce point qui n’est pas satisfaisant pour le moment. Pour le programme dans son ensemble, intégrant 42 sous-objectifs assignés à 17 organisations, le Department devra élaborer un système de reporting  des progrès et des risques en temps réel, et qui fournit un avertissement précoce des difficultés potentielles. Ce système devra être intégré dans chaque organisation.

J’espère vous avoir donné envie de lire ce document, que j’ai trouvé passionnant, notamment le détail des discussions de la commission d’audit.

Vincent Coustillac – PMI France-sud- PMP

concours « Build Your Island »: étudiants, testez vos talents de chef de projet et partez en voyage !

Microsoft Project
Partenaire de DantotsuPM

Microsoft et Teamsquare reconduisent cette année le concours « Build Your Island » destiné aux étudiants.

Comme plus de 500 étudiants s’y sont essayés l’an dernier, c’est l’opportunité de rejoindre la communauté « Build Your Island » et de tester ses talents de chef de projet.

A la clé, un voyage de rêve pour l’équipe gagnante!

Build your Island
Cliquez pour vous inscrire à ce concours

vous ne pouvez pas gagner en perspective depuis le fond des tranchées

You Can’t Gain Perspective From Inside the Trenches

http://themanagersdiary.com/2012/02/05/you-cant-gain-perspective-from-inside-the-trenches.aspx

« Faites suivre l’action efficace de calme réflexion. De cette calme réflexion viendra encore plus d’efficacité dans l’action. » Peter Drucker

« L’expérience n’est pas le meilleur professeur; l’expérience justement évaluée est le meilleur professeur. » – John Maxwell

Petite Bannière CSP
Partenaire de DantotsuPM

Tout manager qui mérite ce titre sait quelle métrique il observe au quotidien et heure par heure. Il sait quels rajustements faire en réponse à ce qu’il voit. Il a un plan établi et qui lui montre où il en est sur leur chemin vers son objectif. Il a mis en place son plan de contingence.

Mais dans le feu de l’action, sur le chemin au succès, il est important de prendre du recul et de réévaluer des choses. Cependant, pour la plupart d’entre nous, c’est beaucoup plus difficile qu’il n’y paraît initialement. Vous ne pouvez pas simplement le décider au cours d’un déjeuner. Je recommande que vous passiez un week-end agréable et rassembliez tout le monde lundi matin avant que d’être pris dans le travail de la semaine. Cela vous donne deux ou trois jours ainsi qu’à votre équipe de management pour clarifier vos esprits et aborder le planning et la performance cible en étant frais. Alors, que devriez-vous revoir ?

Commencez par l’image d’ensemble puis allez vers une analyse en profondeur :

  • Vos objectifs ou projets sont-ils toujours valables ? Devriez-vous aller vers autre chose ?
  • Progressez-vous vers vos objectifs, ou avez-vous atteint les jalons de votre plan ?
  • Y a-t-il quelque chose plus que vous devriez faire pour maximiser la performance, ou bien accélérer ou améliorer l’impact du projet ?
  • Mesurez-vous les bonnes choses ?

optimiser la voilureÀ quelle fréquence devriez-vous faire ceci ? Je dirais que mensuellement est un bon début, selon le projet et vos besoins de performance. Au strict minimum, une fois par trimestre.

Ce sont ces sortes de contrôles d’état d’avancement qui vous assureront que vous ajustez les voiles de votre bateau pour vous déplacer aussi rapidement que possible vers votre destination.

« Le pessimiste se plaint du vent. L’optimiste s’attend à ce qu’il change. Le Leader ajuste les voiles.  » John C. Maxwell

pas de vacances pour les chefs de projet ? Très mauvaise idée !

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. Elles sont absolument nécessaires. 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…

à quoi ressemble un bon WBS (Structure de découpage des taches / SDT) ?

What Does A Good WBS Look Like?

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

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

Mutuellement Exclusif

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

Collectivement Exhaustif

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

La figure suivante représente un projet.
WBS 3D de Jean-Yves Moine. Cliquez sur l’image pour lire l’article.

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

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

Auto-évaluez gratuitement votre Projet ERP avec Jean-Louis Tomas et son outil gratuit

Auto-évaluez gratuitement votre Projet ERP

Vous vous posez des questions sur votre Projet ERP ?  Jean-Louis vous propose de rechercher ensemble des réponses optimisées pour votre environnement à travers une approche radicale en 3 étapes :

  1. Évaluez vous-même en ligne, interactivement et gratuitement votre Projet ERP grâce à un outil indépendant des éditeurs et des intégrateurs : Auto-évaluez votre Projet ERP
  2. Définissez les actions correctives prioritaires grâce à 85 fiches pratiques recensant les meilleures pratiques collectées sur plusieurs centaines de Projets ERP : Maîtrisez votre Projet ERP
  3.  Mettez enfin en place les actions correctives personnalisées à votre propre environnement avec l’aide du Consultant, auteur de cet outil et de cette étude :  Organisez une session de travail

Jean-Louis se tient à votre disposition si vous aviez besoin d’un échange plus personnalisé sur vos problématiques spécifiques.

contacter Jean-Louis Tomas

à quoi ressemble un bon WBS?

What Does A Good WBS Look Like?

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

Microsoft Project
Partenaire de DantotsuPM

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

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

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

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

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

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

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