articles, méthodes, partages d'expérience et rdv du management de projets et de l'agilité
Que lire ?Que vous soyez déjà chef de projet ou souhaitiez le devenir, ou que vous vouliez simplement améliorer vos compétences en leadership, Agile, management, projets, soft skills, … : Voici quelques livres qui sauront vous être utiles !
Vendre le management de projet reste est un sujet souvent épineux pour les chefs de projet selon les organisations.
Comment fournir à toutes vos parties prenantes les bonnes infos au bon moment ?
Comment mieux utiliser les périodes de faible énergie au travail ?Sur quoi pouvez-vous travailler quand vous vous traînez en fin de journée (ou en fin de semaine) ?
Il y a du pouvoir dans le simple acte de dire non, mais pour beaucoup d’entre nous c’est le mot le plus difficile à dire
Vidéos CAS D’USAGE, TUTORIELS et cours en ligne… ainsi qu’accès à la communauté Yammer.
Il existe au moins 3 blogs intéressants pour les utilisateurs de MS Project: « Voix des Utilisateurs », Annonces et Support.
Notre partenaire Campana & Schott a produit une fiche descriptive sur deux pages qui présente les principales fonctionnalités proposées par Office 365 Planner.
Cette fiche comprend des cas d’utilisation ainsi qu’un scénario d’intégration avec Project Online sur lequel une fiche de résumé est également proposée.
« Avec Office Planner, Microsoft offre un service cloud dédié à la collaboration des équipes, qui s’intègre parfaitement aux fonctions existantes de l‘entreprise. », déclare Sven Hausen, Director Enterprise Project Management chez Campana & Schott.
Téléchargez la fiche descriptive Office 365 Planner ! (2.0 M)
Téléchargez la fiche descriptive Microsoft Project Online ! (2.1 M)
Dans cette vidéo en anglais de 10 minute vidéo, réalisée par Microsoft, presque tout ce que vous devez savoir pour démarrer est présenté.
Ce produit est encore jeune et en plein développement, donc ne soyez pas surpris de voir apparaitre de nouvelles fonctionnalités au fil du temps. En effet, Planner est seulement disponible en tant que module de Office 365 et donc Microsoft mettra en ligne des améliorations selon son propre calendrier.
Je vous ai déjà parlé des pages Microsoft pour donner votre feedback et il en existe une pour Microsoft Planner : the uservoice page. En lisant les remarques et demandes des utilisateurs, vous verrez rapidement les limitations et réponses de Microsoft à celles-ci. Microsoft y communique également sur le produit, fonctionnalités actuelles et à venir !
Le portail de formations Office 365 met à disposition de tous des sessions en webconférences sur la plupart des produits avec des explications détaillées sur les fonctionnalités souvent méconnues mais aussi des aides à la prise en main et des cas d’usage très concrets.
Si vous en connaissez d’autres, n’hésitez pas à les ajouter en commentaires à ce billet et je les intègrerai dans la liste.
Cet article a été écrit il y a déjà plus de 5 ans par Jean-Baptiste Jourdant, consultant-formateur et Responsable du département Management de projet pour CSP Formation et partenaire de DantotsuPM.
Le chef de projet informatique Maîtrise d’OEuvre (MOE) client : « Avec cette méthode d’évaluation des charges avec les points de fonction (PF), on croit que tout est résolu, mais le prestataire fait ce qu’il veut avec tous ces ajustements, et on n’est pas plus avancé. »
Le chef de projet SSII : « Depuis qu’ils nous demandent des cotations en PF, on n’a plus de marge de manœuvre. En plus, on ne maîtrise pas les coefficients de productivité, alors on s’engage les yeux fermés, et puis on est coincé. »
Les PF sont une méthode d’évaluation des fonctionnalités logicielles telles que perçues par les utilisateurs (finaux, administrateurs métiers) de l’application. A travers différents composants (groupes de données, transactions) l’application est cartographiée puis valorisée en nombre de PF.
Puis, à l’aide d’un coefficient de productivité (nombre de PF produits par homme-jour), on calcule la charge estimée du projet.
Le PF n’est certainement pas une panacée universelle. Toutefois, il permet d’établir un référentiel compréhensible par tous les interlocuteurs de la chaîne de production.
La Maîtrise d’OuvrAge (MOA) voit ses fonctionnalités (disséquées, certes),
la MOE client va disposer d’une base de comparaison entre ses différents projets (à manier avec précaution),
la MOE SSII va disposer d’une image fonctionnelle « anticipée » de ses composants techniques, et faire valoir directement les carences éventuelles.
Les différents éléments suivants sont évalués pour prendre en compte les spécificités.
Entre la fonctionnalité et les charges, le chef de projet passe par plusieurs étapes :
1° Cartographie fonctionnelle =>100 PF Bruts
2° Ajustement produit (sécurité, techno), +20% =>120 PF Ajustés
3° Productivité nominale (REX), 2 PF/HJ =>Charge = 60 HJ
4° Efficacité projet (off-shore), 0,8 =>Charge brute = 75 HJ
5° Activités complémentaires (Conception, doc), +50% => 112,5 HJ
Finalement, dans la méthode, pour passer à l’étape suivante, on utilise un ratio qui mesure la contribution de chaque catégorie.
Et pour une productivité nominale de 2 PF/HJ, on a en réalité entre les PF bruts et la charge nette, une productivité globale de 0,88PF/HJ : 100 PF / 112,5 HJ
GPM just released an updated version of the P5 Standard for Sustainability in Project Management!
It is still free and is available at: http://www.greenprojectmanagement.org/p5
http://www.funretrospectives.com/peer-introduction-game/
Le jeu d’introduction de pairs est une activité de développement de l’esprit d’équipe pour que les nouveaux membres de l’équipe en apprennent davantage les uns des autres. Une conversation rapide suivie par introduction par un pair fournit un mécanisme rapide de présenter chaque personne dans un grand groupe.
Paulo dit: « Je vous présente Amit. Il est né au Canada, mais sa famille est en Inde. Il aime la samba brésilienne et sa nourriture préférée est le hot-dog, plus particulièrement en assistant à une partie de base-ball. Il travaille actuellement comme … »
Note: J’ai été surpris la première fois que l’on m’a invité à faire cet exercice dans le cadre d’une réorganisation et de la mise en place d’une nouvelle équipe de management.
Questions: Avez-vous également expérimenté cet exercice « brise-glace » ? En connaissez-vous d’autres ?
http://www.funretrospectives.com/one-word/
La technique « Un Mot » est un contrôle simple dans l’activité qui permet aux participants de partager leurs sentiments avant d’entrer dans les données et détails de la réunion en elle-même. C’est une bonne ouverture pour une réunion car elle reconnaît les sentiments des personnes et les fait parler dès le début.
Cette activité est décrite comme un Activité de Checkin par Esther Derby Et Diana Larsen dans leur remarquable livre Agile Retrospectives book.
http://www.agileadvice.com/2016/06/03/scrumxplean/splitting-user-stories/ par Faisal Ansari
Un défi usuel auquel sont confronté les équipes Scrum inexpérimentées est lié au découpage des « User Stories » (dans Scrum, les articles du Product Backlog) pour qu’elles soient suffisamment granulaires pour le développement. Le modèle INVEST est une bonne façon de tester si les « User Stories » sont bien écrites.
Chaque « User Stories » doit être indépendante l’une de l’autre. Ceci empêche les chevauchements entre les items; de plus, cela permet à l’équipe de les implémenter dans n’importe quel ordre.
Les détails du travail doivent être négociables, tant parmi les parties prenantes que l’équipe. Les besoins spécifiques et décisions de conception seront étoffés pendant le développement. Beaucoup de praticiens agiles recommandent d’écrire les « User Stories » sur une petite fiche – ceci est intentionnel pour qu’une quantité limitée de détails puisse être prescrite.
Chaque « User Stories »doit ajouter un valeur métier/business au produit, au client et/ou à l’expérience des utilisateurs.
Une bonne « User Stories » peut être suffisamment bien comprise par l’équipe pour qu’ils puissent l’évaluer – pas précisément – mais qu’à un haut niveau ils en perçoivent la taille. Il est utile de comprendre l’effort relatif en comparaison d’autres « User Stories ».
Une « User Story » n’est pas assez petite si l’équipe ne peut pas la faire faire dans un seul Sprint. Comme des grandes « User Stories » sont divisées en items plus petits, la clarté sur la taille et la mise en œuvre est plus grande, ce qui améliore la probabilité que l’équipe le réalisera en un Sprint.
Testable
Chaque « User Story » devrait être testable; ceci est une caractéristique commune de tout besoin bien écrit. Si l’équipe ne peut pas déterminer comment la « User Story » peut être testée, c’est une indication que la fonction désirée ou la valeur business désirée ne sont pas assez claires.
Il y a deux manières communes de découper des « User Stories » : verticalement ou horizontalement. La découpe horizontale divise l’article au niveau d’un composant architectural. Exemple : Interface Utilisateur, bases de données ou services back-end. Tandis que, une découpe verticale aboutit à un résultat logiciel démontrable qui ajoute de la valeur au business. Donc, on recommande de découper verticalement les « User Stories » afin de réduire les dépendances et améliorer la capacité de l’équipe à livrer un incrémentent de produit potentiellement utilisable à chaque sprint.
Si la susdite histoire devait être divisée de façon verticale, elle pourrait se décomposer en fonction des façons de payer pour un client comme suit…
Et/ou
Le point clé de noter dans les « User Stories » verticalement décomposées comme ci-dessus consiste en ce que chaque « User Story »passe les tests INVEST mentionnés plus tôt et donc un Propriétaire de Produit (Product Owner) peut prioriser ces « User Stories » en fonction des besoins clients. Cependant, si une approche horizontale a été utilisée pour diviser la « User Story » (c’est-à-dire décomposition selon les couches et composants architecturaux) alors la mise en œuvre de tels besoins aboutira à une fonctionnalité utilisable Seulement quand tous les composants horizontaux seront finalement livrés et intégrés.
Une autre approche souvent utilisée sur les « User Stories » est de se concentrer sur les étapes individuelles qu’un utilisateur peut entreprendre pour atteindre son objectif final. C’est-à-dire une « User Story » qui décrit un long parcours ou « flux utilisateur » dans un système peut être décomposé selon les étapes qui en représentent les parties. En reprenant l’exemple précédent d’un client faisant un achat en ligne, la « User Story » peut être décomposée de la manière suivante :
En tant que client, je peux passer en revue les articles que je veux mettre dans ma commande pour être confiant que je paye pour les bons articles.
En tant que client, je peux recevoir un avis de confirmation pour mon achat pour suivre et garder une trace de mon achat.
Il y a de nombreuses autres méthodes qui peuvent être utilisées dans le découpage des grandes « User Stories » comme :
la liste ci-dessus est détaillée (en anglais) dans ce billet: Blog.agilistic.nl.
https://blogs.office.com/2016/06/16/the-6-not-so-obvious-reasons-a-project-plan-fails/ by Office Team
En fait, les petits projets ont 10 fois plus de chances de réussir selon le rapport « Chaos Manifesto » et seront deux fois plus probablement dans les temps, dans le respect de leur budget et la livraison des fonctionnalités critiques attendues. Il n’est bien sûr aucunement garanti que tout petit projet réussisse…
Tous les projets, même petits, ont beaucoup de composants en mouvement. Si vous travaillez dans le marketing, les ressources humaines, l’informatique, la construction ou autre industrie, l’agilité et la flexibilité sont de réels atouts pour vos projets. Le chef de projet Agile qui s’est développé avec l’adoption de postures et principes tel le Manifeste Agile, avec des artefacts et méthodes comme Scrum et des solutions logicielles de management de projet plus collaboratives. Adopter des méthodes flexibles permet d’être mieux armé pour manager un projet dans l’environnement actuel qui est en perpétuelle et rapide transformation. Le projet managé avec Agile génèrera du revenu plus rapidement grâce à la livraison itérative de solutions certes incomplètes mais apportant de la valeur rapidement. De plus, les bénéfices seront également plus importants en bout de course car les fonctions non critiques ne seront probablement jamais développées avec ces approches.
Un outil performant devra être mis en œuvre (même sur un projet de petite taille). Les coûts d’acquisition, de configuration et d’utilisation sont devenus plus abordables (en particulier dans le Cloud). Selon Information Week les sociétés à haute-performance comprennent l’importance des logiciels de planification de projets en matière d’efficacité et de performance. Leurs principaux critères de sélection sont la fiabilité, la facilité d’intégration et la facilité d’usage (la convivialité). Le bon logiciel devrait aussi converser de manière transparente avec les outils universels de l’entreprise comme la bureautique.
Avec des équipes travaillant à distance à distance, et souvent à l’échelle mondiale même dans les petites structures, sur des fuseaux horaires différents et des cultures variées, bien communiquer et bien manager le temps sont devenus plus critiques que jamais. Donner accès à des outils qui laissent des parties prenantes s’auto-manager et partager les derniers statuts, discussions et échéanciers de projet maintient tout le monde connecté et organisé.
Avoir un sponsor exécutif avec un réel intérêt dans le projet, quelqu’un qui ira se battre pour votre projet du début à la fin, est un grand facteur (sinon le plus grand) dans le succès du projet. L’avoir est déjà bien, mais l’engager activement pour qu’il donne une direction claire et aide dans la résolution rapide des problèmes est encore mieux. Le manque de temps est souvent un problème. Aussi, avant le démarrage du projet, Le sponsor et le chef de projet devraient se rencontrer pour discuter des questions comme l’engagement de temps, les rapports d’avancement, les réunions, les mécanismes de remontée de problèmes, etc.
Être bien aligné sur la stratégie business n’est pas aisé pour le projet. Cependant, c’est un impératif pour avoir de bonnes chances de réussite. Il est critique d’avoir une compréhension des priorités stratégiques clés de la société puis d’examiner le projet pour voir comment il se justifie par rapport à celles-ci. Ceci va aider à positionner le projet dans la liste des priorités de l’entreprise. En plus d’économiser un temps, des efforts et ressources précieux, cela aide aussi à obtenir le support exécutif nécessaire.
Le PMI® a constaté qu’une des causes majeures de réussite rapportée par les sociétés est une communication supérieure. La capacité à communiquer en temps réel avec les membres de l’équipe où qu’ils soient grâce aux logiciels de management de projet collaboratifs sécurise le succès d’un projet.
Du plus simple au plus complexe, il y a beaucoup de pièges qui peuvent emporter un projet. Mais pour chaque piège, il y a aussi une solution.
Les organisations ultra performantes ont compris qu’il n’y a pas de temps à perdre pour implémenter ces changements si nécessaires.
PMI is a registered mark of Project Management Institute, Inc.
Voici une brève vidéo qui en expose les concepts sur un exemple concret.
The courses offer a diverse self-training experience including videos, labs and assessments.
To take the courses: go to https://www.edx.org/ and enroll.
LA conférence qui discute de l’essence même des principes fondateurs de ce que l’on appelle maintenant « l’agilité ». L’orateur, Dave Thomas est ici tout à fait légitime puisqu’il revient sur la réunion, à laquelle il participait en 1999 qui donnait lieu au « Manifesto for agile software development »
L’étude du management de projet Agile fournit une compréhension de base d’Agile qui vous permet d’appliquer Agile à tous les aspects de votre rôle et votre organisation
Les certifications PMP et PgMP ont une durée de validité de 3 ans à compter de la date de réussite à l’examen. Afin de prolonger leur certification PMP ou PgMP, les certifiés doivent « gagner » 60 Professional Development Units (PDUs) sur les 3 années du cycle de validité des certifications.
PMI, PMP and PgMP are registered mark of Project Management Institute, Inc.
quelle est la première chose que vous faites en vous asseyant devant votre ordinateur le matin ?Laissez-moi deviner : vérifier le flux entrant. Vérifier le courrier électronique ou des statistiques de trafic ou les messages de votre patron. Vérifier les tweets que vous suivez ou le statut Facebook d’amis.
C’est moins le Comment je trouve le temps que le Pourquoi je trouve le temps. Vous trouverez toujours le temps pour les choses qui ont un très fort pourquoi. »
Le 6 juillet dernier, Jeff Sutherland et Ken Schwaber, les créateurs du Scrum Framework, ont présenté les mises à jour du « Scrum Guide ».
Elle met en évidence 5 valeurs cardinales de Scrum et de l’Agilité et les détaille.Visitez http://scrumguides.org pour lire et télécharger le Official Scrum Guide (seulement disponible en Anglais pour l’instant).
Ceci permet de toujours pouvoir garder un œil sur les déviations entre les dates planifiées initialement et la dure réalité avec l’avancement réel.
Les 2 vidéos suivantes expliquent comment aisément suivre son échéancier et générer les rapports dont vous avez besoin.
The exposure draft is available until 26 July 2016, and open to any members of the public with an interest in project management.
PMI plans to launch the PMBOK® Guide in 10 languages at the same time as the English version, in third quarter of 2017.
The PMBOK® Guide – Sixth Edition will feature several significant content enhancements.
Most notably, this edition will include expanded coverage of agile.
New in the sixth edition, each section (or knowledge area) of the guide will have three introductory sections.
Other content enhancements include:
The Guide to the Project Management Body of Knowledge (PMBOK® Guide) contains both a standard (The Standard for Project Management) and a guide within the same book.
The standard section, which was exposed for comment earlier this year, provides the foundation for the PMBOK® Guide. All other information in the PMBOK® Guide is aligned with the Standard for Project Management.
Details, viewing and participation in the review, click here.
PMI Talent Triangle, PMI and PMBOK Guide are registered marks of Project Management Institute, Inc.
http://projectriskcoach.com/2016/04/22/how-to-identify-and-manage-secondary-risks/ par Harry Hall
Une réponse à un risque peut créer d’autres risques. Ceux-ci sont des risques secondaires qui peuvent s’avérer plus significatifs que les risques primaires si nous n’y prenons garde.
L’une des épisodes du dessin animé de la Panthère Rose la montrait aux prises avec une souris dans sa maison. La souris la rendait folle; elle devait trouver une façon d’éliminer ce problème.
La Panthère Rose, portant un costume de chat, a chassé la souris de la maison puis dans la rue. Les chiens du voisinage ont poursuivi « le chat ». La Panthère Rose a couru pour sa survie, mais a fini déchirée en lambeaux.
Un risque secondaire est un risque qui est créé par une réponse à un autre risque.
Le propriétaire de risque peut être fort bien intentionné dans sa réduction de la probabilité et de l’impact d’un risque; cependant, beaucoup de réponses ont le potentiel de créer des risques secondaires. Si le propriétaire de risque atténue une menace, en exécutant un plan de contingence, ou en exécutant un plan de repli, il peut causer des risques secondaires.
En définissant des plans de réponse aux risques, leurs propriétaires devraient identifier, capturer et développer des plans de réponse aux risques secondaires dans le registre des risques. Les propriétaires de risque devraient chercher les réponses au risque les plus efficaces et qui produisent la moindre quantité de risques secondaires.
Imaginez que vous faites partie de l’équipe projet qui a été chargée d’ajouter une nouvelle fonctionnalité à un logiciel de gestion des comptes clients sous quatre mois. Le projet est critique pour pouvoir espérer battre la concurrence en lançant rapidement la commercialisation et en capturant au passage des parts de marché.
En identifiant les risques, l’équipe projet n’est pas certaine que les deux développeurs assignés pourront compléter les tâches de programmation dans les temps.
L’équipe décide que, si les développeurs prennent une semaine ou plus de retard sur l’échéancier, ils ajouteront une autre ressource. Cependant, l’équipe reste inquiète car cette réponse peut causer un risque secondaire : l’ajout d’un nouveau développeur exigera que les développeurs originaux lui fournissent des explications et de l’orientation, les mettant encore plus en retard dans leurs tâches. L’équipe capture alors ce risque secondaire dans le registre des risques et développe des plans de réponse à cette éventualité.
Passez en revue les plans de réponses de risque que vous avez développés et identifiez les risques secondaires. Évaluez ces risques secondaires et développez des plans de réponse pour les plus significatifs.
http://blog.oikosofy.com/happiness-index-agile-retrospective-tool/
Peu importe combien votre équipe est performante, il y a toujours une opportunité d’amélioraation. L’indice de bonheur est un outil des rétrospectives agile, qui mesure le bonheur des équipes agiles. Luis Gonçalves le partage dans le livre écrit avec Ben Linder « Getting Value out of Agile Retrospectives. »
Cet exercice est une combinaison de « Développez une chronologie » et « Sismographe émotionnel » de Normand L. Kerth.
Le but de cet exercice est d’avoir une représentation graphique des émotions des membres de l’équipe pendant un Sprint. Ce type d’informations aide l’équipe à identifier ce qui affecte sa performance pendant le Sprint. Indépendamment du problème qu’expérience l’équipe, cet exercice les aide à révéler les émotions d’équipe directement en cet endroit.
C’est certainement approprié pour une équipe qui passe à travers beaucoup d’émotions différentes (positives ou négatives) pendant un sprint. Cela leur bénéficie quand ils veulent en évaluer les conséquences ou quand l’équipe a plusieurs défis dans le Sprint et voudrait comprendre comment ces problèmes sont apparus.
L’indice de bonheur est approprié pour n’importe quelle équipe. Il n’exige pas de niveau de maturité spécifique. L’exercice peut être appliqué tant aux équipes à distance qu’à celles réunies en un même lieu.
Prenez une page blanche A4 et quelques post-it. Divisez le papier sur 2 parties/axe – positif et négatif. Graduez ensuite l’axe des abscisses en fonction des jours de sprint.
Il y a 2 façons de conduire l’exercice
Option 1 : L’exercice est fait pendant la rétrospective avec toute l’équipeCréez de petits groupes de 2-3 personnes. Demandez-leurs de faire une session de brainstorming sur les événements ou les situations qui se sont produites pendant le dernier sprint. Ensuite, demandez aux groupes de créer une représentation graphique des niveaux émotionnels pour les situations sur lesquels ils ont fait du brainstorming. Quand tous les groupes ont terminé, compilez une représentation de tous les groupes sur un seul graphique. N’oubliez pas de mettre une explication sur chaque émotion différente.
Option 2 : L’exercice est réalisé par petits bouts pendant le sprintAu lieu d’une équipe dessinant le graphique émotionnel, vous laissez chaque individu dessiner un graphe avec son propre niveau d’émotion à la fin de chaque journée de travail. Cette approche permet de s’assurer que tous les événements ou situations sont couverts et aucun n’est oublié.
Vous aurez une belle vue de ce qui est arrivée pendant le sprint. Ces informations aident le facilitateur de la rétrospective dans l’identification des situations qui devraient être répétées et des événements qui causent des problèmes ou le retard de l’équipe.
De plus, vous pouvez aussi utiliser des techniques d’analyse de cause racine pour identifier les problèmes fondamentaux.
DantotsuPM.com 