Archives de Tag: planning

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

13 mar

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é ?

7 mar

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 ?

5 mar

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.

 

8 raisons pour lesquelles les estimations sont trop faibles

23 fév

8 Reasons Why the Estimates Are Too Low

http://www.pmhut.com/8-reasons-why-the-estimates-are-too-low

Par Jens Schauder

Une des tâches les plus difficiles dans un projet de développement logiciel est d’évaluer la taille du projet. Malheureusement, le plus souvent, vous devez le faire au début même du projet, alors que vous avez le moins d’informations. Le résultat à la fin est très souvent une différence très significative entre l’estimation originale et le temps et l’argent réellement nécessaires.

Si la différence est aussi souvent positive que négative c’est en quelque sorte “acceptable”. Mais dans certaines équipes, les estimations sont systématiquement trop faibles !

La stratégie évidente et souvent employée est d’ajouter un certain pourcentage à l’évaluation de l’équipe. Mais bien sûr, ceci n’adresse que les symptômes, parce que la plupart du temps personne n’en connaît la raison. Aussi, dans cet article, je vais vous présenter plusieurs raisons pour de mauvaises évaluations, comment les identifier et aussi comment si possible les éliminer.

Voici les sortes de raisons que j’ai identifiées à ce jour :

  1. Super HéroLes estimations des super héros : Souvent les évaluations sont faites par un développeur très expérimenté (le Super Héros). Quand il évalue une tâche il s’imagine la réalisant. Mais, bien que l’évaluation puisse être correcte pour le Super Héros, elle pourrait ne pas fonctionner pour des développeurs dans la moyenne. Et, comme ils ne sont pas des Super Héros, il leur faudra plus de temps.

Vous pouvez identifier cette sorte de situation en laissant des personnes différentes réaliser les estimations, en incluant des développeurs moyens. Si l’évaluation du Super Héros est constamment au-dessous de celles des autres, la correction devient évidente : Utilisez l’estimation des autres développeurs. Mais n’excluez pas le Super Héros des évaluations. Ces développeurs expérimentés sont très bons pour identifier les choses que d’autres auraient tendance à oublier.

  1. Mauvaise Équipe : Cette raison est semblable à la situation des estimations de Super Héros dans laquelle l’évaluation n’est correcte que pour une équipe de bons (voire excellents) développeurs. Elle en diffère cependant, parce que dans ce scénario, pour une raison ou pour une autre, le projet est pourvu en personnel avec une équipe différente de celle escomptée au départ. Peut-être avec des développeurs moins brillants, ou peut-être simplement une équipe qui ne connaît pas bien le domaine, la structure ou le langage de programmation.

Héros junior...Pour identifier cette situation, parlez avec les personnes réalisant les évaluations. Laissez-les expliciter les suppositions qu’ils ont faites quand ils ont préparé l’évaluation et comparez les à ce qui se produit sur dans le projet dans réalité.

Si c’est le problème vous avez deux options : la première est d’arrêter ce changement d’équipes. Mais cela ne marche pas la plupart du temps, parce que vous ne les changez pas juste pour le plaisir, n’est-ce pas ? Donc il vous reste la deuxième option : Même quand vous planifiez d’utiliser votre équipe de champions, faites les évaluations en supposant qu’une équipe moyenne doive réaliser le travail. Soyez honnête sur ce qu’est une équipe moyenne.

  1. Faire des suppositions dans le noir : Souvent les informations disponibles sur le projet ne sont suffisantes pour une évaluation fiable. Seule une vague description est disponible.

Pour identifier cela comme le problème sous-jacent, décomposez le projet en tâches, que vous évaluez. Pour chaque tâche inscrivez les suppositions que vous avez faites : quelle technologie sera utilisée, quelle est la complexité de la logique à implémenter. Pendant le projet, vérifiez si vos suppositions tiennent la route ou s’il y a beaucoup de changements. C’est aussi une grande partie de la solution au problème. Faites de la description de votre supposition une partie de votre évaluation. Si les suppositions sont fausses, le client peut les corriger, aboutissant à une nouvelle estimation plus fiable. S’il change d’avis plus tard, vous avez une base claire pour un processus de management des changements, qui assure, que les modifications sont possibles, mais que celui qui les demande les paye aussi.

  1. oubli - pièce manquanteOublis : Cette raison paraît très semblable à la précédente. Les trucs oubliés ne sont pas inclus dans les évaluations. Mais cette fois, ce n’est pas parce que les personnes faisant les évaluations ne les connaissent pas, mais parce qu’ils en oublient.

Utiliser la même stratégie que sur « Faire des suppositions dans le noir » devrait rendre cette sorte d’erreur évidente. Comme remède, laissez de multiples personnes faire des évaluations et comparez les résultats. Vous devriez le faire basé sur les tâches détaillées, car des tâches manquantes dans des évaluations différentes y deviennent évidentes.

  1. Projets « Boule de glaise » : Quand les projets basés sur une base de code spécifique prennent trop longtemps à chaque fois, une raison pourrait être que les tâches continuent à devenir de plus en plus complexes que prévu. Une raison typique à cela serait une base de code excessivement complexe et tortueuse, où personne ne peut vraiment prévoir les effets que peut avoir un changement de code donné.

Dans un tel projet, je m’attendrais à beaucoup de syndrome du 80 %, peu de tests et beaucoup de développeurs qui jurent. Faites une analyse de la base de code, en vous concentrant sur le management des dépendances et l’architecture. Si vous trouvez beaucoup de non-sens, il y a une seule solution : Nettoyez cette base de code et payez votre dette technique. C’est-à-dire investissez le temps et l’argent nécessaire pour améliorer l’architecture. Je recommande aussi d’implémenter des tests qui empêcheront l’architecture de commencer à se dégrader de nouveau.

  1. Multitâche : Les personnes sont mauvaises dans le multitâche. Donc vous ne pouvez pas mettre votre meilleur développeur à 20 % sur cinq projets différents et vous attendre à ce qu’il soit aussi efficace qu’en temps normal. Une fois que vous commencez à y réfléchir, cela devrait vite devenir évident de savoir si vous avez le problème ou pas. Et il en va de même pour la solution.
  1. Le Mythique Mois Homme: Vérifiez si vos évaluations sont traitées comme cela : “Frank dit qu’il aurait besoin de 6 mois. Nous devons avoir fini dans 1 mois, donc mettons 6 développeurs sur le projet.” Si c’est le cas vous ratez tous les surcoûts que cause une plus grande équipe. Pour comprendre cette sorte de problème lisez le livre Mythical Man Month. Je pense vraiment que le livre est surévalué, mais le chapitre sur le mythique mois homme est vraiment pile sur le sujet.

Ce problème est presque certain de vous frapper quand vous faites un projet qui a de plus grande ampleur que vos projets normaux. Vous sous-estimerez grandement, si vous ne factorisez pas la sur couche exponentielle de communication sur un tel projet.

  1. Développeur Paresseux : Bien sûr il y a toujours la possibilité que les développeurs ne travaillent juste pas assez dur. Selon mon expérience, la plupart du temps, ce n’est pas un problème. Mais cela peut vraiment se produire. Les symptômes pourraient être beaucoup de fenêtres de navigateur ouvertes, sur des sites qui n’ont aucune relation avec le travail à faire, accompagné de commutations hectiques entre ces fenêtres, quand le patron arrive. Si c’est un problème avec un seul développeur, il se peut que le développeur puisse y remédier. Mais si beaucoup de développeurs passent leur temps à procrastiner alors c’est le plus probablement un problème de management. La procrastination n’est pas amusante. Réaliser des choses l’est. Donc si chacun remet ses tâches à demain, c’est qu’il y a quelque chose dans l’environnement qui les démotive probablement fortement. Découvrez quoi et éliminez le.
CSP Formation

Partenaire de DantotsuPM

la structuration 3D des projets par Jean-Yves Moine

6 fév

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

2 jan

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

qu’est-ce que l’analyse des parties prenantes et pourquoi vous devez-vous de bien la faire ?

22 déc

What Is Stakeholder Analysis and Why Should You Do It?

http://www.pmhut.com/what-is-stakeholder-analysis-and-why-should-you-do-it

par Michael L Young

Le poète écossais Robert Burns disait : “Les meilleurs plans des souris et des hommes tournent souvent de travers”. Cela se produit souvent dans le management de projet.

Vous produisez un excellent plan, embauchez des prestataires, trouvez le matériel, formez personnel et embarquez le management. Alors, venant de nulle part, c’est le déraillement parce que quelqu’un auquel vous n’avez pas même pensé est préoccupé par la façon dont le projet est exécuté et vous devez recommencer de zéro ou, pis encore, tout abandonner. Les personnes peuvent aussi facilement graisser les rouages d’un projet que l’arrêter net.

L’analyse des parties prenantes c’est identifier toutes les personnes, groupes et institutions qui peuvent avoir un intérêt dans un projet et prendre des actions pour gérer leurs intérêts et leurs attentes afin que le projet fonctionne aussi bien que possible.

Cette analyse a besoin d’être réalisée au début du projet pour que tous les risques et communications requises puissent être inclus dans le plan de projet. À cet égard, l’analyse des parties prenantes est étroitement liée avec la gestion des changements et la gestion des risques.

Des organisations et personnes de niveaux différents ont des motivations, des attentes et des intérêts différents. Le management projet contemporain considère non seulement les besoins du client et de l’organisation, mais regarde aussi la manière dont il impacte la société dans  son ensemble. Les considérations environnementales en sont un exemple classique.

Qu’est-ce qu’une partie prenante ?

En général, une partie prenante est quelqu’un qui se servira, développera, ou aura un impact sur n’importe quel aspect de votre projet. Les parties prenantes peuvent être directes ou indirectes. Des parties prenantes directes sont les personnes (développeurs, managers, clients) dont les actions peuvent directement avoir un impact sur votre projet – ils sont impliqués dans le cycle de vie du projet, ou ont un impact sur le projet – ils utilisent le système ou le livrable que le projet met en place. Les parties prenantes Indirectes sont celles qui ont un peu de pouvoir politique pour influencer le projet ou ceux qui sont intéressés par ses résultats. Pour faire court : les parties prenantes sont ceux qui ont des intérêts dans le projet.

Identification des parties prenantes

L’identification et l’analyse des parties prenantes sont réalisées au mieux à l’aide des techniques de brainstorming. Ce processus est généralement effectué sous forme d’atelier, avec les représentants des participants clés du projet.

La première étape est de lister toutes les personnes et organisations qui vont probablement être affectées, positivement ou négativement, directement ou indirectement, par le projet.

Cela aide parfois d’utiliser des catégories et penser à tous les individus et sous-groupes dans cette catégorie. Des catégories fréquemment rencontrées incluent : Management, personnel, clients, médias, communauté, finance.

Par le processus de brainstorming, listez tous les noms des parties prenantes qui pourraient :

  • Être concernées de n’importe quelle façon par le projet
  • Avoir une position influente, ou
  • Être affectée par les problèmes auxquels s’attaquent le projet

Souvent l’équipe projet connaîtra intimement les parties prenantes et aura une bonne idée de leurs préoccupations. Dans d’autres cas – particulièrement si les parties prenantes sont distantes du projet – l’équipe devra rechercher des informations pour aider à évaluer les besoins de ces parties prenantes. Faire cette recherche est nécessaire.

Collecte d’informations

Il y a trois façons principales d’obtenir des informations sur les besoins des parties prenantes. Lesquelles utiliser dépend des ressources disponibles et de l’importance ou du niveau de la partie prenante. Il y a les enquêtes, les entretiens et les « focus group ».

Les enquêtes en ligne, par téléphone et courrier sont les méthodes de recherche les plus simples et les moins chères. Les enquêtes sont généralement les plus appropriées quand il y a beaucoup de parties prenantes (par exemple : tout le personnel) quand on connaît déjà nombre de préoccupations et vous avez besoin de connaître le sentiment général. Elles utilisent des questions fermées et à choix multiple et l’analyse statistique. Les enquêtes ont généralement un faible taux de réponse mais qui augmente avec le niveau d’intérêt des personnes dans le projet.

Les « focus group » consistent à réunir  un groupe représentatif de parties prenantes, à leur poser des questions et enregistrer les consensus et diverses vues. Les « focus group » peuvent être utilisés pour identifier les préoccupations qui sont ensuite entrées dans une enquête quantitative auprès des parties prenantes.

Les interviews sont les plus coûteux en temps et sont à réserver aux parties prenantes très puissantes. Le but est d’obtenir autant d’informations que possible de la partie prenante et ses avis sur le projet pour que les plans puissent être mis en place pour adresser leurs besoins ou utiliser leur support.

Une fois que le chef de projet a rassemblé des informations suffisantes sur les besoins des parties prenantes, il peut conduire une évaluation minutieuse des parties prenantes et planifier une stratégie de communication.

Évaluation de Parties prenantes

Une fois que vous avez une bonne liste de parties prenantes et vous savez ce qui les motive, vous pouvez prendre certaines décisions sur combien d’efforts allouer à traiter de leurs besoins. Cela dépend de leur niveau d’intérêt et leur capacité à influencer sur les résultats du projet.

La grille intérêt/pouvoir est un outil utile. Vous pouvez positionner chaque partie prenante ou groupe d’entre elles sur la grille et prendre les actions appropriées. Tracez une grille avec le pouvoir sur l’axe des Y (de faible à fort) et l’intérêt sur l’axe des X (de faible à fort). Divisez en quatre quadrants. Le quadrant en haut à gauche doit être maintenu satisfait, le supérieur droit doit être managé de près, celui en bas à gauche a besoin d’être contrôlé et en bas à droite  gardé informé.

La grille Intérêt-Pouvoir

Pour ceux dans les quadrants gauches et supérieurs (colorés en bleu), vous devez obtenir les réponses à quelques questions de base pour guider vos actions. Ces informations peuvent former la base d’un rapport vers la partie prenante. Ces questions sont :

  • Qu’est-ce qui fait de ces personnes des parties prenantes?
  • De quoi ont-elles besoin de l’équipe projet ?
  • En quoi l’équipe projet a-t-elle besoin d’eux ?
  • De quels sujets l’équipe projet doit-elle les mettre au courant ?
  • Quelles méthodes seraient les meilleures façons de les informer ?
  • À quelle fréquence doivent-ils être informés ?

Rapport sur les parties prenantes

Vous pouvez maintenant commencer à préparer votre rapport d’Analyse des Parties prenantes du Projet en utilisant toutes les informations que vous avez rassemblées afin de récapituler les centres d’intérêts des parties prenantes et proposer un plan d’action.

Pour des projets plus petits un tableau de synthèse est suffisant pour capturer les informations sur les parties prenantes. Préparer-vous un tableau avec les titres et contenus suivants :

  • Groupe de partie prenante – dénomination du groupe (par exemple : direction, communauté, utilisateurs)
  • Groupes spécifiques – Sous-groupes dans ceux-ci (par exemple : Équipe de direction, CIO(DSI), Ministre)
  • Principaux intérêts/problèmes – Récapituler quels sont les secteurs d’intérêt que vous avez appris de votre recherche. Quels sont les risques que pose chacun d’eux ?
  • Canaux de communication principaux – Lister les médias avec lesquels vous communiquerez avec chaque groupe (par exemple : réunions formelles, courrier électronique, rapports).
  • Fréquence – Établissez combien de fois vous communiquerez avec ce groupe (par exemple : quotidiennement, par semaine, par trimestre, Annonce Hoc).
Groupe Sous-Groupe Intérêt Risque Canaux de communication Fréquence
Direction Finance Contrôle des coûts Réticence au changement d’outils Réunions formelles Mensuelle
Direction CIO Nouvelle techno Acquisition de nouvelles compétences Email Hebdo
           

Communication avec les parties prenantes

Le produit fini d’une analyse des parties prenantes est un plan de communication qui est une partie du plan complet de projet.

Effort de communication, mode et fréquence dépendent du coût et du niveau d’influence de la partie prenante. Certains exigeront des nouvelles simples et peu fréquentes, d’autres exigeront des communications régulières, détaillées et fréquentes.

Les informations devront être sélectionnées pour communiquer efficacement les informer suffisamment des groupes de partie prenante différents. Les outils et canaux de communication peuvent inclure:

  • Rencontres Formelles - Avec les parties prenantes puissantes
  • Rencontres Informelles - Avec les personnes intéressées
  • Liste de diffusion - Disséminer des informations aux personnes sur l’avancement du projet
  • Lettres d’information – Par la liste de diffusion, envoyées par courrier électronique ou imprimées
  • Écrans d’information – Représentation visuelle de l’avancement du projet dans lieux publics
  • Site Web – Des mises à jour régulières d’informations sur le projet en « self-service »
  • Briefings individuels – Pour ceux qui ont plus d’intérêt et sont prêts à y assister
  • Tours et Démonstrations – Pour les personnes et organisations externes intéressées
  • Forums publics – Plus approprié quand il y a des parties prenantes communautaires
  • Communiqués de presse – Faire un rapport sur le passage de jalons significatifs du projet
  • Publicités et Envois par la poste – Journaux, magazines, panneaux d’affichage
  • Comité de Liaison – Les représentants de plus grands groupes. Diffuser les minutes.

Résumé

Un bon chef de projet reconnaît l’impact clé que peuvent avoir les parties prenantes tant à aider qu’à entraver la progression du projet. Une analyse minutieuse des parties prenantes et un plan de communication soigné maximiseront les chances du projet à délivrer les livrable à l’heure et dans le budget.

le site de microsoft projet en français

Partenaire de DantotsuPM

quand le plan de projet est le problème

20 déc

When the Project Plan Is the Problem

http://www.pmhut.com/when-the-project-plan-is-the-problem par Michelle Symonds

Les chefs de projet les plus efficaces comprennent l’importance d’un plan de projet robuste avec des estimations raisonnables pour chaque activité. Donc un temps et un effort considérables entrent d’habitude dans la préparation du plan de projet. Il exige suffisamment de détails pour que chaque tâche puisse être assignée à la bonne personne ou à la bonne équipe et comprenne ce que l’on attend d’elle et quand. Il détaille les dépendances entre les tâches pour que les risques puissent être évalués à fond et il est une des composantes fondamentales d’un projet réussi.

Mais qu’arrive-t-il si le plan est fondamentalement défectueux ? Ou si les besoins changent tellement à mi-chemin pendant le projet que le plan devient dénué de sens ? Dans de telles circonstances, il peut en réalité devenir nuisible à la réussite du projet que de continuer à vouloir suivre le plan. Le PM et l’équipe projet doivent rester flexibles et adaptables dans leur approche du plan de projet. Coller rigidement à ce qui a été spécifié initialement échoue tout simplement à saisir la réalité de la plupart des projets.

Et s’il devient évident que le plan est défaillant, vous devez l’admettre et le modifier pour corriger les erreurs. Cela peut être une chose difficile à admettre, mais suivre aveuglément un plan que vous savez être faux ne mènera jamais à un bon résultat.

Des chefs de projet jeunes ou inexpérimentés peuvent ne pas être préparés à la quantité de flexibilité requise dans de vrais plans de projet et combien de changements seront exigés sur le plan pendant le déroulement du projet. Les chefs de projet plus expérimentés sauront que c’est typique de la plupart sinon de tous les projets complexes.

Les changements dans des projets peuvent survenir pour une variété de raisons :

  • le départ de personnel critique,
  • le changement de priorités business,
  • les besoins deviennent plus clairs comme le projet progresse,
  • l’objectif fonctionnel peut simplement changer à cause du marché concurrentiel.

Les changements peuvent provenir de facteurs internes à l’organisation ou de facteurs externes concernant des fournisseurs ou des services externalisés, mais, indépendamment des raisons, c’est par l’expérience de manager beaucoup de projets complexes que vous apprendrez que le changement est une partie normale de chaque activité et de chaque projet.

Les meilleurs chefs de projet emploient des plans de projet comme le point de départ dans lequel seront intégrés plus d’informations et de détails par les membres de l’équipe travaillant sur chacune des tâches individuelles, par la réévaluation des ressources du projet comme le projet progresse et par les revues des besoins du client et de l’objectif ultime. Il est donc indispensable de savoir comment contrôler le statut des projets et des ressources et comment obtenir un retour d’information significatif des membres de l’équipe et des utilisateurs finaux.

Toute personne impliquée dans un projet qui croit qu’un plan de projet peut être mis en place au début du projet et simplement mené à terme pour atteindre un résultat réussi est inexpérimenté ou bien a travaillé seulement sur des projets très simples.

Donc, il est important de reconnaître qu’un projet en échec n’est pas celui qui dévie du plan de projet ou de l’échéancier (ni même du budget) mais celui qui échoue à délivrer ce dont le client a besoin ou veut.

Changer un plan pour délivrer ce qui est exigé est simplement une étape sur le chemin d’un projet réussi et devrait toujours être vu comme tel. Il est essentiel que chacun qui est impliqué dans le projet soit conscient dès le début que le plan va probablement changer d’ici quelque temps mais qu’il est aussi important de suivre le plan actuel. C’est un difficile numéro d’équilibriste que de convaincre les parties prenantes de la véracité du plan au départ tout en les préparant au fait qu’il pourrait changer. Pas étonnant que tant de personnes essayent de faire avec un plan peu convenable plutôt que d’admettre qu’il a besoin d’une mise à jour, mais, néanmoins, c’est ce que vous devez faire pour réussir.

Un plan de projet créera seulement un problème si le chef de projet (ou quelqu’un d’autre impliqué dans le projet) refuse de le changer pour tenir compte des changements qui se produisent pendant la durée de vie du projet. Quand vous considérez que beaucoup de projets ont une durée de plusieurs années, il est peu réaliste de s’attendre à ce que le plan reste inchangé.

Bien trop souvent, sur les projets en échec, on s’efforce de déterminer pourquoi le projet dévie du plan et comment le remettre en piste au lieu de regarder comment l’objectif final pourrait tout de même être atteint. Cela peut être difficile, particulièrement quand le plan original faisait partie de la justification du projet, ce n’est pas impossible si vous vous concentrez sur ce qu’était l’objectif fonctionnel original. En fait beaucoup de méthodologies formelles de management de projet se concentrent sur l’objectif fonctionnel comme étant le facteur majeur dans les projets réussis.

Les chefs de projet peuvent souvent apprendre de projets précédents et se préparer pour le projet suivant en notant les différences entre l’échéancier attendu, le budget… et les données réelles. L’application des leçons apprises au projet suivant aidera dans la gestion des attentes de ceux impliqués et améliorera les résultats de chaque projet suivant, voilà pourquoi les chefs de projet les meilleurs sont souvent les plus expérimentés. Mais, pour le moins expérimenté, il y a des cours avec des méthodologies reconnues comme PRINCE2, la Certification PMP et APM PQ qui enseigneront nombre de techniques éprouvées par des chefs de projet qui ont dû apprendre de la manière la plus difficile.

Votre réussite passe par la performance de vos projets !

Partenaire de DantotsuPM

projets sans dates

10 nov

Projects With No Dates

http://www.pmhut.com/projects-with-no-dates de Skip Reedy

Dans mon article précédent Why Project Management is Difficult, j’ai suggéré que vous exécutiez votre plan de projet sans afficher aucune date. Pourquoi ? Parce que les gens marchent aux dates. Si quelque chose doit être fait vers la fin de la semaine suivante, la plupart des personnes le feront vers la fin de la semaine suivante, même si elles pourraient le faire dès demain.

C’est en raison d’un Syndrome et une Loi. Le Syndrome de l’Étudiant que vous avez probablement pratiqué à la perfection dans une vie précédente, est toujours vivant et bien réel dans votre vie d’aujourd’hui. Vous avez tant de choses en cours que vous ne pouvez pas entamer la nouvelle tâche avant d’avoir assez de temps devant vous pour la compléter.

Relisez ce billet sur la Loi de Parkinson

Si vous n’êtes pas tout à fait à 100% occupé, la Loi de Parkinson vous aidera à utiliser tout le temps imparti même si cela n’est pas nécessaire. D’abord, il n’y a aucune pression. Ensuite, prendre votre temps créera un meilleur résultat. Troisièmement, Il n’y a aucune raison de le faire plus tôt parce que ce n’est pas nécessaire ou bien le destinataire ne sera pas prêt. Quatrièmement, si vous avez justifié de temps supplémentaire pour le compléter parce qu’il peut y avoir des aléas, vous semblerez ne pas savoir estimer les délais. En tant qu’humains, nous vous voulons toujours paraître sous notre meilleur jour.

L’objectif pour respecter une date de fin avec ces deux comportements est une tentative de pas être en retard ni en avance. Du point de vue d’une tâche individuelle, cela peut ne pas poser de problème. Cependant, quand il y a une séquence de tâches dépendantes, il est très difficile de maintenir la durée complète sous contrôle. Avec une variation normale, quelques tâches seront en avance, mais très peu si nous travaillons par rapport à la date de fin. Avec une variation normale, quelques tâches seront en retard même si nous travaillons par rapport à la date de fin. Cela devient une question sérieuse quand quelques tâches prennent significativement plus long que la date de fin. Il y a très peu de tâches se terminant tôt pour les compenser. Ne pas être en avance ni en retard avec une variation normale devient problématique. En réalité, ce n’est pas évident et s’immisce dans nos vies comme un cauchemar. Pas étonnant les chefs de projet soient usés!

L’approche standard pour protéger le projet de ce dépassement de durée, est d’ajouter des marges de sécurité dans les tâches. M. Parkinson et Mme l’étudiante renient la majorité de cette protection. Donc, nous ajoutons encore plus de marges dans les tâches. Et plus de sécurité et toujours plus.

Vous connaissez le vieux mantra des ventes, “Ce n’est pas grave si nous perdons de l’argent sur chaque vente. Nous le compenserons par le volume. “

Essayez celui-ci, “Ce n’est pas grave si mes tâches ont du mal à être à l’heure, nous le compenserons plus tard. “

Une autre solution doit être utilisée. De là, un plan sans dates.

Blasphème de base: AUCUNE date ? Cela va empirer les choses, non ?

Aucun Délai, aucune pression, aucun exercice d’évacuation, aucun souci, aucun livrable !

Ne m’assassinez pas out de suite !

Les tâches auront des durées. Nous ne savons pas ce qu’elles seront. Pour planifier un projet, nous devons estimer combien de temps elles pourraient prendre.

Pas de dates! Essayons à nouveau.

Ce qui aiderait vraiment serait de savoir de combien de temps la tâche prendra alors qu’elle n’est pas commencée et avant que tous les apports nécessaires ne soient disponibles. Les personnes sont raisonnablement capables de faire le travail en donnant leur pleine attention à la tâche, en travaillant rapidement et diligemment jusqu’à ce que ce soit terminé. Aucun reproche. Demandez de l’aide, si nécessaire. Remettez-le livrable quand il sera prêt.

Une fois que nous choisissons finalement ce nombre, cette durée, nous savons une chose à coup sûr: Ce n’est pas combien de temps la tâche prendra. Cela arrivera plus rapidement ou plus lentement, sera interrompu, rencontrera des incidents, des retards, des changements, une maladie, des vacances et toute autre chose possible.

C’est pourquoi nous mettons partout des marges de sécurité. Et où cette sécurité nous a-t-elle menés ? À un combat pour être à l’heure! Donc nous avons un problème. Nous savons que les tâches ne seront pas faites selon le nombre, la durée que nous avons juste choisie. Cette durée n’a pas beaucoup de flexibilité. Volontairement, nous n’y avons pas  ajouté de marge de sécurité. Cela devrait être juste assez de temps si tout se passe comme prévu. La probabilité est que la tâche prendra plus longtemps que ce nombre. Nous avons besoin de sécurité, mais la sécurité dans une tâche ne résout pas le problème.

La vraie raison est que nous pensons que nous avons besoin de la marge de sécurité pour protéger l’exécution de cette tâche dans les temps. Ce n’est pas ce pourquoi nous en avons besoin. Nous avons besoin de la marge de sécurité pour réaliser le projet à l’heure.

Nous n’avons pas besoin de marge de sécurité dans durée de la tâche, nous en avons besoin dans la durée de projet.

Nous avons besoin de marge de sécurité pour protéger la date d’engagement du projet et nous avons besoin de focaliser notre attention sur l’exécution rapide des tâches.

Ensuite nous avons besoin d’estimations de tâches avec juste assez de temps pour les faire dans un monde imparfait.

le site de microsoft projet en français

Partenaire de DantotsuPM

PMO unipersonnel

17 oct

One Person PMO

http://www.pmhut.com/one-person-pmo

Par J. Alex Sherrer

Un Project Management Office (PMO) peut être une source de valeur pour les chefs de projet parce qu’il fournit la direction, la formation, la connaissance, les bonnes pratiques, la priorisation des projets et les processus organisationnels. Bien que de plus en plus de sociétés créent des bureaux de management de projet, les petites et moyennes organisations n’ont pas de PMO.

Mais cela ne signifie pas que nous ne pouvons pas nous transformer en PMO d’une personne. Par petites étapes incrémentales nous pouvons poser les bases de bonnes pratiques dans notre société qui aideront non seulement notre organisation, mais aussi nous-mêmes, en développant des documents de management de projet, des procédures et des pratiques cohérentes. Et il ne doit pas nécessairement prendre beaucoup de temps ou être créé d’un seul coup. Nous pouvons commencer avec les secteurs les plus important dans notre environnement – la clé est juste de commencer et de s’y tenir en réalisant des progrès et des améliorations cohérents.

  1. Bibliothèque d’information : Une bibliothèque pour les fichiers de projet, les modèles et les outils pédagogiques est la nécessaire première étape. Des bonnes pratiques de gestion de l’information sont essentielles parce que si nos documents ne peuvent pas être facilement localisés ou devenir périmés, nos futurs efforts de PMO  seront vains. Une information, indépendamment de sa valeur, qui ne peut pas être trouvée ne vaut pas plus que de n’avoir aucune information du tout.

  2. Modèles de documents de projet : Des modèles de documents de projet peuvent aider à faire gagner du temps et à s’assurer que nous n’oublions pas de choses importantes, mais ils peuvent aussi servir d’outils d’apprentissage pour d’autres qui peuvent avoir seulement de temps en temps à manager des projets. Nous risquons fortement de nous décourager si nous essayons de réaliser trop de modèles immédiatement, donc commençons par les documents les plus cruciaux, en les gardant aussi simples et flexibles que possible. Beaucoup de sites internet de management de projet offrent des modèles de démarrage que nous pouvons personnaliser pour nos propres besoins. De bons candidats pour de premiers modèles sont la charte de projet, la matrice des parties prenantes, le registre des risques, les RACI, le journal des problèmes, le journal des changements et la matrice de traçabilité des besoins.
  3. Processus de leçons apprises : Les leçons apprises font partie intégrales de l’amélioration continue et nous sommes destinés à faire les mêmes erreurs à plusieurs reprises si nous n’apprenons jamais d’elles. Donc nous devrions enraciner le processus des leçons apprises dans tout effort et cela devrait être une partie visible de l’initiation, l’exécution et la clôture de projet.
  4. Processus de clôture de projet : Avec notre bibliothèque en place et le processus des leçons apprises, nous voudrons nous assurer que nous incorporons ces artefacts de projet dans nos étapes de clôture administrative de projet. Chacun, nous compris, tient toujours à passer au projet suivant quand l’un est fini, mais sans vérification, catalogage et classement des informations projet, nos bibliothèques de projet sont incomplètes.
  5. Formation : Webinars et des séminaires sont une excellente façon d’impliquer d’autres personne dans l’apprentissage du management de projet sans les y forçer. Nous pouvons aussi utiliser des discussions autour de l’amélioration des modèles que nous avons créés jusqu’à présent comme des opportunités d’apprendre.
    6. Ventura

    Partenaire de DantotsuPM - Cliquez sur ce logo pour contacter Ventura pour vos besoins en Management de Projet et PMO

  6. Plans subsidiaires : Particulièrement sur des projets grands et complexes, le besoin de modèles pour les plans subsidiaires deviendra vite apparent. Ceux-ci sont les plans de collecte des besoins, de contenu, d’échéancier, de qualité, de management des ressources humaines, de communication et  de management des risques. La nécessité de ces plans peut parfois être dure à comprendre pour des non chefs de projet, donc nous devrions attendre le bon projet pour “dévoiler” ces modèles avec parcimonie afin que leur utilité soit évidente à ceux impliqués dans le projet.
  7. Système de contrôle des changements / système de management de configuration : Un modèle documenté, flexible, standardisé de contrôle des changements du projet sera un outil puissant. Le niveau de rigueur nécessaire pour ce contrôle varie largement d’un projet à l’autre, donc il peut être difficile de créer un guide généralisé.
  8. ROI : Pour beaucoup de nos projets, le processus de sélection est informel ou se produit à l’extérieur de notre périmètre de responsabilités. Cependant, sans métrique explicite de l’impact du livrable, service ou résultat final de notre projet, nous ne pouvons jamais exécuter de revues après-projet objectives. Donc une des bonnes pratiques que nous pouvons établir est de travailler avec le sponsor ou d’autres personnes dans notre organisation pour déterminer cette métrique et la revisiter ensuite après la clôture du projet pour mesurer l’impact.
← Entrées Précédentes

Suivre

Get every new post delivered to your Inbox.

Joignez-vous à 236 followers