L’exposition au risque est en fait plus élevée au début.
Voyons donc comment réduire l’exposition aux risques dès le début de vos projets.
Pourquoi l’exposition au risque est la plus forte au début ?
Les managers de projet ont à ce moment-là le moins d’informations. L’incertitude est la plus grande.
Vous savez très peu de choses sur :
Objectifs du projet
Livrables
Exigences
Budget
Contraintes
Critères de succès
Disponibilité des ressources
Voici 5 activités que vous pouvez entreprendre pour réduire l’exposition au risque dès le début du projet.
Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes
Réduisez au plus tôt votre exposition aux risques
#1 – Déterminez les parties prenantes à contacter
Avez-vous déjà vu un manager de projet ou un sponsor de projet tenir délibérément une partie prenante dans l’ignorance ?
vers un engagement efficace des parties prenantes : Relisez ce billet
Cette personne découvre le projet plus tard et exerce alors son pouvoir et son influence. Cela entraîne souvent des choses à refaire et des impacts négatifs sur l’échéancier et le budget. Identifiez vos parties prenantes tôt et cherchez à comprendre leurs préoccupations et leurs intérêts.
#2 – Mettez tout le monde sur la même longueur d’onde
Si vous demandez à deux personnes d’expliquer la raison d’être d’un nouveau projet, vous pouvez obtenir des réponses totalement différentes.
Travaillez avec le sponsor du projet, l’équipe projet et les parties prenantes pour rédiger la charte de projet initiale.
Les chartes de projet comprennent, sans toutefois s’y limiter :
Titre du projet
Description
Objectifs du projet
Livrables
Hypothèses et contraintes
Critères de succès
Résumé des jalons
Budget à haut niveau
Exigences principales
Risques majeurs (menaces et opportunités)
Parties prenantes
Ces éléments peuvent grandement améliorer le focus, la compréhension et l’alignement de votre équipe et des parties prenantes.
#3 – Clarifiez les objectifs de votre projet
Au début des projets, les objectifs sont souvent définis de manière vague, ce qui entraîne des malentendus. Travaillez avec votre sponsor de projet pour définir, clarifier et communiquer les objectifs.
Objectif = Verbe + Focus + Cible + Délai
Voici une syntaxe suggérée pour les objectifs : Verbe -> Focus -> Cible -> Délai. Par exemple : « Augmenter les bénéfices de 5 % avant la fin de l’année. » L’utilisation de cette syntaxe garantit la cohérence de vos objectifs et permet de vous assurer que vos objectifs sont spécifiques et mesurables.
Le PMBOK V7 sur Amazon
Objectif.
Quelque chose vers lequel le travail doit être orienté, une position stratégique à atteindre, un but à atteindre, un résultat à obtenir, un produit à produire ou un service à exécuter. PMBOK®, 7ème édition
#4 – Identifiez les risques
Dans les premières étapes d’un projet, nous n’avons pas encore identifié les risques. Il existe de nombreux outils et techniques qui peuvent vous aider, vous, votre équipe de projet et vos parties prenantes à identifier les risques tels que :
Techniques de collecte d’information (p. ex., remue-méninges, entrevues, Delphi)
Techniques de création de diagrammes (p. ex., diagrammes de contexte, organigrammes)
SWOT / FFPM (c.-à-d. forces, faiblesses, possibilités et menaces)
Pré-mortem. Décrivez un projet hypothétique échoué ou contesté à votre équipe de projet. Demandez à votre équipe d’identifier les risques et de déterminer les réponses aux risques.
Liste d’invites. Il s’agit d’une liste de catégories qui incite les intervenants à identifier des risques supplémentaires dans chaque catégorie.
Analyse de la liste de contrôle. Il s’agit d’une liste de risques potentiels utilisée pour aider à identifier les risques supplémentaires.
Examens de documents. Examiner les documents relatifs au projet et aux projets connexes.
De plus, vous pouvez utiliser une combinaison de techniques. Par exemple, vous pouvez faire un exercice de remue-méninges, suivi par un examen d’une checklist de contrôle.
#5 – Clarifiez les attentes des parties prenantes
Certaines personnes pensent que vous pouvez lire dans leurs pensées. Lorsque vous interagissez avec les dirigeants, les membres de l’équipe de projet et autres parties prenantes, posez des questions explicites sur leurs attentes.
Que désirent-ils du projet ? Que s’attendent-ils à ce qu’il se passe pendant le projet ? Quelles attentes n’ont pas été exprimées par eux ou par d’autres ?
À vous de jouer !
Vous démarrez un projet ? Prenez le temps d’examiner votre projet à la lumière de ces cinq principes. Épargnez-vous quelques maux de tête en aval en réduisant votre exposition au risque dès maintenant.
“PMI,” the PMI logo, “PMP,” “PMBOK” and “Project Management Institute” are registered marks of Project Management Institute, Inc.
partagez ce billet avec vos amis, collègues et relations professionnelles
Voici 7 façons dont les leaders peuvent gagner le respect de leurs employés
#1 – Communiquez clairement et efficacement.
Les leaders peuvent gagner le respect de leurs employés en communiquant clairement et efficacement. Pour ce faire, ils peuvent transmettre leurs idées, leurs objectifs et leurs attentes de manière claire et concise. Ils peuvent utiliser une variété de canaux et de méthodes de communication pour atteindre tous les membres de l’équipe. De plus, les leaders doivent s’assurer que leur communication est cohérente et transparente, et qu’elle fournit aux employés l’information et les conseils dont ils ont besoin pour faire leur travail efficacement.
#2 – Écoutez activement et attentivement.
Écoutez avec attention surtout si vous êtes à distance et n’avez pas de compléments visuels à la communication.
Les leaders peuvent gagner le respect de leurs équipes en écoutant activement et attentivement leurs commentaires, leurs idées et leurs points de vue. Cela implique de dialoguer avec les membres, de poser des questions et de leur donner l’occasion de contribuer et de participer à la prise de décisions. Ainsi, les leaders démontreront qu’ils apprécient la contribution de leurs équipes et sont prêts à l’intégrer à leur processus décisionnel.
#3 – Fournissez du soutien et des ressources.
Les leaders peuvent gagner le respect des équipes en leur fournissant le soutien et les ressources dont elles ont besoin pour réussir. Cela implique de fournir aux membres les outils, la formation et les conseils nécessaires pour qu’ils puissent s’acquitter efficacement de leurs rôles. De plus, la connexion régulière, fournir des commentaires et le coaching les aideront énormément à se développer et à s’améliorer.
#4 – Fixez des objectifs et des attentes clairs.
Cliquez sur cette image pour un billet détaillé.
Les leaders peuvent gagner le respect de leurs équipes en fixant des objectifs et des attentes clairs pour leur équipe. Cela implique de définir des objectifs spécifiques, mesurables et réalisables. De plus, les leaders peuvent fournir des nouvelles et des commentaires réguliers pour aider les employés à rester sur la bonne voie et à atteindre leurs objectifs. Ce faisant, les leaders peuvent démontrer qu’ils sont engagés dans le succès de leur équipe et qu’ils leur fournissent les conseils dont ils ont besoin pour atteindre leurs objectifs.
#5 – Faites preuve d’empathie et de compréhension.
N’hésitez pas à découvrir et utiliser les cartes d’empathie.
Les leaders peuvent gagner le respect de leurs équipes en faisant preuve d’empathie et de compréhension. De plus, cela implique d’être conscient et sensible aux émotions et aux expériences des membres, et cela implique d’être solidaire et compatissant en réponse à leurs besoins et à leurs défis.
CSP DOCENDI est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
#6 – Soyez transparent et honnête.
Les leaders peuvent gagner le respect de leurs équipes en faisant preuve de transparence et d’honnêteté. Cela implique d’être ouvert et honnête dans la communication. En outre, cela implique d’être transparent et honnête dans la prise de décision et la résolution de problèmes.
#7 – Reconnaissez et appréciez les réalisations.
Les leaders peuvent gagner le respect de leurs équipes en reconnaissant et en appréciant leurs réalisations et leurs contributions. Cela implique de reconnaître et d’apprécier régulièrement les efforts et les réalisations des membres de l’équipe. En outre, cela implique de fournir des récompenses et des incitations pour les motiver et les inspirer.
Ces 7 actions et attitudes peuvent aider les leaders à gagner le respect des membres de leurs équipes et à constituer des équipes solides, collaboratives et productives.
Dirigez de l’intérieur: La meilleure façon pour les leaders de gagner le respect de leurs équipes est de toujours respecter leurs comportements et leurs actions.
partagez ce billet avec vos amis, collègues et relations professionnelles
Les prescriptions médicamenteuses sont des solutions dangereuses. Il est effrayant de lire tous leurs potentiels effets secondaires.
Deux personnes sur un million ont cultivé telle ou telle maladie en prenant ce médicament. Ne détesteriez-vous pas en mourir ?
Mais, plus sérieusement, il est vrai que certaines solutions peuvent vraiment vous assassiner.
Solutions dangereuses
#1. Les solutions dangereuses multiplient les problèmes.
Les solutions sont dangereuses lorsque vous diagnostiquez le mauvais problème. L’autre jour, mon médecin m’a dit que ma tension artérielle était élevée. J’ai dit : « Oui, ça augmente chaque fois que je vous rends visite. Je n’ai pas besoin de médicaments pour la tension artérielle. Vous devez arrêter de me faire trembler. Quel est le remède à l’anxiété causée par les médecins ? »
Vous déterminez que la faible performance est un problème de travail d’équipe. Mais peut-être que les gens ont besoin de savoir ce qui est important. Arrêtez de changer frénétiquement de direction. Ne planifiez pas d’exercices de travail d’équipe lorsque le problème est en fait vous-même.
Et si le problème est un mauvais leadership ?
Le problème pourrait-il venir de vous ?
Peut-être avez-vous besoin de travailler sur vous-même, pas sur eux.
Voici des questions pour mettre en lumière les réels problèmes:
En quoi puis-je contribuer à ce problème ?
Et si le problème apparent n’était pas le vrai problème ?
Qu’est-ce qui pourrait causer ce problème ?
Quels processus ou procédures nuisent à la productivité ?
Qui fait la mauvaise chose ? N’interrompez pas les employés les plus performants.
#2. Les solutions dangereuses ignorent les comportements.
Il est plus facile d’instituer de nouvelles directives et procédures que de traiter avec les gens. Quand quelqu’un dit : « Nous nous sommes plantés », demandez : « Qui a foiré ? » Écoutez pour obtenir des noms spécifiques, pas un « nous » ambigu.
Les réponses ambiguës ne résolvent pas des problèmes spécifiques. Travailler plus fort n’est pas la solution quand les gens travaillent déjà plus fort.
Les problèmes que vous définissez en termes de comportements peuvent être résolus.
Que font les gens pour causer cette situation ?
Qu’est-ce que les gens laissent de côté et qui cause cette situation ?
#3. Les solutions dangereuses vont trop loin pour résoudre les problèmes.
Quelle serait la solution la plus simple ?
N’amputez pas votre pied pour guérir une mycose des orteils. Peut-être votre mal de tête n’est-il pas un cancer du cerveau.
À quelle fréquence ce problème se produit-il ?
Quelle est la solution la plus simple que nous puissions concevoir ?
Quand la résolution de problèmes crée-t-elle plus de problèmes qu’elle n’en résout ?
partagez ce billet avec vos amis, collègues et relations professionnelles
Abraham Maslow a abordé l’estime avec le quatrième niveau de sa hiérarchie des besoins et Adrian Gostick et Chester Elton ont écrit le livre à ce sujet dans The Carrot Principle (le principe de la carotte).
Cela n’a pas besoin d’être formel. Distribuer trop souvent des récompenses financières ou des trophées dilue leur valeur. De plus, vous n’avez peut-être pas de budget pour des récompenses tangibles.
Cela ne devrait pas être ressenti comme forcé.
Il est presque aussi mauvais d’établir un planning de reconnaissance des membres de l’équipe que de ne pas en faire du tout. Comme la rétroaction, l’appréciation est meilleure lorsqu’elle est « dans l’instant » et proche du moment où l’action qui a provoqué l’appréciation s’est produite.
Cela ne devrait pas toujours être nous en tant que leaders qui la donnons.
Lorsque vous voyez tous les membres de votre équipe participer activement à l’appréciation informelle d’autres membres de l’équipe sans y être invités, vous savez que l’équipe a intégré cela dans son ADN.
Elle doit aller au-delà des livrables.
Ceux-ci sont importants, mais pourraient être réalisés au détriment de la santé de l’équipe. Nous devons considérer non seulement ce que les gens ont fait, mais aussi comment ils l’ont fait. Les changements de comportement sont difficiles, et si quelqu’un a fait des progrès en agissant sur la base de retours constructifs, cela devrait être reconnu même s’il n’a pas atteint son objectif. Les équipes où l’appréciation n’est donnée que lorsque les choses vont bien indiquent effectivement que le succès est la seule chose qui compte.
CSP DOCENDI est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
Avec une équipe virtuelle, il peut être un peu plus difficile de semer les graines de l’appréciation, alors voici quelques façons de le faire.
Soulevez le sujet de l’appréciation avec l’équipe quand elle définit ses valeurs et ses règles de travail. Demandez-leur des idées sur ce qu’ils estiment valoir la peine d’être apprécié et comment ils aimeraient s’apprécier les uns les autres. Cela pourrait inclure la façon dont l’appréciation peut être exprimée avec les différents outils de collaboration virtuelle que l’équipe utilise. Les likes ou les emojis positifs peuvent être utilisés pour les outils basés sur le chat, tandis que les étoiles, les cœurs ou autres autocollants positifs peuvent être utilisés sur les tableaux blancs ou les tableaux virtuels.
Suggérez aux membres de l’équipe de partager des événements personnels clés tels que les anniversaires dans le calendrier en ligne de l’équipe pour permettre aux membres de l’équipe d’identifier plus facilement ces jalons.
Intégrez des moments d’appréciation dans vos événements d’équipe. Une approche pourrait être de prendre les dix premières minutes de chaque réunion d’équipe hebdomadaire pour donner aux membres de l’équipe une chance de remercier publiquement quelqu’un d’autre de l’équipe qui les a aidés au cours de la semaine. J’ai constaté que dans des événements tels que les rétrospectives, cela se traduit par des résultats de meilleure qualité, surtout si l’équipe a rencontré des difficultés avant la rencontre.
Créez un tableau d’appréciation dans votre espace virtuel où les membres de l’équipe peuvent s’afficher des cartes de remerciement.
Les avantages de la reconnaissance que nous recevons sont comme les grains de sable dans un sablier. Créer une culture d’appréciation au sein de nos équipes est un moyen de s’assurer que le sable ne s’épuise jamais.
partagez ce billet avec vos amis, collègues et relations professionnelles
Alors que PMI Global publie comme chaque année les tendances sur l’emploi en management de projets, revenons aussi sur la genèse et l’histoire du PMI en France à travers plusieurs membres emblématiques.
Pour rester compétitives, les entreprises devront se concentrer sur l’embauche de personnes capables de résoudre les problèmes et de construire des relations qui les aideront à conduire le changement et à générer une valeur stratégique.
Voici de quoi soutenir et même accroître la demande de managers de projet qui ont acquis les power skills (compétences relationnelles) et vont aider leurs employeurs à traverser les turbulences. Ceci est particulièrement vrai en Europe avec la crise énergétique et climatique, ainsi que la dramatique guerre en Ukraine alors que le monde du tourisme a fortement redémarré.
Savoir où les opportunités sont les plus susceptibles d’émerger et de se développer rapidement vous permet en tant que professionnel des projets de dénicher des opportunités de carrière.
Sans surprise, la communication reste la compétence la plus importante, suivie de la résolution de problèmes, du leadership collaboratif et de la réflexion stratégique.
Zoom sur le PMI france avec ces 3 vidéos
1. Jean Claude DRAVET : PMI France depuis 1995…
2. Impact social – Christian Jacques Bonetto : PMIEF
3. Membership & volontariat
Envie de rejoindre notre communauté de chef de projet ? Comment rejoindre PMI France ? Plus d’information ici : https://pmi-france.org/etre-membre
“PMI,” the PMI logo, “PMP,” “PMBOK,” “PM Network,” “Project Management Institute” and “Pulse of the Profession” are registered marks of Project Management Institute, Inc.
partagez ce billet avec vos amis, collègues et relations professionnelles
Les principales parties prenantes exercent parfois une pression importante pour atteindre des objectifs de projet irréalistes. Repousser ces demandes peut mettre sur les nerfs même le/la manager de projet le/la plus expérimenté(e) !
Et il peut être difficile de convaincre ces parties prenantes de changer leurs objectifs ou leurs perspectives. Que faites-vous lorsque vous ne pouvez pas changer l’avis des parties prenantes ?
Adoptez un processus qui vous permettra de gérer les attentes et de faire avancer le projet.
Voici une approche en 4 étapes pour tirer le meilleur parti des attentes déraisonnables.
Étape 1 – Partagez les faits.
Développez un argumentaire simple et direct qui décrit vos préoccupations concernant le projet. Utilisez les données antérieures du projet, les documents de référence de l’industrie et les préoccupations présentées par les leaders techniques. Votre message est susceptible d’être considéré comme une mauvaise nouvelle, alors soyez prêt pour une forte réaction. Cela peut nécessiter plusieurs tentatives pour faire passer votre message, alors soyez persévérant pour faire entendre votre message. Tenez-vous-en aux faits. Ne laissez pas les réactions des parties prenantes détourner votre message en une discussion émotionnelle. Vous partagez des informations sur les risques qui doivent être traités. Gardez à l’esprit que ce n’est pas votre travail d’empêcher les hauts dirigeants de prendre des risques. Votre travail en tant que manager de projet consiste à vous assurer que les parties prenantes reconnaissent les risques que présente le projet. Après votre discussion, traitez les directives que vous recevez du mieux que vous pouvez.
Étape 2 – Comprenez leurs perspectives.
Qu’est-ce qui est réellement important dans le projet pour cette partie prenante ?
Partagez les risques du projet avec un public plus large et écoutez les points de vue supplémentaires de ces parties prenantes. Les membres de l’équipe technique peuvent être surchargés de problèmes ou avoir un volume de travail déraisonnable. Certaines parties prenantes peuvent avoir des intérêts pour leur propre équipe qui entrent en conflit avec la meilleure option pour l’ensemble de l’organisation. Toutes ces choses peuvent finir entre vos mains pour être traitées. Soyez compréhensif et souvenez-vous : Vous ne pouvez aborder les problèmes dans une discussion transparente seulement si les parties prenantes mettent leurs problèmes sur la table. Aidez les autres à comprendre ces perspectives divergentes et générez des discussions pour explorer une chemin plus dégagé pour faire avancer le projet.
Étape 3 – Soyez prêt à faire des compromis.
Ne soyez pas inflexibles. Au fur et à mesure que les conversations que vous organisez se déroulent, certaines de vos tentatives pour réduire les risques du projet peuvent être rejetées. Recherchez une position raisonnable dans le management des risques qui vous permette de faire des progrès positifs vers la réalisation du projet.Le chemin à suivre n’est peut-être pas parfait. Cependant, une amélioration de 80% de votre situation est probablement préférable à une détérioration irrémédiable d’une relation pour atteindre les 90 ou 100%. Lorsque l’environnement pour la livraison du projet n’est pas idéal, mettez en place une surveillance supplémentaire pour remonter les problèmes dès que possible. Discutez de ces sujets de préoccupation avec votre sponsor et lors de vos réunions de projet hebdomadaires.
Étape 4 – Montrez le chemin emprunté par votre projet.
Capitalisez sur votre surveillance pour identifier les problèmes. Créez des mesures qui montrent l’impact des zones de risque sur le projet. Partagez le chemin emprunté par votre projet avec les parties prenantes. Par exemple, si vous craignez que les ressources techniques clés ne soient pas disponibles pour consacrer suffisamment de temps à votre projet, établissez un temps minimum nécessaire pour livrer votre projet dans les délais. Surveillez les heures réelles que votre ressource critique consacre au projet et l’état d’achèvement de ses tâches. Signalez vos résultats lors des réunions d’état d’avancement pour tenir les gens informés de l’état du risque. Si les préoccupations que vous avez soulevées plus tôt (à l’étape 1) ont un impact, vous aurez des données concrètes pour justifier votre préoccupation, et vos parties prenantes seront plus susceptibles d’appuyer les changements dont vous avez besoin pour mener à bien votre projet. Si tout va bien, ne soyez pas complaisant ! Poursuivez la surveillance jusqu’à ce que la possibilité de risque soit éliminée.
Avez-vous des recommandations pour traiter les demandes déraisonnables ? Partagez-les avec nous !
Lorsqu’un client, un patron ou un employé fait une demande spéciale, il est normal de se montrer un peu flexible. Cela pourrait vous coûter du temps ou de l’argent supplémentaire, cela pourrait être un problème, cela pourrait ne pas être mérité.
Ou bien, vous pouvez dire non.
Mais si vous dites oui, alors il est payant que vous y soyez à 100%.
Si vous ne l’êtes pas, votre oui ne valait rien. Cela cesse d’être une faveur si cela vient en râlant.
Tenir rancune signifie que vos mains sont trop encombrées pour réaliser votre meilleur travail.
partagez ce billet avec vos amis, collègues et relations professionnelles
Demain est comme hier, mais peut-être un peu plus vite ou moins cher.
Les systèmes industriels prospèrent grâce à leur prévisibilité. Il lisse la chaîne d’approvisionnement, améliore l’efficacité et rendent bon nombre de participants plus à l’aise.
Demain est comme hier, mais peut-être un peu plus vite ou moins cher.
Mais les ruptures, la créativité et les connexions humaines ne viennent pas de la prévisibilité. Elles proviennent d’interactions imprévisibles avec des idées et des voix inconnues.
Presque tous les best-sellers sont des best-sellers surprises. Toutes les grandes idées sortent de façon inopinée, du côté gauche par exemple.
Un best seller qui fut une surprise sur Amazon
Mais si vous passez votre temps à regarder du côté gauche, elles sortiront du côté droit à la place.
Le chaos est inconfortable, surtout si vous avez été endoctriné dans la mentalité industrielle. Mais si les bonnes personnes et les bonnes conditions sont présentes, le chaos crée des possibilités.
Faites-le avec intention.
partagez ce billet avec vos amis, collègues et relations professionnelles
Tous les projets ne sont pas adaptés aux approches agiles. Des critères bien pensés peuvent vous aider à déterminer si vos projets sont de bons candidats agiles.
Voici des questions que vous pouvez utiliser pour développer vos propres critères de qualification pour Agile :
Pouvez-vous obtenir le bon personnel ?
Les membres appropriés de l’équipe technique et métier doivent être dédiés au projet. Cela signifie que vous devez gérer les compromis difficiles entre le travail de projet et les considérations opérationnelles. Les projets agiles produisent des résultats rapidement, ils prennent donc beaucoup de temps aux participants. De plus, les approches agiles nécessitent des membres essentiels des équipes business et technique qui sont critiques à vos activités opérationnelles. Il est important de prioriser leur temps sur le projet afin qu’ils puissent contribuer efficacement.
Les ressources ont-elles une profondeur de connaissances appropriée ?
Une connaissance approfondie des domaines business et techniques liés au projet est cruciale. L’approche agile repose sur des experts métier travaillant en étroite collaboration avec les experts de l’équipe technique. Ce qui rend les méthodologies agiles Agile, c’est la réactivité à l’évolution des besoins. Les techniciens et les personnes du business compétents doivent constamment réévaluer les livrables du projet, les besoins de l’entreprise aux niveaux macro et micro et la priorité des fonctionnalités requises par le client final.
Le Sponsor a-t-il un état d’esprit Agile ?
Le sponsor doit être disposé à participer à des revues fréquentes du produit en construction, qui sont fondamentales dans l’approche agile. La réactivité agile aux conditions changeantes de l’entreprise et son environnement évolutif sont très différentes des méthodes de projet traditionnelles. Si un sponsor veut un ensemble linéaire et méthodique d’objectifs livrés selon un calendrier prédéfini, il aura du mal avec les livrables du projet en approche agile. Les sponsors qui sont mal à l’aise avec la nature évolutive de l’agilité créent des difficultés qui peuvent couler le projet.
L’équipe peut-elle être co-localisée (physiquement ou virtuellement) ?
Agile implique un dialogue profond, interactif et parfois difficile. Pour tirer le meilleur parti de ce dialogue, vous devez créer l’environnement le plus riche possible. Co-localisez les membres de votre équipe de projet si possible. Si vous ne pouvez pas, simulez la colocalisation avec les meilleurs outils vidéo et audio que vous pouvez obtenir. Essayez de faciliter un dialogue agile avec des outils de communication médiocres, c’est comme essayer de remorquer une caravane avec une tondeuse à gazon.
Existe-t-il une synergie entre les membres de l’équipe business et technique ?
Une équipe agile doit bien s’entendre pour réussir. Les méthodologies agiles nécessitent le dévouement d’experts business et techniques qui sont ouverts à soutenir de nouvelles idées et à se soutenir les uns les autres en tant qu’individus. Vous avez besoin d’un coach agile qui comprend et peut gérer la dynamique humaine, et qui peut favoriser un environnement où les membres de l’équipe partagent facilement leurs idées et leurs préoccupations.
Le produit peut-il être construit (et livré) de manière itérative ?
Les meilleures qualités des approches Agile proviennent de la fourniture de solutions partielles tout en apprenant de chaque itération. En plus des livrables logiciels, d’autres produits peuvent également être construits de cette façon. Avec un peu de créativité, des déménagements, la mise en œuvre de nouveaux processus et même certains projets de construction dans le bâtiment peuvent utiliser des approches agiles.
Utilisez-vous d’autres critères pour déterminer si un projet est candidat à une approche agile ?
Si oui, partagez-les avec nous !
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
Que vous ayez suivi un cours de base en management de projet qui couvrait les pratiques pour les approches prédictives ou que vous étudiiez pour passer l’examen PMP®, vous êtes probablement familier des diagrammes de réseau de planification. Cependant, comme beaucoup d’outils et de pratiques dans le guide PMBOK, ce n’est pas parce que nous apprenons à les connaître que nous allons les utiliser.
Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes
Si vous omettez de créer un diagramme de réseau, vous risquez de passer à côté des bénéfices qui suivent.
Construire un diagramme de réseau est un exercice de « team building », de cohésion d’équipe, amusant. Que vous le fassiez sur un tableau blanc à l’aide de notes autocollantes ou sur une plate-forme de collaboration virtuelle, c’est une bonne opportunité pour les membres de l’équipe de différents domaines fonctionnels de comprendre comment nous allons progresser du début à la fin.
Cela accroît l’adhésion de l’équipe aux échéances du projet. En contribuant à la création du diagramme, il y a un plus grand sentiment de propriété de l’échéancier final.
Le diagramme de réseau capture la logique de planification d’une manière facile à comprendre et à expliquer. Guider une partie prenante à travers un diagramme de Gantt détaillé, en particulier lorsqu’il existe plusieurs chemins parallèles, peut être un exercice frustrant pour vous et votre public !
Il est plus facile de remarquer si vous avez commis une erreur de planification. Une fois que quelques centaines de tâches sont saisies dans un outil de planification et que des dépendances ont été ajoutées, localiser une activité manquante peut être comme essayer de trouver la proverbiale aiguille dans une meule de foin. D’autre part, la navigation dans les activités dans un chemin sur un diagramme de réseau est plus intuitive et les activités manquantes et les dépendances inutiles ou manquantes peuvent être identifiées plus rapidement.
Cela rend la création du planning plus efficace. Si vous avez déjà vu un manager de projet batailler pour capturer des données dans un outil de planification devant son équipe, vous apprécierez la réduction de perte de temps lorsque le même manager de projet peut prendre un diagramme de réseau complet et le saisir hors ligne dans l’outil, puis partager le produit final avec l’équipe.
Dans certaines situations, il peut être judicieux d’omettre le diagramme de réseau.
Si votre projet se prête à une approche entièrement adaptative et que la séquence des éléments de travail change fréquemment, et qu’en même temps vous devrez peut-être intégrer une compréhension des dépendances lors de la priorisation de l’arriéré de produit ou de la file d’attente de travail, un diagramme de réseau deviendrait très rapidement obsolète.
Si c’est simple et facile…
Si le projet est simple et comporte un nombre minimal de chemins réseau, un diagramme de réseau peut être exagéré. Enfin, si votre projet est très similaire à un projet historique et que vous pouvez réutiliser la planification de ce projet précédent avec un minimum d’effort, un diagramme de réseau peut aussi être inutile.
Mais en dehors de ces situations, les bénéfices de produire un diagramme de réseau en tant qu’entrée principale de votre échéancier de projet seront bien réels.
100 autres leçons sur le leadership de projet
Si vous avez aimé cet article, pourquoi ne pas lire mon livre Easy in Theory, Difficult in Practicequi contient 100 autres leçons sur le leadership de projet ?
partagez ce billet avec vos amis, collègues et relations professionnelles
J’aimerais que chaque personne en position de leadership comprenne à quel point la reconnaissance est importante pour ses équipes. Les personnes qui les composent ne veulent pas seulement de la reconnaissance, elles en ont besoin. Pour beaucoup de gens, la reconnaissance est le carburant de leur moteur de productivité.
La plupart des gens souhaitent faire plaisir aux gens et l’une des personnes auxquelles ils veulent le plus faire plaisir est leur patron.
Ils veulent quelques choses en échange de faire plaisir à leur patron et l’une de ces choses est le « crédit » ou la reconnaissance d’un travail bien fait. S’ils ne reçoivent pas ce crédit, beaucoup d’entre eux perdent leur motivation à continuer à donner le meilleur d’eux-mêmes.
Et c’est une erreur.
Aucun d’entre nous ne devrait donner à quelqu’un d’autre ce genre de pouvoir sur une partie de notre vie.
CSP DOCENDI est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
Les personnes qui réussissent le mieux ne cherchent pas la reconnaissance et l’affirmation, elles regardent à l’intérieur d’elles-mêmes.
Savoir qu’elles ont fait de leur mieux les motive. Leur opinion d’elles-mêmes est plus importante que celle de quelqu’un d’autre.
Nous voulons tous la reconnaissance et le soutien des personnes pour lesquelles nous travaillons. Mais le vouloir et en avoir besoin sont deux choses très différentes. Reconnaître vos propres efforts est beaucoup plus important, ou devrait l’être, que la reconnaissance de quelqu’un d’autre.
Appréciez absolument toute reconnaissance et tout soutien que vous recevez de quelqu’un d’autre. Mais ne dépendez pas d’eux pour continuer.
La seule raison pour laquelle vous devez continuellement donner le meilleur de vous-même dans tout ce que vous faites est la suivante: VOUS méritez votre meilleur effort. Vous méritez d’être le meilleur que vous pouvez être dans tous les domaines de votre vie.
Cela ne peut pas dépendre des actions ou de l’inaction de quelqu’un d’autre.
Ne comptez pas sur quelqu’un d’autre pour vous motiver à être meilleur.
Donnez toujours le meilleur de vous-même et quoi que vous fassiez, vous le ferez très bien.
Ce soir, avant d’aller dormir, assurez-vous de prendre un moment pour vous remercier des efforts que vous avez déployés aujourd’hui. Rappelez-vous que peu importe ce qui a été accompli ou n’a pas été accompli aujourd’hui, vous avez fait de votre mieux. Et c’est tout ce que quiconque, y compris vous-même, peut demander.
partagez ce billet avec vos amis, collègues et relations professionnelles
Une préparation diligente, des flux de travail clairement définis et une surveillance vigilante sont essentiels pour livrer un projet DevOps hautement performant. Szymon Piasecki, responsable DevOps chez STX Next.
DevOps: 3 steps to plan and execute a successful project par Szymon Piasecki
Bien que DevOps ne soit pas une nouvelle expression ou idée pour quiconque évolue dans l’industrie high-tech, c’est devenu un mot à la mode ces dernières années. Sa popularité est telle qu’il est maintenant crucial de comprendre comment structurer et déployer au mieux une équipe DevOps, et il existe plusieurs points de vue et méthodologies différents sur ce sujet.
En termes simples, DevOps est l’intégration des développeurs et des opérateurs informatiques en un seul groupe, avec l’objectif commun d’améliorer la vitesse et la qualité du déploiement des logiciels. Il a d’abord été créé en réponse aux préoccupations concernant la ségrégation des équipes et la façon dont cela entraînait souvent des ruptures de communication et un manque de cohésion.
Depuis que le terme a été inventé pour la première fois en 1993, DevOps n’a fait que gagner en popularité. 83% des décideurs informatiques en 2021 ont déclaré avoir mis en œuvre ce style de travail sous une forme ou une autre.
Changer l’orientation business de cette manière ne garantit pas un changement immédiat de résultats. Cependant, cette dynamique représente un changement de culture informatique, avec un accent accru sur la collaboration et les compétences relationnelles interpersonnelles. Pour que ce modèle fonctionne à long terme, les ingénieurs doivent être ouverts à cette nouvelle façon de travailler.
Alors, quelles étapes vitales une équipe DevOps doit-elle prendre pour assurer la réussite d’un projet ?
1. Comprendre le pourquoi
Les étapes préliminaires d’un projet DevOps sont cruciales. Sans une direction claire et une compréhension commune au sein de l’équipe, l’initiative est vouée à l’échec.
Pourquoi ce changement ?
L’équipe et le client doivent donc être prêts à consacrer le temps nécessaire pour comprendre les objectifs de chacun et s’assurer que leurs visions s’alignent. Cela peut se faire par le biais de réunions et d’ateliers, où les participants identifient les objectifs et les membres de l’équipe établissent un objectif clair sur ce à quoi le produit final devrait ressembler.
Lorsque cette mise au point est exécutée correctement, l’équipe DevOps quittera la première phase du projet avec un briefing bien défini et une compréhension claire des objectifs du client. Si cette étape est précipitée, les ingénieurs seront gênés par un manque de direction, ce qui augmentera la probabilité que le produit fini ne réponde pas aux exigences du client.
2. Développer
La deuxième phase est celle où le développement de l’application commence. Ceci est généralement facilité par l’utilisation d’une solution basée sur le cloud, où l’équipe commence à préparer l’environnement, à travailler sur les composants qu’il doit contenir et à comprendre comment ils doivent être configurés pour maximiser l’efficacité.
Les meilleures équipes DevOps sont agiles et polyvalentes, avec des membres qui peuvent facilement s’adapter à un nouveau rôle ou aider dans divers domaines.
Pendant cette période, l’équipe doit s’assurer que la version finale de l’application est aussi sécurisée que possible. Pour cette raison, l’équipe DevOps a besoin de compétences diverses, y compris au moins un expert en cybersécurité.
Une phase de développement réussie se caractérise par des flux de travail clairement structurés dans lesquels le projet est décomposé, étape par étape. Tous les membres de l’équipe doivent comprendre où ils s’inscrivent dans le plan et comment ils peuvent contribuer.
Il est important de se rappeler que les projets DevOps sont rarement une promenade de santé du début à la fin. Le développement est souvent entravé par des délais manqués, des bugs et des conflits de priorité qui éloignent les ingénieurs de leurs responsabilités projet. Pour cette raison, les meilleures équipes sont agiles et polyvalentes, avec des membres qui peuvent facilement s’adapter à un nouveau rôle ou aider dans divers domaines. Cette agilité est extrêmement importante pour assurer la continuité lorsque les flux de travail sont perturbés.
3. Tester, surveiller et améliorer
Une fois qu’un produit est mis en ligne, le travail entre dans une nouvelle étape cruciale. Les meilleures équipes DevOps ne se reposent jamais sur leurs lauriers à la fin de la phase de développement.Les développeurs doivent surveiller attentivement l’application à ses débuts afin que tout bug puisse être identifié et immédiatement corrigé.
Des ingénieurs devraient être en place pour surveiller l’environnement, y compris la façon dont il est affecté et comment il réagit aux flux variables de nouveaux utilisateurs. Les données obtenues constituent une ressource précieuse et doivent être traitées comme telles, les équipes triant et étiquetant les résultats dès qu’ils sont collectés.
Une fois les données de référence recueillies, l’équipe doit analyser les résultats pour identifier les parties de l’application qui pourraient nécessiter des améliorations ou une refonte. Après cela, le résultat final devrait être un produit qui fonctionne de manière optimale et répond aux spécifications du client.
Se préparer au succès
Les équipes DevOps qui suivent les étapes décrites ci-dessus auront la certitude absolue que leur projet est sur la bonne voie et qu’il est prêt pour réussir.
Concevoir un produit bien fait est beaucoup plus facile lorsque votre équipe inclut des spécialistes de diverses disciplines qui sont enthousiastes à l’idée de collaborer et de communiquer. Avoir la bonne équipe facilitera également la transition entre chaque étape d’un projet DevOps et garantira que le client est satisfait.
partagez ce billet avec vos amis, collègues et relations professionnelles
Vous jonglez avec des tâches avec une vitesse digne des plus grands numéros de cirque. Félicitations, champion du multitâches ! Mais, est-ce la bonne approche pour conserver votre santé mentale ?
How NOT to Multitask – Work Simpler and Saner par Leo Babauta
Vous travaillez déjà sur deux projets à la fois, et votre boss vient de mettre deux nouvelles demandes sur votre bureau. Vous êtes au téléphone pendant que trois nouveaux courriels arrivent. Vous essayez de sortir à l’heure afin de pouvoir faire quelques courses sur le chemin du retour pour le dîner. Votre téléphone fixe sonne, tout comme votre téléphone mobile. Votre collègue s’arrête avec une demande d’informations et votre Google Reader compte plus de 100 messages à lire.
Vous jonglez avec des tâches avec une vitesse digne des plus grands cirques. Félicitations, champion du multitâche !
En cette ère de technologie instantanée, nous sommes bombardés d’une surcharge d’informations et d’exigences envers notre temps. C’est en partie la raison pour laquelle GTD (Getting Things Done® – David Allen’s GTD® Methodology) est si populaire dans le monde de l’information. C’est un système conçu pour des décisions rapides et pour garder toutes les demandes dans votre vie en ordre de priorités. Mais même si vous utilisez GTD, vous êtes parfois tellement submergés par les choses à faire que votre système commence à s’effondrer.
Life Hack a récemment publié « Comment faire du multitâche » How to Multi-task, et c’est un bon article sur la nature du multitâche et comment le faire tout en se concentrant sur une tâche à la fois.
Ce billet est « Comment NE PAS effectuer plusieurs tâches à la fois », un guide pour travailler aussi simplement que possible pour conserver votre santé mentale.
Tout d’abord, quelques raisons rapides de ne pas effectuer plusieurs tâches à la fois
Le multitâche est moins efficace, en raison de la nécessité de changer de contexte pour chaque nouvelle tâche, puis de changer à nouveau.
Le multitâche est plus compliqué et donc plus sujet au stress et aux erreurs.
Le multitâche peut rendre fou, et dans ce monde déjà chaotique, vous devez régner dans la terreur et trouver une petite oasis de santé mentale et de calme.
Voici quelques conseils sur la façon de NE PAS effectuer plusieurs tâches à la fois
Une manière différente de construire votre « to-do » liste
Établissez d’abord des listes de tâches pour différents contextes (c.-à-d. appels téléphoniques, ordinateur, courses, domicile, en attente, etc.) selon votre situation.
Ayez un outil de capture (comme un cahier) pour vos notes instantanées sur ce qui doit être fait.
Ayez une boîte de réception physique et électronique (et aussi peu de boîtes de réception que possible) afin que tous les éléments entrants soient rassemblés en un seul endroit (un pour les documents papier, un pour le numérique).
Planifiez votre journée en blocs, avec des blocs de temps libres entre eux pour les choses urgentes qui surviennent. Vous pouvez essayer des blocs d’une heure ou d’une demi-heure, selon ce qui fonctionne pour vous. Ou essayez ceci : des blocs de 40 minutes, avec 20 minutes entre eux pour les tâches diverses.
Première chose du matin : Travaillez sur votre tâche la plus importante. Ne faites rien d’autre tant qu’elle n’est pas faite. Accordez-vous une courte pause, puis commencez votre prochaine tâche la plus importante. Si vous pouvez en faire 2 à 3 le matin, le reste de la journée est facile.
Stoppez tout risque de distraction.
Lorsque vous travaillez sur une tâche dans un bloc de temps, désactivez toutes les autres distractions. Fermez le courrier électronique et Internet si possible. Éteignez votre téléphone cellulaire. Essayez de ne pas répondre à votre téléphone fixe si possible. Concentrez-vous sur cette tâche et essayez de la faire sans vous soucier d’autres choses.
Si vous ressentez le besoin de vérifier vos e-mails ou de passer à une autre tâche, arrêtez-vous. Respirez profondément. Recentrez-vous. Revenez à la tâche à accomplir.
Si d’autres éléments surviennent pendant que vous travaillez, placez-les dans la boîte de réception ou notez-les dans votre système de capture. Revenez à la tâche à accomplir.
Lorsque vous avez terminé la tâche à accomplir, traitez vos noteset votre boîte de réception, ajoutez les tâches à vos listes de tâches et redéfinissez votre emploi du temps si nécessaire. Traitez vos e-mails et autres boîtes de réception à intervalles réguliers et prédéterminés.
Parfois, une interruption est si urgente que vous ne pouvez pas la reporter jusqu’à ce que vous ayez terminé la tâche à accomplir. Dans ce cas, essayez de capturer où vous en êtes avec la tâche à accomplir, et mettez tous les documents ou notes pour cette tâche ensemble et de côté (peut-être dans un dossier « action » ou un dossier de projet). Ensuite, lorsque vous revenez à cette tâche, vous pouvez ressortir votre dossier et regarder vos notes pour voir où vous vous êtes arrêté.
Prenez de profondes respirations, étirez-vous et faites des pauses de temps en temps. Profitez de la vie. Sortez et appréciez la nature. Restez sain d’esprit.
CSP DOCENDI est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
Voici une brève vidéo qui donne à réfléchir sur nos pratiques.
Effectuer simultanément plusieurs tâches devient banal, sinon obligatoire. Mais gagne-t-on vraiment en efficacité ? Avec quelles conséquences ? Analyse scientifique d’un phénomène que l’économie a diffusé dans toute la société.
partagez ce billet avec vos amis, collègues et relations professionnelles
De nombreuses organisations utilisent une planification basée sur les livrables, spécifiant les différentes fonctionnalités ou produits que les équipes prévoient de livrer et quand. Je suis fan de la planification basée sur les livrables à court terme parce qu’elle concentre tout le monde sur des (peu et moins nombreux) livrables. La pandémie nous a appris une leçon essentielle : Bien que la planification à long terme basée sur les livrables puisse mettre en lumière les risques, nous ne pouvons pas garantir que nous pourrons réaliser tous ces plans à long terme.
À quand remonte la dernière fois où votre entreprise, votre marché ou votre contexte organisationnel ont changé deux ou trois mois après le moment où vous avez réalisé votre planification ?
Pour de nombreuses organisations, un trimestre (oui, 13 semaines) s’avère être une planification à long terme.
C’est à ce moment-là que mes clients me disent qu’ils se sentent mal à l’aise face à leurs décisions passées. Ils se sont trop engagés et trop à l’avance. Maintenant, le coût d’une re-planification semble élevé.
Vous avez des options.
Au lieu d’une planification à long terme basée sur les livrables, considérez les idées suivantes
Planifiez le moins possible de livrables maintenant, à court terme.
Créez une liste d’options que vous pouvez ajouter, en supposant que vous ayez le temps de terminer plus de livrables avant la prochaine planification.
Définissez les problèmes potentiels, et non les livrables, pour faciliter la prise de décision future.
Voici comment ces idées fonctionnent ensemble.
Idée #1 : Limitez le nombre de livrables à planifier en ce moment
Quelle est l’ampleur et la longueur de votre arriéré de produit (product backlog) actuel ?
Voici quelques lignes directrices que j’ai utilisées pour limiter la planification :
Limitez le backlog d’une équipe au nombre d’éléments que l’équipe peut terminer en deux semaines maximum. Parce que même si l’équipe n’utilise pas d’itérations, deux semaines constituent un délai raisonnable pour voir si le backlog doit changer.
Limitez votre backlog produit au nombre d’articles que les clients peuvent adopter en environ un mois. Si les clients ne peuvent pas intégrer les changements pour un produit donné plus rapidement, il est peut-être temps de donner un projet ou un produit différent à cette équipe.
Limitez le nombre de projets et de programmes au nombre d’équipes. Lorsque les équipes travaillent sur un seul projet ou programme à la fois, elles progressent au maximum de leur capacité. Le multitâche ralentit tout.
Vous pourriez être prêt à m’accorder le bénéfice du doute… Mais qu’advient-il de tout le reste du travail que vous planifiez normalement pour ce projet ou ce produit ?
Au lieu de vous engager à tout le travail à l’avance, engagez-vous à en faire aussi peu que possible. C’est tout ce qui est au dessus de la ligne. Ensuite, si vous avez le temps avant qu’il ne soit temps de re-planifier, vous pouvez remonter une option située en dessous de la ligne vers le haut.
Vous n’avez pas non plus à classer ces options longtemps à l’avance. Étant donné que personne n’a ces options sur un arriéré de produit ou dans une feuille de route, l’équipe ou le manager de produit peut reclasser les options comme nécessaire. Ou à mesure que le marché, le client et le contexte organisationnel changent.
Les options vous permettent de planifier à long terme, sans vous engager sur ces options.
*big black line: C’est ce dont les équipes ont besoin pour réussir ce trimestre. Compléter tout ce qui est au dessus de cette ligne serait déjà génial. Au fur et à mesure que les équipes terminent les histoires, la communauté projet et le Product Owner réévaluent les histoires restantes sur la feuille de route et sélectionnent lesquelles ajouter au travail en cours.
Idée #3 : Définissez les problèmes pour vos décisions futures
Quand je pense aux arriérés ou backlogs et aux feuilles de route des produits, je pense aux problèmes que nous avons déjà décidé de résoudre. Cependant, j’ai commencé ce billet en suggérant que nous avons besoin de plus de flexibilité dans notre planification parce que notre contexte pourrait changer.
Lorsque nous définissons les problèmes candidats plutôt que les livrables, nous pouvons plus facilement examiner le contexte par rapport à nos plans précédents.
Cela facilite le choix des problèmes à résoudre et du moment où il est possible de s’y attaquer. Et cela permet à tout le monde de raccourcir toutes les boucles de rétroaction lorsque vous gérez votre planification. (Voir Multiple Short Feedback Loops Support Innovation pour plus de détails.)
Soutenez vos décisions futures
Réfléchissez aux livrables que vous souhaitez livrer maintenant et plus tard. Au lieu de pré-spécifier tous ces livrables, lesquels pourriez-vous transformer en options ?
Ensuite, au lieu de vous engager sur des livrables à long terme, pouvez-vous faire de ces problèmes à long terme des idées à adresser ? Plus votre entreprise, votre marché ou votre contexte organisationnel change rapidement, plus vous voudrez peut-être modifier les livrables et le moment pour les livrer. Et vous voudrez peut-être repenser quels sont les problèmes à résoudre et quand.
La raison pour laquelle le titre de cet article est entre guillemets est qu’il s’agit d’une question fréquemment posée dans les groupes de discussion sur http://projectmanagement.com et le groupe LinkedIn Project, Program and Portfolio Management de PMI. Avec un certain nombre d’autres contributeurs, je l’ai vue et y ai répondu suffisamment de fois pour que je pense que cela vaut la peine de partager mes réflexions avec mon lectorat.
Détails de la certification sur le site du PMI
La certification PMP® est la référence en management de projet que la plupart des recruteurs et des managers connaissent. Les personnes averties savent que si elle ne fournit aucune garantie de compétence, elle démontre au moins qu’un praticien a une certaine compréhension de base de la nomenclature, des outils et des techniques.
Bien qu’avoir obtenu cette certification ait été un facteur de différenciation au cours des premières décennies suivant son introduction, à ce stade, elle l’est moins, mais dans certaines industries et régions spécifiques, ne pas l’avoir pourrait entraîner le rejet d’une candidature par le processus de filtrage initial.
Mais une fois qu’un praticien a obtenu sa certification PMP, que se passe-t-il ensuite ?
Le développement professionnel devrait être la quête de toute une vie (ou du moins d’une carrière), et les certifications fournissent des preuves tangibles qu’une personne investit dans son développement, donc cette question semble raisonnable.
Avant de poser cette question, la personne doit avoir identifié un objectif de carrière ou de développement spécifique. Dans certains cas, cela peut être simple, par exemple si une certification particulière est requise dans le cadre des conditions préalables à une promotion dans l’entreprise.
Mais c’est rarement le cas et c’est ce qui rend les choses plus difficiles.
Les entreprises qui développent et gèrent des certifications de compétences déclareront toutes avec confiance que leurs produits vous aideront à faire progresser votre carrière. Pourquoi pas ? Pour chaque personne qui adhère à cette justification, l’organisation d’accréditation gagnera généralement un montant initial puis un flux de revenus continus.
Mais à moins qu’un rôle particulier auquel vous aspirez exige que vous ayez une certification de compétence spécifique, dans la plupart des cas, tout ce que cela prouvera, c’est que vous avez appris quelque chose et que vous avez réussi un test. Vous l’avez peut-être fait sans pratique concrète dans ce domaine.
Visitez ce site
Maintenant, si vous avez déjà acquis de l’expérience dans un domaine et que vous souhaitez ensuite avoir des preuves visibles de votre acquisition de certaines connaissances, alors un certificat de compétence est un moyen de le faire. Mais si vous voulez apprendre une nouvelle compétence, vous feriez mieux de vous auto-éduquer ou de prendre un cours sans certification et de les faire suivre d’un travail pratique réel supporté par un praticien chevronné.
Aussi, les seules réponses correctes à la question initiale sont :
Quels sont vos objectifs de développement ?
ou
Pourquoi recherchez-vous une autre certification ?
“PMI,” the PMI logo, “PMP” and “Project Management Institute” are registered marks of Project Management Institute, Inc.
Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes
Si vous ne savez pas où vous allez, n’importe quelle route vous y mènera – Lewis Carroll
partagez ce billet avec vos amis, collègues et relations professionnelles
Vous avez du mal à expliquer DevOps et tout ce qu’il englobe aux non-techniciens ? Les gens se demandent-ils ce que font réellement les ingénieurs DevOps de votre équipe ?
Ces définitions et analogies vous aideront à leur répondre.
Le terme DevOps a été créé il y a plus de 10 ans, et ce qui a commencé comme un hashtag est devenu un mouvement culturel dans l’informatique. Cette philosophie encourage les développeurs à aller vite, à expérimenter et à itérer. DevOps est devenu intrinsèquement lié à la transformation numérique. Mais en ce qui concerne la terminologie informatique, une décennie est amplement suffisante pour accumuler des définitions, des interprétations et une grande confusion autour de ce que DevOps signifie réellement.
DevOps est-il la même chose qu’Agile ? Est-ce une méthodologie ? Est-ce juste une autre façon de dire collaboration ? Que font réellement les ingénieurs DevOps ? Avons-nous besoin de ce titre, ou n’est-ce qu’un effet de mode ?
Parce que DevOps englobe de nombreux concepts différents (livraison continue, intégration continue, automatisation, etc.), il peut être difficile, en particulier pour ceux qui sont les plus passionnés par ce sujet, d’essayer de réduire DevOps à une courte phrase. Mais, rappelons-nous, les petites phrases peuvent être utiles, que vous essayiez de vendre l’idée dans la chaîne de management ou d’expliquer ce que vous faites à quelqu’un lors d’une fête. Donc, pour l’instant, mettons de côté les nuances autour de termes spécifiques à DevOps et concentrons-nous sur la vue d’ensemble.
Qu’est-ce que DevOps en 6 définitions et analogies ?
Nous avons demandé aux experts DevOps comment ils expliquent DevOps avec leurs mots les plus courts et les plus simples afin que tout le monde puisse comprendre sa valeur, quelle que soit sa formation technique. Voici quelques définitions percutantes et quelques analogies utiles pour vous aider à raconter votre propre histoire DevOps.
1. DevOps est un mouvement culturel
Visitez ce site
« DevOps est un mouvement culturel où les deux principaux groupes de parties prenantes (développeurs de logiciels et opérations informatiques) conviennent que le logiciel n’ajoute pas vraiment de valeur tant qu’il n’est pas utilisé par quelqu’un – clients, utilisateurs, employés, etc. » explique Eveline Oehrlich, directrice de recherche en chef au DevOps Institute.
« Pour cette raison, les deux équipes veillent ensemble à ce que les logiciels soient livrés avec rapidité et qualité. »
2. DevOps responsabilise les développeurs
DevOps permet aux développeurs de posséder, d’exécuter et de manager de bout en bout la livraison d’une application.
« Il est communément admis que DevOps permet une livraison en production plus rapide en mettant en œuvre et en exploitant des processus automatisés. Pour moi, c’est beaucoup plus fondamental », explique Jai Schniepp, propriétaire de produit senior de plates-formes DevOps sécurisées chez Liberty Mutual.
« DevOps permet aux développeurs de posséder, d’exécuter et de manager de bout en bout la livraison d’une application ou d’un logiciel. DevOps élimine la confusion autour de la propriété et conduit l’équipe vers une infrastructure automatisée et managée par les développeurs. »
3. DevOps est une approche collaborative de création et de livraison de logiciels
« En termes simples, DevOps est une approche de création et de fourniture de logiciels informatiques dans laquelle tout le monde travaille ensemble », explique Gur Steif, président de l’automatisation des activités numériques chez BMC.
4. DevOps est comme une chaîne de montage
Pour qu’une chaîne de montage fonctionne, les composants doivent être conçus pour s’assembler de manière transparente.
« Je comparerais DevOps à une chaîne de montage », déclare Gur Steif. « L’idée est de concevoir et de construire toutes les pièces à l’avance, de manière à ce que toutes les pièces s’emboîtent. Pour qu’une chaîne de montage fonctionne, les composants doivent être conçus pour s’assembler de manière transparente. Les gens qui conçoivent et construisent les moteurs doivent penser au châssis et aux supports de moteur. Les gens qui construisent des freins doivent penser aux jantes et aux pneus, et ainsi de suite. C’est comme ça que ça doit être dans le logiciel. Les développeurs qui écrivent la logique métier ou l’interface utilisateur doivent penser à la base de données qui stocke les informations client, à la sécurité qui protège les données utilisateur et à la façon dont tout cela fonctionne lorsque le service est exposé à ce qui peut être des millions d’utilisateurs.
« Amener les gens à collaborer et à penser au travail effectué par d’autres plutôt que de se concentrer uniquement sur leur(s) tâche(s) individuelle(s) est le plus grand obstacle à surmonter. Si vous y parvenez, vous avez d’excellentes chances de réaliser la transformation numérique », ajoute Steif.
5. DevOps est une recette – combinant les personnes, les processus et l’automatisation
Jayne Groll, PDG du DevOpsInstitute, a une excellente analogie culinaire pour expliquer DevOps :
DevOps est une recette qui repose sur des ingrédients de trois grandes catégories : les personnes, les processus et l’automatisation.
La plupart des ingrédients peuvent être adaptés à partir d’autres pratiques et sources bien connues telles que Lean, Agile, SRE, CI / CD, ITIL, le leadership, la culture et les outils. Le secret derrière DevOps est la façon dont ces ingrédients sont combinés et dans les bonnes proportions (comme toute bonne recette) afin d’augmenter le flux et la valeur pour le client.
6. Les équipes DevOps sont comme les équipes de course NASCAR
Les équipes de course ne réfléchissent pas du départ à l’arrivée; Elles tournent la table pour considérer la course de la ligne d’arrivée au départ.
« Lorsque je parle des résultats souhaités pour une initiative DevOps, je mentionne NASCAR ou les courses de F1 », explique Chris Short, responsable marketing technique principal, plates-formes cloud, chez Red Hat, et éditeur de la newsletter DevOps’ish.
« Les chefs d’équipe de ces équipes de course n’ont qu’une mission : Finir à la meilleure place possible avec les ressources dont ils disposent tout en surmontant l’adversité à laquelle ils sont confrontés. Les équipes de course ne réfléchissent pas du départ à la ligne d’arrivée ; Elles renversent la problématique pour regarder la course de la ligne d’arrivée au départ. Elles se fixent un objectif, un objectif ambitieux, puis commencent à travailler à rebours à partir de ces objectifs pour déterminer comment y arriver. Le travail est délégué aux membres de l’équipe pendant la semaine de la course pour atteindre l’ensemble des objectifs qui permettent d’obtenir le résultat souhaité. »
« Les équipes de course pratiquent les arrêts aux stands toute la semaine avant la course. Elles suivent des programmes de musculation et de cardio pendant la semaine pour se garder physiquement prêtes pour les conditions exténuantes du jour de la course. Elles collaborent continuellement pour résoudre tout problème qui pourrait survenir. De même, les équipes logicielles devraient pratiquer souvent les livraisons. Si les systèmes de sécurité sont en place et que les essais se déroulent bien, la mise en production se produit plus fréquemment. La vitesse rend les choses plus sûres avec cet état d’esprit », explique Short.
« Il ne s’agit pas de faire la « bonne » chose », ajoute-t-il, « il s’agit d’adresser autant de choses qui pourraient vous empêcher d’obtenir le résultat souhaité que possible. Collaborez et ajustez en fonction des retours en temps réel que vous observez. Attendez-vous à des anomalies et travaillez pour améliorer la qualité afin de minimiser l’impact de ces anomalies sur l’objectif. Ce sont les attentes de chacun dans un monde DevOps. »
Qu’est-ce qu’un ingénieur DevOps ?
Un mouvement culturel, une méthodologie, une recette pour réussir : Remarquez comment personne n’a fait référence à DevOps comme à un rôle.
Pourtant, l’ingénieur DevOps figure en bonne place sur la liste des meilleurs emplois de Glassdoor en Amérique, et ce chaque année depuis 2017. Est-il logique d’étiqueter le mot « DevOps » sur le titre d’une personne lorsque des organisations informatiques toutes entières sont invitées à travailler d’une nouvelle manière ?
Certains croient fermement que la réponse est non.
« DevOps est une méthodologie, pas un rôle», explique Neelan Choksi, président et chef de l’exploitation chez Tasktop. « Plutôt que d’étiqueter vos ingénieurs « ingénieurs DevOps », vous devez reconnaître que le rôle de l’ingénieur dans le développement et les opérations a évolué et continue de le faire. Parce que le cloisonnement des organisations en départements appartient au passé, le changement perpétuel n’est plus le travail d’un département et le problème d’un autre.
En fait, trop se concentrer sur les rôles individuels peut freiner les organisations, dit Choksi. « Si [dans votre organisation] la culture DevOps est plutôt considérée comme un job ou un rôle unique, vous pouvez toujours apporter de petites améliorations locales en adoptant les meilleures pratiques DevOps, mais l’impact de ces pratiques sera limité. »
A l’autre extrémité du débat, certains soutiennent que les titres sont significatifs, surtout lorsque les industries traversent des transformations majeures. Inclure le terme DevOps sur un CV ou une description de poste indique un niveau de compétence qui est actuellement difficile à trouver, dit Oehrlich.
« J’ai suivi la transformation DevOps en tant qu’analyste de l’industrie depuis ses débuts », a récemment écrit Oehrlich. « Aujourd’hui, l’utilisation de la méthodologie DevOps est de 74 % (en dehors des méthodologies complémentaires), avec une adoption à l’échelle de l’entreprise de 24 % et une adoption projet (ou projets multiples) de 42 %, selon le rapport Upskilling 2020 : Enterprise DevOps Skills Report. »
Le défi numéro un auquel est confronté DevOps est de trouver et d’attirer des personnes DevOps qualifiées. 58 % des personnes interrogées ont déclaré que trouver des personnes qualifiées est un énorme défi, tandis que 48 % disent que la rétention de personnes DevOps qualifiées est un challenge.
Quelle que soit votre position dans le débat en cours sur les ingénieurs DevOps, Choksi et Oehrlich ont tous deux des conseils sur ce qu’il faut rechercher chez les personnes qui dirigent DevOps dans votre organisation :
« Les ingénieurs DevOps doivent se concentrer sur leurs compétences en résolution de problèmes et sur leur capacité à accroître l’efficacité, à gagner du temps et à automatiser les processus manuels et, surtout, à se soucier de ceux qui utilisent leurs livrables », explique Choksi. « L’ingénieur à l’épreuve du temps est capable de travailler entre les équipes et les fonctions, non seulement au sein de l’informatique, mais aussi dans l’ensemble de l’entreprise. Ils sont en mesure de tirer parti de spécialistes et d’intégrer les approches et méthodologies optimales qui offrent de la valeur dans un environnement concurrentiel rapide avec la qualité requise par les clients. »
« Le titre d’ingénieur DevOps décrit une façon différente de concevoir », explique Oerhlich. « Bien qu’il existe des responsabilités fondamentales pour un ingénieur DevOps (codage, script, ré-ingénierie, automatisation, collaboration et communication), le rôle lui-même est un rôle d’ingénierie. L’ingénierie est une question d’innovation, la créativité étant un trait humain fondamental qui stimule le développement de nouvelles technologies et de nouveaux produits, processus ou services. La combinaison des mots « DevOps » et « ingénieur » met en avant que l’avenir est à l’innovation autour de la façon dont le développement et les opérations sont effectués ensemble : Le titre « ingénieur DevOps » souligne cet état d’esprit. »
partagez ce billet avec vos amis, collègues et relations professionnelles
Votre management des risques doit rester aussi simple que possible et néanmoins vous garantir que les réponses sont faisables, économiquement viables et efficaces.
#1 – Identifiez correctement le propriétaire de chaque risque.
Une fois qu’un risque a été identifié, En tant que manager de projet, vous devez vous demander : « À qui appartient le risque ? ». Le propriétaire de risque est la personne responsable de l’élaboration et de l’exécution du plan de réponse à ce risque.
#2 – Détectez et réagissez aux petits risques connexes.
De nombreux risques sont connectés.
Plusieurs petits risques connexes peuvent avoir un effet boule de neige qui mène éventuellement à un événement important. Apprenez à bien mettre en évidence les connexions entre les risques, comment les percevoir, puis travaillez à les détecter.
#3 – Identifiez et managez les risques secondaires.
Certaines réponses à un risque peuvent déclencher une avalanche d’autres risques.
Lorsque les propriétaires des risques élaborent des plans de réponse à leurs risques, elles ou ils peuvent ne pas tenir compte des risques secondaires. Les risques secondaires sont ceux qui découlent directement de la mise en œuvre d’une réponse au risque primaire. Certaines solutions et plans d’action pour manager un risque pourraient générer d’autres problèmes potentiels.
En tant que manager de projet expérimenté, vous éduquez et demandez à vos propriétaires de risques d’identifier et de planifier les risques secondaires importants.
#4 – Élaborez des plans de contingence.
Certains plans de réponse aux risques doivent être exécutés immédiatement, d’autres sont de ‘contingence’. Ces plans conditionnels ne seront exécutés que si certaines conditions prédéfinies sont remplies.
#5 – Préparez des plans de secours.
Quel est votre plan de secours si celui prévu pour manager le risque échoue ?
Que doit faire un propriétaire de risque si le plan de réponse au risque échoue ?
Elles ou ils devraient mettre en place et être prêts à exécuter un plan de secours pour les risques importants.
Le plan de secours peut être utilisé pour atténuer une menace ou tirer bénéfice d’une opportunité.
#6 – Identifiez clairement les déclencheurs de risque.
Qu’est-ce qui pourrait déclencher ce risque ?
Certains managers de risques font un excellent travail de définition des plans de réponse, mais ne parviennent pas à définir clairement quel serait le déclencheur du risque, comme manquer un jalon.
Aidez-les à travailler ce point.
Les déclencheurs peuvent être utilisés pour avertir que le risque est sur le point de se produire, ce qui donne au propriétaire du risque le temps de mettre en œuvre le plan de réponse à ce risque.
#7 – Sachez saisir les opportunités.
Parmi tous les risques potentiels se cachent aussi des opportunités très positives pour le projet.
Les risques comprennent aussi des événements ou des conditions positives, qui, s’ils se produisent, auront un impact positif sur les objectifs du projet.
Vous serez beaucoup plus efficace si vous parvenez à identifier ces événements positifs et ne ratez aucune chance d’en faire bénéficier votre projet et vos clients
#8 – Tenez à jour vos plans de management de projet.
Vous devez rester synchrone dans l’ensemble de vos plans de projets avec celui de management des risques.
Les plans de management de l’échéancier, des coûts, de la qualité, des approvisionnements, des recrutements et du périmètre. Au fur et à mesure que les propriétaires de risques élaborent des plans de management, vous devez en tant que manager de projet mettre à jour tous ces autres plans en conséquence.
Par exemple vous ajouterez si nécessaire de nouvelles activités au WBS et définirez plus en détail la façon dont les provisions pour éventualités seront utilisées.
#9 – Maintenez un journal des hypothèses.
Tenez votre journal des hypothèses à jour et visible de votre équipe et de votre sponsor.
Vous-même et les membres de l’équipe projet faites beaucoup d’hypothèses, en particulier dans les premières phases d’un projet en fonction des informations disponibles. Au fur et à mesure que l’équipe de projet découvre de nouvelles informations, les hypothèses déjà identifiées peuvent nécessiter une mise à jour ou vous pourriez devoir ajouter de nouvelles hypothèses. En gardant ces hypothèses visibles de tous, vous permettez à chacun d’intervenir et de les corriger ou enrichir si nécessaire.
#10 – Créez des contrats ou des accords avec les parties prenantes externes.
Certains propriétaires de risques peuvent souhaiter faire appel à un tiers pour répondre aux risques.
En tant que manager de projet, vous allez vous assurer que ces décisions et contrats soient documentés et approuvés si besoin.
Voyez-vous d’autres mesures à prendre pour mieux pour planifier la réponse aux risques ?
Envisagez d’utiliser cette liste comme une simple liste de contrôle et appliquez-la sur l’un de vos projets actuels pour la tester.
Votre management des risques doit rester aussi simple que possible et néanmoins vous garantir que les réponses sont faisables, économiquement viables et efficaces.
partagez ce billet avec vos amis, collègues et relations professionnelles
Vous avez certainement entendu parler de ChatGPT. Qu’est-ce ChatGPT ?
Il y a un buzz incroyable autour de cette intelligence artificielle avec laquelle on peut discuter et qui répond sur un style quasi humain. Les enthousiastes en font des tonnes. On prédit la fin du moteur de recherche de Google puisque ChatGPT répond à toutes vos questions, la fin des codeurs car ChatGTP crée du code sur demande dans le langage de votre choix, la fin des auteurs humains puisque Chat GPT rédige sur demande sur le sujet de votre choix… Christian Hohmann
Christian a eu l’idée de demander directement à ChatGPT ce qu’est ChatGPT !
Sa réponse écrite sera lue par un convertisseur vocal. Pourquoi tant d’engouement autour de ChatGPT ? Réponse dans cette courte vidéo !
La roue de croissance du coaching agile est un outil pour les coachs agiles, les scrum masters, les leaders et tous ceux qui souhaitent accroître leur capacité à aider et à développer les équipes et les organisations en utilisant les principes et les pratiques agiles.
La roue vous permet de réfléchir et de grandir dans votre cheminement agile.
Faites-vous aider d’un autre coach Agile pour progresser.
HBR n’avait jamais entendu parler de ce terme et ils appelèrent Mintzberg pour lui demander ce que signifie l’adhocratie.
Il corrigea son article pour que ce soit plus clair. Même si, à la relecture, avant de publier l’article, les relecteurs de HBR ne comprenaient toujours pas ce qu’était l’adhocratie… (H. Mintzberg,2004)
L’adhocratie, est une structure qui est basée sur des relations informelles.
Structure axée sur l’informel
Pensez aux entreprises agiles ou libérées. Ces entreprises innovent constamment, elles fonctionnent en mode projet.
Quand une équipe a terminé un projet, ses membres sont ré-alloués sur d’autres projets. À l’exception par exemple des tâches opérationnelles dans l’industrie comme c’est le cas dans certaines entreprises.
Mintzberg a défini deux sous-catégories de bureaucraties.
Structure axée sur le formel
Tout d’abord, la bureaucratie Mécaniste, c’est une entreprise où le personnel devra se référer rigoureusement aux procédures afin de mener une tâche. Imaginez une usine industrielle.
Enfin, la bureaucratie Professionnelle, où, il y aura un système de classement, pour évaluer le personnel. Pensez aux cabinets de conseil où chaque consultant est évalué sur l’atteinte de ses objectifs.
Comme le dit Max Weber, le père de l’organisation bureaucratique : c’est une entreprise axée sur le formel. Tout est hiérarchisé avec des rôles clairement définis.
Revenons au sujet de cet article, quelle posture doit adopter le chef de projet au sein de deux structures ?
Le Project Management Institute® (PMI) a pris conscience qu’un chef de projet doit adapter son comportement à la structure de l’entreprise. C’est la raison pour laquelle, le nouvel examen PMP® est, depuis 2021, axé sur des questions situationnelles et moins techniques.
Autrefois, on attendait principalement d’un chef de projet qu’il maîtrise l’aspect technique de la planification d’un projet. Il n’est pas rare, d’entendre que ceux qui ont passé le PMP avant 2021 avaient à réaliser des calculs sur les coûts et délais d’un projet. Aujourd’hui, ce n’est plus le cas. Le PMI, recherche des chefs de projet qui savent gérer les relations informelles avec les membres de leurs projets.
Dans une entreprise bureaucratique, on attend du chef de projet qu’il soit hautement compétent d’un point de vue technique. Autrefois, nous étions dans un paradigme qui considérait que si le chef de projet savait faire un GANTT, cela suffisait pour qu’il soit un bon chef de projet sans prendre en compte le côté management des parties prenantes.
Aujourd’hui, l’adhocratie semble se démocratiser. De nombreuses, entreprises qui fonctionnement toujours en mode bureaucratique ont compris qu’il fallait être plus souple sans forcément devenir une structure adhocratique. C’est pourquoi, le PMI a accentué le côté « leadership » lors de la certification PMP. En effet, PMI veut sensibiliser les (futurs) chefs de projets à prendre conscience que la réussite d’un projet passe par le pilotage des Hommes et ainsi aider les entreprises bureaucratiques ou adhocratiques à mieux réussir leurs projets. Comme le dit si bien PMI, le PMBoK® 7 est bien adapté pour les projets traditionnels, hybrides, aussi bien qu’Agiles.
Si vous pilotez un projet dans une entreprise bureaucratique vous serez fortement confronté aux cloisonnements des différentes entités et à la réticence aux changements. Car, ces entités n’ont pas l’habitude de communiquer ensemble. Il vous faudra vous armer de patience. La démarche du Lean Management semble très intéressante pour vous aider à piloter vos projets au sein de ces organisations.
Salle Obeya
Car, elle va vous permettre de mettre en place une salle Obeya, similaire à un Comité de Pilotage de Projet (COPIL) où les différentes parties prenantes rattachées à plusieurs entités, pourront travailler ensemble de manière visuelle avec un management collaboratif. Il est fort possible que votre entreprise n’ait pas de référentiel en gestion de projet. Si vous êtes certifié (PMP ou Prince2…), il vous faudra encore une fois, être patient et convaincre le sponsor de l’utilité du PMBoK ou autres référentiels.
Ce qu’il faut comprendre est que, si vous souhaitez mener à bien vos projets dans une bureaucratie, il vous faudra être un accompagnateur du changement en plus d’être un chef de projet. Faites preuve d’empathie et impliquez les parties prenantes vers le management participatif.
Livre sur Amazon
La démarche du Lean Management est efficace pour vous aider. Si le Lean vous est inconnu, n’hésitez pas à faire appel à un certifié Green/Black Belt Lean ou responsable amélioration continue de votre entreprise, il vous fournira des outils efficaces pour piloter vos projets.
Il ne faut pas oublier que l’entreprise automobile Toyota à l’origine du Lean est passé d’une bureaucratie inefficace à une bureaucratie habilitante ou excellente selon Isaac Getz, Liberté & Cie. et Jeffey Liker dans son ouvrage : Le modèle Toyota, 14 principes.
Si vous pilotez votre projet dans une adhocratie, le chef de projet est avant tout, un leader et coach.
Si vous êtes moins confronté à la réticence aux changements, il n’en demeure pas moins que vous devez savoir laisser vos parties prenantes prendre des décisions (contrairement à une bureaucratie où vous avez un pouvoir de décision assez élevé). Il est primordial que vous soyez sociable et connaissiez bien les démarches Agile ou Lean car elles sont souvent utilisées pour rester innovant.
Étant donné, que nous sommes dans l’informel, l’équipe projet collabore et travaille dans la même pièce. Toutefois, il faudra être précautionneux sur le fait de bien centraliser les données pour que l’équipe puisse avoir toutes les bonnes informations nécessaires au bon endroit. Cela nécessite, donc que vous appréciez travailler en équipe et gérer les conflits axés sur les relations. Comme il y a plus d’informel que de formel, il y a une plus grande probabilité que des conflits apparaissent. N’oubliez pas si vous avez travaillez depuis longtemps dans une structure traditionnelle et que vous devez maintenant travailler dans une adhocratie que la responsabilité de la planification revient à l’équipe projet.
CSP DOCENDI est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
Finalement, que vous pilotiez un projet dans une bureaucratie ou adhocratie, vous devez faire preuve d’empathie, écoute active et avoir le sens du relationnel.
Cela semble être du bon sens.
Mais, dans une bureaucratie, vous devrez :
Vous armer de patience
Être un facilitateur
Accompagner le changement vers le management participatif
Savoir utiliser les bons outils car vous avez tout de même un pouvoir conséquent.
A la différence, de l’adhocratie, où votre pouvoir est limité. Vous serez tel le Scrum Master qui est présent pour guider son équipe (mais sans la diriger), tout en sachant canaliser et centraliser les relations informelles.
Sources :
[1] Mintzberg H. (2004). Le management : Voyage au centre des organisations. Eyrolles, Paris. Page. 348.
“PMI,” the PMI logo, “PMP,” “PMBOK” and “Project Management Institute” are registered marks of Project Management Institute, Inc.
IOUALITENE Yanis est chef de projet Lean.
Yanis Ioualitene
Il est diplômé de Skema Business School en management de Projets & Programmes. Il est certifié PMP ®, Prince2, ITIL 4, PSM I, Agile PM DSDM et Green Belt Lean.
Yanis a contribué au groupe de travail sur le PMBoK 7 organisé par le PMI Francophone.
Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes
partagez ce billet avec vos amis, collègues et relations professionnelles
Les managers de projet ont à ce moment-là le moins d’informations. L’incertitude est la plus grande.
Si vous demandez à deux personnes d’expliquer la raison d’être d’un nouveau projet, vous pouvez obtenir des réponses totalement différentes.
Dans les premières étapes d’un projet, nous n’avons pas encore identifié les risques. Il existe de nombreux outils et techniques qui peuvent vous aider, vous, votre équipe de projet et vos parties prenantes à identifier les risques tels que :
Certaines personnes pensent que vous pouvez lire dans leurs pensées. Lorsque vous interagissez avec les dirigeants, les membres de l’équipe de projet et autres parties prenantes, posez des questions explicites sur leurs attentes.
DantotsuPM.com 