articles, méthodes, partages d'expérience et rdv du management de projets et de l'agilité
Il me semble que le focus est trop souvent limité à identifier et manager les dangers. Hors, il est tout aussi critique de protéger et développer ses équipes, ressources, parties prenantes, partenaires… et de trouver les équilibres pour la bonne santé du projet et de ses acteurs.
En management de projets, il n’y a pas de baguette magique mais plutôt un ensemble d’outils, de méthodes et d’approches dont le professionnel a appris à se servir pour satisfaire ses clients et équipes.
https://www.scruminc.com/jeff-suthlerland-launches-scrum-at-scale-guide/ par Jeff Sutherland
La première équipe de Scrum a fini son premier Sprint il y a 25 ans. Mon but alors et il continue de l’être, était de construire des équipes à hautes performances. Depuis, je me suis concentré uniquement sur ce sujet. Comment permettons-nous aux gens d’en accomplir davantage, de vivre de meilleures vies et de changer fondamentalement la trajectoire de leur réussite ?
Il est stupéfiant de voir comment Scrum a réorganisé le monde de travail au travers de nombreuses disciplines et au-delà du logiciel. The Standish Group data montre que des projets Agiles ont trois fois moins de chance de complètement échouer que des projets en cascade et quatre fois plus de chance de réussir. C’est ce qui fait que les sociétés veulent devenir « Agile ».
Actuellement, la menace existentielle sur Scrum est le “Mauvais Scrum (Bad Scrum).” Donc, j’ai investi ces quelques dernières années à codifier les meilleures pratiques pour faire grandir Scrum et réfléchir à ce qui fonctionne ou pas et y donner un nom : Scrum@Scale.
Donc je l’ai gardé simple. Le Guide Scrum@Scale comporte juste quelques pages. Comme avec Scrum et le Guide Scrum, il est libre d’accès. Vous ne devez pas me demander la permission. Prenez-le, utilisez-le et partagez votre connaissance et votre expérience.
Chaque équipe Scrum est différente, même des équipes dans la même organisation. Elles ont leur culture propre, leurs façons de travailler, des succès, des échecs, leur propre contexte. Mais elles suivent une structure commune. Et dans cette structure elles développent itérativement de nouvelles solutions aux problèmes qu’elles essayent de résoudre.
Pour disséminer le bon Scrum et avoir l’impact nous voulons avoir sur le travail, nous avons besoin de plus de personnes que seulement Scrum Inc. pour l’enseigner. Nous avions un pilote l’année dernière avec Angela Johnson de l’Équipe Co-Lead et avons énormément appris. Nous postons ses formations sur le site Web de Scrum Inc aussi bien que scrumatscale.com. L’an dernier, nous avons décerné un diplôme à notre première classe de formateurs Scrum@Scale. Ils étaient 17.
Je veux vraiment mettre en évidence une chose que nous exigeons vraiment . Pour devenir un formateur Scrum@Scale vous devez avoir implémenté Scrum à l’échelle et soumis une étude de cas de ce travail. Qu’avez-vous appris ? Qu’est-ce qui était difficile ? Qu’est-ce qui a fonctionné ? Et cette étude de cas doit être partagée. Pas juste avec Scrum Inc. Pas seulement avec d’autres formateurs Scrum@Scale. Avec le monde entier. Nous voulons que le monde entende parler des réussites de nos formateurs et que ces histoires deviennent des points de référence dans une conversation globale.
Des centaines de personnes ont déjà suivi nos classes Scrum@Scale, beaucoup de coachs et formateurs. Les réactions que nous avons obtenues sont que c’est une codification des meilleures pratiques qu’ils avaient appliquées depuis des années. Nous voulons favoriser une communauté où les gens et les organisations se transforment en apprenant les uns des autres.
Une bibliothèque qui est là si vous êtes l’une des sociétés du Fortune 100 aux États-Unis ou une startup en pleine croissance à Hyderabad.
Comme vous le savez peut-être, je me suis retiré du poste de CEO de Scrum Inc en janvier 2018. Une des raisons principales est qu’ainsi je pourrai concentrer mes efforts sur Scrum@Scale et le partager avec autant de personnes que possible dont les vies seront meilleures grâce à cela.
https://www.lollydaskal.com/leadership/handle-annoying-overconfident-people-life/ par Lolly Daskal
Parfois, il est difficile de ne pas les laisser nous impacter.
Mais il y a une façon efficace de gérer les gens présomptueux.
Mon travail de coach de cadres exécutifs me met en contact avec les personnes les meilleures dans toutes sortes d’organisations et d’industries, et je rencontre des gens présomptueux tout le temps. Une facette de mon rôle est de les recentrer sur la réalité et une partie de cela est de leur apprendre à travailler avec d’autres personnes présomptueuses.
Tout d’abord cependant, faisons une distinction claire entre deux degrés ou types différents de profils présomptueux. Le premier est le narcissique, qui est non seulement présomptueux, mais a aussi un sens de supériorité et de bon droit. Pour une discussion détaillée sur comment gérer un narcissique, voir mon article sur Inc. How to Deal With a Narcissistic Leader
M
ais ici nous considérons un ordinaire présomptueux: un collègue, ou un boss, ou un associé.
Ceux qui vous portent sur les nerfs tous les jours.
La meilleure façon de gérer une personne présomptueuse est de trouver votre propre sens intérieur de sécurité. Quand vous pouvez trouver en vous votre propre confiance, rien qu’une personne présomptueuse puisse dire ou faire ne vous abattra. Elle peut être incapable de vous toucher et peut même dire des choses très désagréables ou cruelles, mais vous pouvez toujours laisser glisser cela quand vous vous sentez sûrs de vous.
C’est facile à dire, mais plus difficile à accomplir. Mais si vous pouvez apprendre à ignorer son attitude présomptueuse et supérieure et essayer de trouver des façons dont vous pouvez apprécier sa compagnie en société, cela peut bénéficier à vous deux. En creusant, il y a probablement quelque chose chez cette personne qui vaut la peine de connaitre ou explorer. Peut-être même qu’au niveau le plus profond, il peut y avoir une personne bonne et gentille, mais avec quelque chose qui, dans le contexte, cause leur comportement présomptueux.
Les gens présomptueux sont souvent peu sûrs d’eux-mêmes et dissimulent leurs insécurités par la dominance et le contrôles des autres. Ils ont beaucoup de mal à admettre leurs erreurs et ils s’accrocheront souvent à une croyance même face à la preuve qu’elle est périmée ou fausse.
La plupart d’entre nous sont rapides pour juger. Peut-être l’impatience est-elle votre faiblesse personnelle et la frustration et l’irritation sont de fréquentes réponses pour vous. Peut-être vous sentez vous intimidés ou sous pression. Indépendamment, les gens présomptueux présentent une grande opportunité d’apprendre la patience et à écouter sans jugement. Donnez-vous pour objectif de tolérer la personne et apprenez à comprendre ce qui la motive. Pensez à comment vous répondriez dans la même position.
Les gens confiants peuvent sentir de loin les gens qui doutent d’eux-mêmes et quand ils le font, ils sauteront probablement dessus. La meilleure façon de combattre ceux qui pensent qu’ils ont toutes les réponses est d’améliorer votre propre assertivité. Les gens extrêmement présomptueux ne gaspilleront pas leur temps sur des personnes qu’ils ne peuvent pas bousculer ni se servir.
Donc, vous avez essayé la tolérance et avez amélioré votre assertivité. Maintenant, vient le temps d’une nouvelle arme : le tact. Vous pouvez toujours mettre en évidence des choses qui sont évidentes en elles-mêmes sans répondre à l’arrogance de la personne. Vous pouvez aussi répondre avec force aux choses qui sont incorrectes, faites-le juste avec bonté et empathie.
Un autre grand outil pour gérer les gens présomptueux est simplement de pivoter vers un nouveau sujet. En changeant la conversation, vous pouvez stopper la dominance de la personne présomptueuse.
Si elle essaie de revenir sur l’ancien sujet, mentionnez poliment que chacun a déjà fait connaitre son point de vue et repartez sur encore un autre nouveau sujet.
Si vous avez essayé en vain toutes les autres techniques, vous pouvez toujours diminuer l’impact d’une arrogante personne présomptueuse. Gardez vos distances pour maintenir votre santé mentale. Faites simplement de votre mieux pour éviter leur chemin. Cela vous fera gagner du temps pour mettre au point comment mieux répondre, ou au minimum cela réduira leur présence ennuyeuse.
Comme Charles Bukowski l’a si brillamment exposé, “The problem with the world is that the intelligent people are full of doubts, while the stupid ones are full of confidence.”
Le dernier livre de Lolly Daskal, The Leadership Gap: What Gets Between You and Your Greatness est disponible!
Naturellement la prochaine étape serait de le construire, n’est-ce pas ?
Trop d’équipes sautent directement dans la construction sans même valider leur idée. Ensuite, vous vous retrouvez avec un produit fini qui a mille et une fonctionnalités, mais pas d’usage. Personne ne l’utilise, ne l’achète, ne le comprend…
C’est pourquoi le prototypage est crucial pour construire un produit que les gens aiment.
Le prototype vous aide à vous concentrer sur les bons détails et vous évite de perdre un temps précieux et de l’argent.
En résumé : vous devez « faire semblant » avant de le « faire vraiment ».
Je vous suggère de commencer à visionner cette vidéo 6 minutes après le début ; Durée 30 minutes (plus questions/réponses)
Vous pouvez aussi trouver les diapositives de la présentation ici : http://bit.ly/2vjq5z2
Le tout premier rapport de l’industrie qui regardait en profondeur les antécédents scolaires, l’expérience au travail, les industries et les détails organisationnels des entreprises pour lesquels travaillent les Scrum Masters ou coaches Agile.
L’édition 2019 du Scrum Master Trends Report a été créée en partenariat avec Scrum.org, le principal établissement de formation et de certification Scrum fondé par Ken Schwaber, cofondateur de Scrum.
http://sethgodin.typepad.com/seths_blog/2018/02/im-not-selling-anything.html par Seth Godin
Bien sûr que si. Vous vendez une connexion ou une avancée. Vous vendez une nouvelle manière de penser, un meilleur endroit où travailler, une chance de faire la différence. Ou peut-être vendez-vous la possibilité, la générosité ou du travail pur et dur.
Il se pourrait que la vente que vous faites consomme du temps et des efforts, pas de l’argent, mais si vous essayez de changer quoi que ce soit, alors vous vendez quelque chose.
Si vous n’essayez pas d’améliorer les choses, pourquoi êtes-vous ici ?
Alors, bien sûr, vous vendez quelque chose.
Peut-être serait-il plus précis de dire « je ne vends pas quelque chose trop agressivement, en envahissant votre espace, volant votre attention et vous poussant à faire quelque chose qui ne correspond pas à vos objectifs. »
Ceci est probablement vrai. Du moins je l’espère.
Using a « Technical Debt Register » in Scrumhttps://www.scrum.org/resources/blog/using-technical-debt-register-scrum par Ian Mitchell
En vieillissant, je me métamorphose en l’un de ces types nostalgiques et ennuyeux qui vit trop dans le passé. Les choses étaient mieux avant, mon enfant. Nous avions des standards et il y avait moins de « sur-simplification ».
Mais parfois au crépuscule, comme je me lève de mon fauteuil à bascule sous le porche et me penche en avant pour soulager mon dos, je reconnais qu’il y a une chose qui est en réalité meilleure maintenant qu’au début des années 2000 : De nos jours, un homme peut parler de la « dette technique » sans que les gens le prennent pour un fou.
La dette technique peut être définie comme les conséquences à long terme de faibles décisions de conception. À l’origine décrit comme une métaphore par la Ward Cunningham, à peu près tout le monde accepte maintenant que la dette technique est un risque réel qui peut réellement être encouru. Cette identification est bonne. Critiquer Java et en damner les conséquences n’est pas vraiment « Agile », c’est juste jouer au cow-boy. Mais la vérité est que pendant des années, cela n’a pas été compris, pas avant que les dettes de certains imbéciles soient si importantes qu’elles ne puissent perdurer.
C’est parce qu’ils ne reflètent pas toujours « des décisions de conception ». Ce sont souvent juste des erreurs, peu importe à quel point ils pourraient être irresponsables ou indignes. Ainsi quand une décision ne met pas directement en péril la qualité de produit, ce n’est pas de la dette technique. Une équipe peut souhaiter un nouvel environnement ou un module d’extension, mais ne pas les fournir n’est pas de la » dette technique », puisque cela ne met pas en danger la qualité du produit lui-même. Cela pourrait très bien réduire la vitesse de développement, parce qu’ils doivent boitiller en utilisant une vieille plate-forme de développement, mais c’est un problème différent.
Dans Scrum, l’attente consiste en ce qu’une définition de DONE (fait) devrait être suffisamment robuste pour que des niveaux ingérables de dette ne puissent pas s’accumuler. De là, si on sait que la dette technique va augmenter, la définition de DONE devrait être revisitée. Il est essentiel de découvrir pourquoi la dette est encourue et comment cela peut être évité.
Par exemple, une équipe devrait tenir compte du « refactoring » (et bien d’autres tâches) en décidant de combien de travail ils peuvent embarquer dans un Arriéré de Sprint sans mettre en péril la qualité à long terme. Mais en dehors de ces contrôles et recherches d’équilibre, il n’y a aucune prescription sur comment la dette technique devrait être traitée une fois que vous l’avez. Ce n’est pas une inadvertance, puisque Scrum est délibérément aussi non-normative que possible. C’est une structure de travail qui laissent aux équipes la décision de comment elles la mettent en œuvre.
Notez cependant que mettre en œuvre « des sprints spéciaux » pour nettoyer la dette technique n’est pas une option. Des sprints techniques de dettes, aussi mentionnés comme des sprints de solidification ou renforcement, sont essentiellement un anti-modèle. Chaque Sprint doit apporter un incrément de valeur véritable. C’est pourquoi la Définition de DONE est le rempart primaire contre l’accroissement de la dette en premier lieu.
Dans ce registre les décisions de conception qui mènent à de la dette peuvent être rationalisées. Vous pouvez penser à ce registre comme un registre RAID (Risques, Assomptions, Issues & problèmes, et Dépendances) qui est sous le contrôle de l’équipe. L’équipe y détaille les conséquences techniques de décisions prises de manières opportunes sur la qualité de mise en œuvre du produit, souvent en termes de probabilité, d’impact et de remédiations envisagées. Il peut être possible de recommander de l’adresser pendant un Sprint, si l’équipe a une compréhension suffisante de l’Arriéré de Produit. Suppositions et dépendances peuvent aussi entrer dans le registre et bien sûr quelques risques peuvent finalement transformer en douloureux problèmes.
Un registre technique de dettes peut aider à informer des équipes de comment la dette encourue devrait être gérée. Ils peuvent prendre des décisions réfléchies et informées sur quand vraiment ajouter de la dette et quand au contraire la rembourser. L’utilisation d’un tel registre ne fait pas partie de Scrum, mais néanmoins cette technique peut aider une équipe à prendre en main la dette technique qu’ils décident d’accepter. Parfois, par exemple, la dette technique peut être réglée en mettant en œuvre des histoires de l’arriéré de produit. Dans d’autres cas pas, et la dette doit alors être adressée séparément.
Certains cas de dette peuvent devoir être exposés au Propriétaire de Produit pour leur prise en considération et d’autres pas. Dans les cas sévères, de la dette technique peut avoir été accumulée qui excède la valeur du projet lui-même, probablement même de multiples fois. Dans de tels cas extrêmes, l’approche la plus pragmatique peut être de tuer le projet et repartir de zéro. Inutile de le dire, cette variation de « échouer maintenant plutôt que plus tard » nécessite un courage extrême.
Une autre option quand on fait face à une dette technique substantielle est de la réduire graduellement, Sprint après Sprint. L’équipe peut devoir s’entendre avec le Propriétaire de Produit pour livrer quelque chose, à chaque itération, qui fournisse tout de même une valeur suffisante aux parties prenantes. Clairement ce n’est pas une excellente option. Elle peut se terminer en marchandages, où la magnitude et la propriété du problème de la dette ne sont pas reconnues ni rendues visibles des parties prenantes. La dette technique devient alors plus d’un cas de problème technique. Les parties affectées pourraient être encouragées à fermer les yeux tant qu’elles obtiennent quelque chose de valeur immédiate pour le business en retour, mais aucun de ceci n’est bon pour la franchise, la confiance ni la transparence.
Maintenant, bien qu’ayant comparé un registre technique de dettes à un registre RAID, je ne suggère pas qu’il doive prendre la forme « documentée » habituelle de celui-ci. Selon mon expérience, il est généralement meilleur d’utiliser un « Information Radiator ». Parfois, cela peut être aussi rudimentaire qu’une feuille de papier scotchée au dos de la chaise du ScrumMaster, mais je préfère proposer aux équipes d’utiliser un mur de cartes dédié à cette fin. Les statuts typiques sont : A faire, En cours, Fait et A escalader. Les articles sont Faits quand ils sont ou atténués ou acceptés.
Incidemment, cela marche aussi pour les registres RAID conventionnels au niveau du projet et du programme. L’escalade depuis un Registre de Dettes Techniques impliquerait sa promotion à un tel niveau. Les managers sont ainsi encouragés à prendre un intérêt actif dans ces registres et questionner tout problème non remonté qui semblent bloqué.
Cela peut être une excellente façon d’encourager le « gemba » chez les managers, où ils sortent du bureau, s’y promènent, mettent leurs liens hiérarchiques et filtres de côté et voient la réalité des choses par eux-mêmes.
Un jalon de projet est un outil puissant pour marquer et évaluer la progression du projet. Représenté par une forme en losange dans les logiciels de diagramme de Gantt, ces trésors indiquent des points clefs dans le plan de projet, comme la fin d’une phase ou une date butoir pour un élément à livrer.
En préparant un échéancier de projet (idéalement sur un diagramme de Gantt), il est important de positionner dans le bon ordre les jalons de projet pour définir des cibles atteignables, marquer les différentes phases du projet et indiquer des événements clefs comme un lancement d’un produit ou une réunion avec le client.
Chaque fois que vous atteignez un jalon, il est important de comparer votre progression réelle par rapport au plan prévisionnel. Plus tôt vous pouvez découvrir des erreurs dans votre exécution de projet, plus tôt elles peuvent être corrigées. Utilisé ainsi, les jalons deviennent critiques pour évaluer les membres d’équipe et définir le succès du projet.
Il peut être tentant d’abuser des jalons de projet pour créer un sentiment d’urgence dans votre équipe. Mais si vous vous reposez trop sur les jalons, ils perdront de leur importance, les rendant plus faciles à ignorer. Placez-les intelligemment, d’habitude aux derniers délais sur les livrables majeurs ou à la fin de phases de projet. Vous constaterez que vous pouvez garder votre équipe motivée à faire son maximum pour atteindre ces buts.
Comme votre équipe s’approche d’un jalon, vous constaterez que chacun pousse un peu plus fort pour atteindre cette cible. Une fois que vous atteignez ce jalon, il est temps de le célébrer ! Indépendamment de comment vous célébrez, assurez-vous de démontrer votre appréciation envers votre équipe. Ainsi, chacun reste motivé et va poursuive ardemment vers le prochain jalon de votre projet.
Dans cette brève vidéo, Tom Peters parle même d’art de définir et poser des jalons dans tous nos projets professionnels comme privés.
http://www.betterprojects.net/2018/02/remote-working-and-allen-curve.html par Craig Brown
La courbe de Allen est une observation faite dans les années 1970 que plus une personne est loin et moins il est probable qu’elle initie la communication.
Cette preuve soutient l’approche de la co-géolocalisation.
Tom Allen a reproduit l’expérience au début des années 2000 en partant de l’hypothèse que skype, l’email, les communications digitales et de meilleurs équipements audio et vidéo auraient réduit l’impact de ces phénomènes.
Constat principal: Initier le mouvement pour amorcer la communication est le point bloquant. Alors que des communications plus fréquentes sont les fondements d’une collaboration efficace.
L’hypothèse de travail actuelle et non testée est que les personnes plus jeunes ont passé davantage de temps en ligne et à collaborer sous forme digitale et que nous avons donc développé nos pratiques sociales pour nous connecter plus facilement.
Mon observation personnelle est que ceci est vrai pour certaines populations, mais ce n’est pas encore le défaut pour la majorité des personnes dans les équipes.
Quand vous choisissez de travailler à distance, vous devez vous attaquer très spécifiquement à ce problème.
http://www.virtualprojectconsulting.com/staying-relevant-as-a-pm/ par Derek Smith
Dans le monde numérique et disruptif actuel, les cadres et organisations font face à de féroces défis compétitifs qui exigent qu’ils s’adaptent continuellement, ou bien affrontent les conséquences de ne pas le faire et la possibilité de disparaitre totalement. Il en va de même pour les managers de projet. Ils/Elles doivent se tenir au courant ce qui change avec les méthodes Agiles et dans la philosophie du management de projet pour rester pertinents et employables.
Des pratiques flexibles Agiles et Lean, comme Scrum et Kanban qui étaient autre fois un domaine réservé aux développeurs de logiciels, sont idéalement positionnées pour générer le succès dans le business. Elles font des incursions significatives à l’extérieur du département informatique et trouvent l’acceptation et l’appui des dirigeants exécutifs. Les organisations ont besoin de sentir rapidement venir les changements externes et internes et de s’y adapter pour livrer des résultats efficaces et rentables, sans perdre de vue le fait que la gouvernance d’ensemble est toujours requise.
La recherche du succès commence aussi par choisir la bonne approche pour délivrer les projets. Certaines caractéristiques spécifiques des projets et des besoins organisationnels devraient former les bases du choix de l’approche la meilleure.
Alors que chacun saute sur le train en marche pour capitaliser sur la formation et l’adoption, et avec tant de choix quand on parle des approches, il peut être intimidant d’essayer de suivre les avancées sur comment ces pratiques se développent et lesquelles choisir. PMI a produit une série de rapports sur le leadership. Notons que les 6 rapports sont liés à atteindre une plus grande agilité.
Les rapports couvrent des sujets comme se concentrer sur le client, provoquer des retours fréquentes, choisir la bonne approche et transformer l’organisation en se concentrant sur les personnes et surveillant les progrès. Développer la collaboration entre des branches différentes du business, changer la culture et évaluer les besoins transverses aux entités fonctionnelles sont d’autres aspects primordiaux à considérer pour atteindre une agilité organisationnelle plus élevée.
Du point de vue de leur carrière, les managers de projet doivent continuer à être au fait des avancées pour rester recherchés et gagner des salaires convenables. PMI Pulse of the Profession® indique que les parties prenantes font le forcing pour adopter des pratiques agiles. Les organisations qui sont agiles et répondent rapidement à la dynamique des marchés, récoltent plus de bénéfices de leurs projets que celles qui ne le sont pas — 75% contre 56%, selon la recherche.
Il est pour cette raison que le PMBOK ® le Guide –Sixième Édition s’est enrichi de pratiques agiles et que le PMI® s’est associé avec Agile Alliance® pour créer le nouveau Agile Practice Guide.
La certification PMI-ACP® est actuellement celle qui connait la croissance la plus rapide au PMI et couvre beaucoup d’approches Agile comme Scrum, Kanban, Lean, la programmation extrême (XP) et le test-driven development (TDD).
“PMI,” the PMI logo, “PMP,” “PMBOK,” “PM Network,” “Project Management Institute” and “Pulse of the Profession” are registered marks of Project Management Institute, Inc.
A pratiquer tous les jours 🙂 pour que cela devienne une habitude, un réflexe inconscient.
Un parcours Management Stratégique et Changement (MSC) : 3ème Édition du PMPD – « Project management Profession Day ». Cet évènement rassemblera les 85 étudiants du Master 2 MSC et de nombreux professionnels du domaine du management de projets pour découvrir de façon ludique et inductive la conduite de projet.
Cet évènement original est organisé par des étudiants et des membres du PMI dans le but d’échanges et de découvertes intenses.
« L’école du Project Management Professional Day – Pour sensibiliser les étudiants de la région sur l’importance du Management de Projet, des étudiants en Master de SKEMA ont lancé avec PMI France Côte d’Azur une nouvelle manifestation : le Project Management Professional Day. A eux de l’organiser en utilisant la palette du PMI : Change Management, Agile, Scrum, Waterfall. La formation par la pratique. En matière d’éducation, rien ne vaut la pratique. Cette constatation est au cœur du projet pédagogique que Jean-Claude Dravet, ancien président de PMI France Cote d’Azur, coache actuellement à SKEMA Business School à Sophia dans le cadre d’un master de l’école monté en partenariat avec l’association azuréenne. Il s’agit d’organiser une nouvelle manifestation, baptisée PMPD (Project Management Professional Day), ce qui donne l’occasion aux étudiants de pratiquer le Project Management sur un projet réel, et de livrer un résultat concret. »
PMI is a registered mark of Project Management Institute, Inc.
Notre posture physique, comme se tenir bien droit et sourire, nous donne davantage d’énergie pour convaincre.
Le physique active le mental et influe ainsi énormément sur nos capacités !
Faites le test.
Relisez le billet Souriez chers chefs de projet car le sourire possède des « super pouvoirs » et regardez la vidéo de Ron Gutman
«
Écouter permet de comprendre son interlocuteurEn dédiant toute votre attention à la personne en face de vous. En cherchant aussi à identifier ce qui n’est pas dit, les sentiments ou ressentis, les besoins de cette personne.
Avant de nous inviter à rejoindre la révolution de l’écoute (ou par l’écoute), William Ury explique aussi pourquoi il est si difficile d’écouter vraiment : Sans jugement, sans préparer sa réponse pendant que l’autre s’exprime, sans interrompre…
http://www.johngoodpasture.com/2018/02/accurate-v-fairness.html par John Goodpasture
Utilisez-vous beaucoup de données dans votre projet ? C’est le cas de presque chacun d’entre nous.
Il y a de nombreux livres et sites Web qui expliquent les biais qui sont construits dans les données, même inconsciemment. Kahneman et Tversky ont probablement certains des meilleurs éléments sur ce sujet.
Vous vous y êtes probablement confrontés à l’école : Ajustement des notes de chacun dans la classe par rapport à une courbe de distribution optimale (Bell Curve). Les notes étaient une chose objective, mais leur ajustement relève de quelque chose d’autre.
La justice c’est l’impact : Quelles sont les conséquences d’avoir appliqué les résultats fournis par les données à un problème ?
Quand des personnes humaines sont impliquées, ceci est encore plus le cas avec la compétition, les classes, l’antagonisme gagnant-perdant, les animosités.
Dans le bureau de projet, le premier instinct est (ou devrait être) l’objectivité.
Mais alors, l’objectivité rencontre les objectifs du management (politiques, humanitaires, économiques, de justice sociale, de compétition) et avant que vous ne le sachiez, vous êtes de retour à « l’ajustement par la courbe de distribution ».
Si « correct » et « exact » ne sont pas la même chose, c’est qu’il y a une différence.
Et, quelle est la nature de cette différence ? C’est le risque !
Et, qui manage des risques ? Le PMO, naturellement !
« Aujourd’hui nous annonçons l’initiative Help a Project Manager Out! (HAPMO!) . C’est une initiative bénévole conçue pour aider toute personne qui a un intérêt ou une passion pour livrer des projets. Votre titre ou industrie ne sont pas discriminants. Peu importe si vous menez actuellement des projets ou espérez le faire un jour.
Deux fois par mois je posterai un article qui ressemble à celui-ci. Typiquement ce sera en début et milieu de mois.
Répondez par un commentaire avec les renseignements pertinents que vous souhaitez partager avec vos collègues du monde entier. Indiquez l’opportunité ou le poste que vous recherchez. Nous avons des personnes dans des rôles de leadership partout dans le monde qui pourraient vous aider dans vos recherches en partageant des conseils ou en facilitant les introductions.
Posez votre question en commentaire. Qu’il s’agisse d’une certification liée au PMI ou pas, des professionnels qui ont déjà suivi cette voie peuvent soit répondre directement à votre question, soit vous orienter vers des ressources pour vous aider.
Laissez un commentaire avec votre question ou situation. Certains des plus grands managers de projets pourraient tout simplement partager leurs pensées en retour.
Surveillez les commentaires. La personne que vous cherchez pourrait être là.
Soyez à l’affût des gens qui s’engagent ici et qui tentent de vous répondre. Connectez-vous et commencez à communiquer avec eux.
Partagez votre opinion. »
https://www.axelos.com/news/blogs/october-2018/prince2-agile-for-prince2-practitioners par Julia Gosse
A quels défis PRINCE2® les praticiens et leurs employeurs font-ils face avec le concept de livraison de projet Agile ?
Le plus grand défi consiste en ce que le terme « Agile” est souvent mal compris : les gens pourraient faire des raccourcis comme « juste plus vite »; ils pourraient avoir entendu dire que c’est seulement pour les projets informatiques, qu’il relève seulement de Scrum ou que leurs contraintes légales les empêchent d’utiliser.
Les projets agiles aboutissent souvent à une livraison plus rapide mais Agile est un état d’esprit. Cela signifie accepter que votre projet ne livrera pas nécessairement tout qui a été spécifié au départ et que, en effet, les utilisateurs n’ont pas nécessairement besoin de tout ce qu’ils ont spécifié.
Quand vos délais sont figés vous devez vous concentrer sur quelles sont les réelles priorités. Se précipiter pour tout délivrer peut diluer le résultat et réduire le niveau de qualité, quelque chose qui reviendra vous hanter plus tard. Un projet Agile préfère ne pas livrer une chose si elle n’est pas à la norme exigée, mais tout dans l’approche est conçu pour s’assurer que ce qui est livré apportera de la valeur au client.
Des approches de livraison Agiles sont de plus en plus utilisées avec beaucoup de succès dans les projets en dehors de l’informatique. J’ai récemment travaillé avec une société d’événementiel utilisant Agile pour planifier et organiser une grande conférence. C’était particulièrement utile pour ce projet qui avait une durée imposée et des coûts fixes.
Davantage d’organisations et praticiens expérimentés avec PRINCE2 gèrent bien cette approche et voient Agile comme un outil très utile. En conséquence, ils adoptent certaines approches comme la co-localisation de l’équipe de projet, l’utilisation d’interactions régulières et la collaboration avec clients et utilisateurs.
Vous avez déjà obtenu un niveau de contrôle et une terminologie que vous comprenez et les organisations PRINCE2 sont expertes pour adapter PRINCE2 à des projets différents.
Il y a beaucoup de saveurs différentes d’Agile et bien que Scrum soit probablement la plus populaire, ce n’est pas la seule approche de développement Agile. PRINCE2 n’a jamais été normatif dans la définition de comment vous livrez un projet et PRINCE2 Agile peut travailler avec une ou de nombreuses approches Agiles, y compris Scrum, Kanban et DevOps. Cela garantit que l’équipe de management de projet comprend comment s’interfacer avec l’approche de livraison Agile.
Il est important de comprendre que PRINCE2 Agile est toujours centré sur le management de projet et que l’équipe devra être formée dans l’approche (ou les approches) de livraison Agile qu’ils adoptent.
Dans PRINCE2 le manager exécutif représente les intérêts de l’organisation; appliquer ceci à l’environnement Agile est une approche gagnante car vous maintenez la perspective business. Cela assure que les utilisateurs ne se laissent pas emporter par leurs demandes et ce qui est livré répond aux exigences d’affaires. Cela résonne bien dans le monde Agile parce que la livraison de valeur est le principal déterminant pour donner la priorité à ce qui devrait être livré ensuite.
Essentiellement c’est un outil d’évaluation de risque pour aider évaluer à quel point Agile est approprié pour un projet donné. Même dans un projet prédictif (en cascade) vous pouvez incorporer quelques éléments Agiles, donc l’Agilomètre permet aux organisations d’évaluer les implications de procéder ainsi.
Dans PRINCE2 Agile® Guidance, on trouve aussi une façon unique d’adresser les questions potentielles liées à l’introduction des méthodes agiles. Par exemple, des assomptions dérangeantes sur les besoins devant être spécifiés au début d’un projet, comment adresser la résistance à un plus grand niveau de collaboration et penser à de la formation ou des ateliers pour encourager l’acceptation d’Agile dans le management de projet.
Les exigences et les attentes des utilisateurs dans un monde de haute technologie augmentent et les gens sont moins enclins à accepter des produits ou des systèmes périmés ou attendre pendant des mois et même des années pour les remplacer.
L’utilisation des apps sur les téléphones portables encouragent des retours et de nouvelles versions fréquentes. Nous devenons tous très habitués du style de livraison collaboratif, itératif et progressif qu’Agile favorise.
L’union des contrôles de management de projet de PRINCE2 avec la connaissance et des capacités Agiles facilite une plus grande adaptabilité aux changements sur les marchés et donne une capacité de répondre et de changer beaucoup plus rapidement.
DantotsuPM.com 