articles, méthodes, partages d'expérience et rdv du management de projets et de l'agilité
https://stevekeating.me/2023/06/04/giving-and-receiving-constructive-feedback/
Donner et recevoir des commentaires constructifs est une compétence importante dans les relations personnelles et professionnelles. Cela vous aide à apprendre et à grandir. Cela vous donne une chance d’améliorer votre performance. Cette compétence peut également établir des liens plus forts entre le donneur et le destinataire de ce retour. Les vrais leaders savent que les commentaires constructifs sont le carburant de la croissance. Ils manquent rarement une occasion de fournir ce carburant à leurs équipes. Même lorsque les retours peuvent être quelque peu difficiles à livrer, ils les donnent tout de même.
Mais pas de manière aléatoire ou par réflexe. Leurs commentaires sont réfléchis et bien planifiés. Ils savent que les commentaires peuvent facilement être mal interprétés, alors ils choisissent leurs mots avec soin.
Trouvez un environnement approprié où les deux parties peuvent avoir de la confidentialité. Les conversations sur les retours nécessitent une concentration sans distractions.
Au lieu de dire à quelqu’un exactement quoi faire, expliquez lui l’impact de ses actions. Proposez des approches alternatives. Encouragez cette personne à trouver ses propres solutions et à s’approprier son développement.Ils développent un niveau de confiance élevé avec leurs équipes afin que leurs membres puissent les aider ouvertement et honnêtement à devenir de meilleurs leaders.
Beaucoup de personnes, même celles qui sont efficaces pour fournir des commentaires, ont du mal à en recevoir.
Créez un environnement qui encourage les retours en écoutant activement sans vous mettre sur la défensive. Rappelez-vous que la rétroaction est une opportunité de croissance et d’amélioration.
Au lieu de trouver des excuses ou de justifier vos actions, essayez de comprendre le point de vue de la personne qui donne des retours. Considérez leurs points objectivement et cherchez des domaines où vous pouvez apprendre et grandir.
N’oubliez pas que les commentaires constructifs visent à aider les individus à grandir et à se développer. Il est important d’aborder ces conversations avec un état d’esprit positif et constructif. Ceci est vrai que vous donniez ou receviez les commentaires.
Ces suggestions sont loin d’être exhaustives. Mais elles peuvent vous aider à établir des relations plus solides et à vous améliorer continuellement, vous et les autres.
Comme toujours, donner et recevoir des retours est un choix que vous devez faire pour vous-même. Sachez simplement que les personnes qui réussissent le mieux font toujours le choix de recevoir ces commentaires.
SAFe reconnaît et respecte que de nombreuses organisations en transition vers des pratiques agiles ont encore un état d’esprit traditionnel. Par conséquent, beaucoup de matériel dans SAFe peut paraître inacceptable pour les agilistes confirmés.
https://failfastmoveon.blogspot.com/2023/05/addressing-some-safe-concerns.html
Très souvent, je rencontre des préoccupations avec SAFe (Scaled Agile Framework). Lorsque l’on regarde la situation dans son ensemble, et ce que de nombreuses entreprises font de SAFe, ces préoccupations sont recevables et devraient être prises au sérieux. Pourtant, aucune de ces préoccupations ne pourrait être résolue par un consultant SAFe compétent (SAFe® Practice Consultant-T – SPCT) et une direction soucieuse de réaliser une différence significative dans ses méthodes de travail. Dans cet article, je considère certaines de ces préoccupations. Michael Küsters.
Avant de creuser, je crois que les compétences et l’expérience de vos consultants SAFe sont essentielles au succès de SAFe. Si vous comptez sur des gens qui ne comprennent pas les conséquences des conseils qu’ils donnent, vous êtes dans une situation difficile. Un de mes amis SPCT (SAFe® Practice Consultant-T – SPCT) a récemment déclaré :
Avoir les mauvais SPC (SAFe® Practice Consultant) – ou ignorer complètement les conseils d’un SPC – vous coûtera facilement dix fois plus cher que ce qu’un bon SPC vous coûterait.
Je suis d’accord. Les bons SPC valent leur pesant d’or. Malheureusement, ils ne poussent pas sur les arbres… Mais c’est une autre histoire. Maintenant, jetons un coup d’œil à certaines des préoccupations que je rencontre habituellement, et ce que vous devez considérer.
SAFe reconnaît et respecte que de nombreuses organisations en transition vers des pratiques agiles ont encore un état d’esprit traditionnel. Par conséquent, beaucoup de matériel dans SAFe est écrit d’une manière qui pourrait être plus acceptable pour les personnes qui ont une faible compréhension de l’agilité. C’est l’idée de « rencontrer les gens là où ils sont ». Oui, c’est controversé, mais c’est de loin mieux que d’affronter les personnes mêmes dont vous avez besoin pour réussir un changement. Ce qui se passe après les avoir rencontrés dépend beaucoup de leur motivation à changer et de la capacité du SPC à mener le changement.
Tout d’abord, si vous n’avez pas les problèmes que SAFe adresse, ne l’utilisez pas. Ceci étant dit, SAFe ne peut pas et ne devrait généralement pas être appliqué dans son intégralité. Au contraire, lorsque vous repérez un problème pour lequel SAFe propose une solution, vous pouvez regarder ce que dit SAFe, avoir une discussion pour savoir si cela vaut la peine d’essayer. Et, si c’est le cas, alors allez-y.
Cela ne signifie pas non plus que vous devez faire des choses qui adressent des problèmes que vous n’avez pas, ni que vous devez faire les choses comme SAFe dit de le faire si cela ne fonctionne pas pour vous. Pour ma part, quand quelqu’un vient me voir et me dit : « Nous utilisons SAFe et avons tel ou tel problème », je me réfère généralement à un article SAFe, et les pointeurs originaux auxquels SAFe fait référence, et je prends la discussion à partir de là. Pour moi, SAFe est un déclencheur de discussion, pas la panacée à tous les maux.
SAFe reconnaît que les dépendances peuvent être un défi dans les organisations complexes. Il fournit des conseils et des pratiques clairs qui rendent les dépendances visibles, puis offre un moyen de traiter ces dépendances de manière systématique. Dans de nombreuses organisations, les dépendances sont inévitables mais au moins vous savez quels problèmes vous avez à cause d’elles, et vous pouvez commencer la discussion sur ce qu’il faut faire à leur sujet. J’ai vu plus d’une fois que les équipes trouvaient leurs dépendances irréalisables et décidaient de se réorganiser. Une excellente discussion à avoir.
SAFe utilise une approche de planification basée sur un cadencement avec des intervalles de planification (Planning Intervals – PIs) de longueur fixe s’étendant généralement sur 8 à 12 semaines. Des intervalles de planification plus longs offrent stabilité et prévisibilité aux équipes au détriment de la flexibilité. Cependant, vous pouvez ajuster la durée des PIs en fonction de votre propre contexte. J’ai vu des trains de livraison agiles exécuter 3 sprints de 1 semaine plus un sprint PI de 1 semaine. Cela correspond même au vieux slogan de Scrum, « Working Software in 30 days or less » – à grande échelle ! Essayez ce qui fonctionne pour vous et discutez.
Peut-être avons-nous une mauvaise image dans notre tête, mais qui peut nous en blâmer quand nous avons été conditionnés à penser en hiérarchies ? Dans un contexte SAFe, vous aimeriez décentraliser ce qui a du sens mais tout n’a pas de sens à être décentralisé. Par exemple, la fonction de Product Management dans SAFe pourrait être composée de Product Owners par équipe, s’ils ont les compétences et la capacité de réussir dans ce rôle, de sorte que cela n’a pas besoin d’être hiérarchique.
Ce dont vous avez besoin, c’est de vous concentrer clairement sur les plus gros morceaux de valeur et d’aligner toutes les équipes autour d’eux.
La façon dont cela se produit peut varier d’une organisation à l’autre, mais le fait que chaque équipe décide par elle-même n’augure rien de bon. Veuillez noter que SAFe encourage la participation active et l’autonomisation des équipes et des individus dans la prise de décisions.
SAFe n’est pas une implémentation stricte de Scrum, mais plutôt un cadre qui intègre des principes et des pratiques agiles provenant de diverses sources, y compris Scrum. Étant donné que de nombreuses équipes utilisent déjà Scrum et sont familières avec les concepts de base de Scrum, SAFe en a tiré parti et conserve les principes fondamentaux de transparence, d’inspection et d’adaptation.
Lorsque je coache des équipes SAFe, je me réfère souvent au Guide Scrum et suggère que comprendre et pratiquer Scrum aide beaucoup à bien mettre à l’échelle. Malheureusement, ce que je vois assez souvent, c’est que les organisations ont déjà utilisé un Scrum hautement dysfonctionnel depuis des années, et veulent maintenant changer cela. En fait, la transformation SAFe pourrait être l’occasion de réparer les trucs Scrum qui ont toujours été cassés et n’ont jamais été résolus.
C’est déjà un dysfonctionnement parce que les fonctionnalités produites avec SAFe devraient se concentrer sur la valeur, pas sur la maximisation de la quantité de travail livré. Vous ne devriez avoir qu’un seul ART Kanban hiérarchisé par valeur et les équipes devraient collaborer sur des objectifs partagés, en utilisant des backlogs communs et des événements inter-équipes pour assurer une solution système cohérente qui maximise la valeur.
Alors que parfois, je constate que les équipes individuelles peuvent se concentrer sur la fourniture de leurs propres fonctionnalités indépendamment de la valeur.
SAFe fournit des mécanismes tels que les démonstrations système et les événements d’inspection et d’adaptation pour s’assurer que les équipes ne partent pas sur une tangente et effectuent une grande quantité de travail de faible valeur.
Il y a beaucoup à dire sur le processus d’estimation de SAFe, et j’ai ma propre opinion sur les conseils donnés. Pour faire simple: Ces conseils sont réservés aux personnes qui ne savent pas par où commencer. Le coaching et l’empirisme devraient conduire à une approche qui répond aux besoins de ceux qui ont besoin des estimations.
Vous devez réaliser que dans les grandes organisations, très souvent, plusieurs parties prenantes, d’autres équipes et potentiellement de grosses sommes d’argent dépendent de l’établissement de prévisions assez précises de l’achèvement. L’estimation peut avoir des implications qui n’existent pas dans des contextes plus petits.
Mon propre exemple est que nous devons absolument savoir si la fonctionnalité sera prête pour un salon précis ou si nous devons mitiger. Mais « Eh bien, nous pourrions ou être prêts à temps ou pas pour le salon » pourrait conduire à un désastre majeur en matière de relations publiques, et est probablement inacceptable.
Alors que l’événement Inspect and Adapt (I+A) se produit à la fin de chaque intervalle de planification (PI), SAFe encourage l’amélioration continue tout au long du PI, les Scrum-of-Scrums (SoS) et les rétrospectives étant des opportunités pour faire apparaître et résoudre les problèmes transversaux.
J’ai moi-même donné des conseils sur le fait que les équipes sont censées apporter leurs propres changements et améliorations indépendamment de l’événement I+A, et même partager leurs apprentissages avec d’autres équipes pendant cet événement. Je m’attends à ce que les équipes apportent des problèmes à court terme au SoS, et n’apportent à l’I+A que des problèmes qui nécessitent des périodes de préparation et d’observation plus longues, et ont un impact bien au-delà des limites de l’équipe. Surtout, vous devez considérer que le I+A est un point de réflexion, où vous vous détachez de la routine quotidienne et vous réunissez en tant qu’équipe d’équipes pour discuter des choses dont vous devez discuter et dont vous n’avez jamais eu l’occasion de discuter auparavant. Il y a toujours quelque chose. Oui, vous pourriez avoir de tels événements plus souvent si vous pensez que cela pourrait aider, il n’y a rien dans SAFe qui vous arrête. Essayez.
Je conviens que le Scaled Agile Framework (SAFe) a des domaines d’interprétation et suscite des préoccupations. S’attendre à ce que ce soit une solution miracle est complètement irréaliste. SAFe fournit une approche structurée pour les grandes organisations qui essaient de donner un sens à toute cette chose « Agile », mais cela ne fonctionne que si elles ont quelqu’un qui comprend plus que ce que dit le matériel. Lorsque vous pouvez faire face aux complexités du développement à grande échelle, de la collaboration entre les équipes et de l’alignement global tout en vous améliorant continuellement, vous avez réussi avec SAFe.
Pour y arriver, vous devez absolument personnaliser SAFe et l’utiliser à bon escient sinon cela deviendra un gâchis, et c’est pourquoi vous avez besoin de personnes qui savent de quoi elles parlent.
Et j’ai vu ce gâchis : La pagaille prend des années à nettoyer. Les personnes qui soutiennent votre initiative de changement doivent être en mesure de répondre aux préoccupations critiques en fonction de leur propre expérience et de leurs apprentissages. Et les personnes de votre organisation qui ont des préoccupations ont besoin d’un temps et d’un endroit où exprimer ces préoccupations car ce n’est qu’alors que vous pourrez vraiment vous améliorer.
J’ai eu l’opportunité de participer à notre événement Czech PMI Chapter et de répondre aux questions du public sur la façon d’aborder la transformation Agile, quels sont les bénéfices attendus et comment les atteindre. J’aimerais poursuivre le partage et approfondir un peu certains des sujets qui ont été ouverts lors de l’événement.
L’attente générale d’une transformation Agile est de renforcer votre capacité à vous adapter et à réagir rapidement à l’échelle de l’entreprise. Si une entreprise veut devenir plus efficace, il y a plusieurs sujets connexes qui doivent être abordés simultanément et ils vont bien au-delà de la façon de travailler des équipes agiles individuelles (culture d’entreprise, développement stratégique des compétences, systèmes de management de la performance, alignement efficace de plusieurs équipes accédant aux mêmes plates-formes technologiques et bien d’autres).
Et pour toute initiative visant à apporter des améliorations, le succès de la transformation est déterminé par le fait de savoir pourquoi et où nous voulons nous améliorer. Nous devons être clairs sur les bénéfices que nous aimerions obtenir, puis définir l’objectif principal des efforts de transformation pour commencer le voyage.
Dans cet article, j’aimerais partager mon expérience pratique avec trois domaines qui sont répertoriés par le 13th Annual State of Agile Report comme les avantages les plus fréquemment obtenus.
La capacité à manager les priorités changeantes (signalée par 69% des participants à la recherche)Voyons d’abord pourquoi nous voudrions améliorer le management des priorités changeantes. Quel est l’impact si nous ne réagissons pas et n’adaptons pas l’allocation actuelle ou prévue des ressources ?
Pour le dire simplement, sans la capacité de manager les priorités changeantes, nous continuons ce que nous faisions, quelles que soient les circonstances qui nous disent d’abandonner nos initiatives actuelles et de commencer à faire autre chose.
Pour changer cela, nous devons surmonter les 3 aspects suivants au niveau de l’entreprise (inutile de dire que chacun d’eux est assez difficile en lui-même) :
Pour aborder les deux premiers points, il est indispensable d’inculquer une attitude « une équipe » ( one team ) à votre équipe de direction. Ils sont censés, eux aussi, être une équipe.
Je vois souvent un investissement d’énergie et de ressources dans le team-building au niveau des équipes inter-fonctionnelles agiles, mais le domaine du team-building au niveau de l‘équipe de management ne reçoit pas l’attention requise (ou nous nous attendons simplement à ce que ces cadres supérieurs rattrapent d’eux-mêmes leur retard).
Pourtant, tout désaccord continu ou attitude défensive au niveau de la direction peut avoir un impact direct sur la coopération aux niveaux inter-équipes et entraver toute volonté de sortir des sentiers battus lorsque les ressources doivent être réorientées. L’alignement des priorités et l’allocation des ressources sont souvent facilités par un processus trimestriel de revue des activités étroitement lié aux objectifs et aux résultats clés (Objectives and Key Results – OKR) des départements de l’entreprise.
Pour réussir dans le troisième domaine listé ci-dessus, il est nécessaire d’adopter pleinement le mode de développement itératif en mettant l’accent sur la valeur client. Je trouve toujours utile de démontrer avec des exemples comment la valeur est construite par des étapes progressives où la technologie est le catalyseur, pas l’objectif.
Afin de parvenir à un changement de mentalité, permettez suffisamment de discussions jusqu’à ce que le sujet soit clarifié et soutenez vos équipes par le coaching.
La visibilité du projet signifie la transparence dans ce que nous faisons, où nous investissons nos ressources et pourquoi cette initiative particulière a été lancée. Une telle visibilité devrait également inclure une rétroaction ouverte sur le succès de la production, ce qui permettra d’améliorer la qualité de nos estimations, la capacité à maintenir le travail en cours dans des limites raisonnables et de rester concentré sur la création de valeur pour le client.
Pour atteindre une telle transparence, il faut généralement choisir le bon outil de communication et disposer d’une équipe qui aide à collecter et à communiquer ces informations entre les équipes. Mais la question la plus importante est la suivante :
Comment la visibilité des projets contribue-t-elle à l’agilité à l’échelle de l’entreprise ?
Comme l’une de mes collègues l’a récemment déclaré, la visibilité du projet apporte une grande compréhension de ce qui est fait, mais elle peut aussi montrer les points faibles. Personnellement, je ne pourrais pas être plus heureuse d’entendre ce commentaire prononcé à haute voix. La prise de conscience des points faibles et leur acceptation est la première étape vers l’amélioration.
Pour profiter pleinement de la visibilité des projets, nous devons fournir à nos équipes un environnement sûr qui favorise l’apprentissage rapide et une approche valorisant l’échec rapide. En d’autres termes, nous devons accroître la confiance dans le partage des opinions, établir la confiance entre les équipes elles-mêmes et guider la direction de l’entreprise vers l’adoption d’une approche de leadership au service des autres.
L’alignement des activités et du SI est au cœur de la mise en place d’équipes inter-fonctionnelles avec des experts métier et informatiques (idéalement colocalisés) ; cet alignement doit être organisé autour des livrables et des parcours clients plutôt qu’autour des systèmes informatiques ou des composants d’infrastructure.
Mais il existe un piège : Le changement organisationnel seul ne suffit pas à atteindre l’alignement.
Commencer une transformation par une grande réorganisation et l’internalisation de rôles nouvellement définis peut créer de la frustration chez les gens. Ils peuvent ne pas se considérer comme étant prêts à assumer leurs nouveaux emplois transformés ni à rejoindre de nouvelles équipes avec une méthode de travail agile.
Mais pour l’instant, je préfère me concentrer sur quelque chose qui peut apporter des bénéfices significatifs même si vos équipes restent séparées entre métiers et informatique : Pour tracer le chemin vers l’alignement entre les experts métier et informatiques, concentrons-nous d’abord sur le langage qu’ils parlent ensemble.
Le langage dans lequel les attentes de l’entreprise sont formulées est le premier indicateur de l’existence ou non d’un objectif commun. Combien de fois avons-nous entendu : « Les utilisateurs ne peuvent pas exprimer clairement leurs exigences et ils les modifient constamment » ou « Encore une fois, les nouvelles fonctionnalités informatiques ne m’ont pas donné ce dont j’avais besoin ».
Dans de telles situations, les user stories sont d’une grande aide. Une user story partage qui, quoi et pourquoi elle est nécessaire. Les user stories ne contiennent pas de description de la solution, mais clarifient plutôt la valeur client attendue que nous voulons obtenir en livrant l’histoire.
Penser et parler de cette façon plutôt qu’attendre des spécifications fonctionnelles de la part de l’utilisateur professionnel fait une grande différence. En maîtrisant la communication dans les user stories, les équipes parviennent à établir un objectif commun : La création de valeur business. L’expertise de l’équipe informatique reste dans la conception de la solution, tandis que la responsabilité de l’équipe business est de déterminer ce qui apporte de la valeur aux clients. Les user stories agissent comme l’élément de connexion qui a autant de sens pour les deux équipes impliquées, tout en leur permettant de s’épanouir dans ce qu’elles font le mieux.
Pour résumer, sur la base de mon expérience avec différentes approches pour connecter les unités commerciales et informatiques, je préfère concevoir une culture d’alignement en établissant un langage commun et en aidant les gens à se préparer au changement comme une première étape. La refonte organisationnelle devrait ensuite être utilisée pour soutenir la culture et rendre la coopération encore plus facile, mais je vois cela comme un catalyseur plutôt que l’objectif de transformation lui-même.
PMI is a registered mark of Project Management Institute, Inc.
Lenka Pincot, PMP, PMI-ACP, PMI-PBA
Lenka est cadre exécutive avec une expérience internationale et une expérience reconnue dans l’établissement d’une vision stratégique et son exécution. Elle excelle dans la conduite de transformations numériques et l’amélioration de l’agilité organisationnelle. Lenka a acquis une expérience multisectorielle en dirigeant des initiatives stratégiques dans les domaines de la banque, de l’industrie manufacturière, de la distribution et de l’automobile. Elle travaille actuellement comme chef de cabinet du président du Project Management Institute®, une organisation à but non lucratif mondiale qui offre un soutien à l’éducation et à l’évolution de carrière aux professionnels qui conduisent les changements et la transformation.
Elle est titulaire du Digital Excellence Diploma de l’IMD Business School of Switzerland, graduated C-level School de European Women in Boards, d’un Master of Science en informatique et de plusieurs certifications en management de projet, pratiques agiles et analyses business.
https://leadershipfreak.blog/2023/04/24/5-questions-that-trigger-positive-thinking/
Imaginez-vous allongé dans la boue en train de répéter : « Je suis au sommet du monde ». La pensée positive ne vous sortira pas de la boue. Il faut se relever. Mais l’état d’esprit est crucial pour réussir.
La pensée positive est utile dès lors qu’elle nourrit l’action.
Vous découvrirez peut-être que le pire n’est pas si grave. Vous pourriez contrarier quelqu’un. Peut-être serez-vous gêné. Vous ne mourrez probablement pas de cet embarras.
Seuls les idiots croient aux mensonges. Vous savez que vous vous mentez à vous-même quand vous dites : « Je suis courageux » alors que vous tremblez de tous vos membres.
Challengez-vous avec la « question la plus courageuse » au lieu de vous mentir à vous-même.
Ne jugez pas votre réponse. Faites-le. L’action nourrit l’optimisme.
Attention : L’agitation ou la sur-occupation est une évasion quand vous cherchez à éviter ce que vous craignez. La chose la plus courageuse que vous puissiez faire aujourd’hui est de faire face à la peur, pas de l’éviter.
Répondez au sondage sur les forces de caractère de VIA. (Cliquez ici puis sur le bouton jaune en haut à droite « Take the free survey ».
Vous oubliez vos réalisations lorsque les ténèbres obscurcissent votre pensée. Vous avez appris à lacer vos chaussures et à lire.
Comment vos réalisations passées pourraient-elles s’appliquer aux défis actuels ?
La vie est une expérience d’apprentissage.
Commencez un journal « J’apprends ». Vous pourriez commencer par des vérités difficiles à admettre comme : « J’apprends que je suis découragé ». Il n’y a pas de sens à nier la réalité.
Mangez-vous votre plat favori ? Soyez reconnaissant pour vos papilles gustatives. La vie est remplie de petits bénéfices. Vous dites « merci » quand quelqu’un vous tient la porte. Notez cela sur votre liste.
Laquelle des questions ci-dessus vous semble utile ? Pourquoi ?
Quelles questions qui déclenchent la pensée positive pouvez-vous ajouter à cette liste ?
Ce rapport annuel a été construit suite à une enquête auprès d’un large panel de professionnels d’organisations très variées en tailles comme en secteurs. Il est toujours intéressant et voici quelques aperçus de l’édition 2023.
Le rapport complet (et gratuit) en langue anglaise
Cette tendance est à la fois une mauvaise nouvelle et une bonne nouvelle pour la profession de manager de projet.
Il est toujours frustrant de constater que, juste au moment où vous pensez maîtriser votre domaine, les objectifs se sont déplacés. Mais à d’autres égards, cette sonnette d’alarme arrive juste à temps.
Nous savions depuis des années que l’intelligence artificielle ferait des percées dans la discipline de la gestion de projet, et c’est en fait majoritairement une bonne nouvelle. Qui veut s’enliser dans les 50% à 80% du rôle du manager de projet qui consiste à produire et contrôler des métriques qui peuvent être mieux managées par un robot ?
Maintenant est venu le moment de prendre en compte ce que cela signifiera réellement pour nous : l’IA ne va pas arriver, elle est déjà ici.
Alors, que peuvent faire les chefs de projet pour pérenniser leurs compétences et répondre aux exigences du marché actuel ?
» Évaluer et prendre les mesures appropriées pour maintenir une performance acceptable du projet
» Travailler en mode collaboratif dans un environnement d’équipe projet
» Adapter une approche de management de projet appropriée et adaptée au travail à accomplir
» Mener des activités avec intégrité, soin et fiabilité
» Écouter activement avec concentration, empathie et le désir de comprendre clairement les autres
» Communiquer avec les autres (communications orales et écrites, présentations)
» Manager des projets qui ont un impact transformationnel sur l’organisation
» Adapter la gouvernance aux besoins spécifiques du projet
Celles et ceux qui sont engagés dans la gestion de projet ont besoin de s’améliorer dans presque toutes ces compétences.
» Mener des activités avec intégrité, soin et fiabilité
» Résoudre les problèmes : identifier les causes, générer des solutions possibles, agir
» Interagir avec les clients et améliorer l’expérience client
» Travailler collaborativement dans un environnement d’équipe de projet
» Faire preuve d’un bon jugement, même sous pression, et tout en restant calme
» Communiquer avec les autres (communications orales et écrites, présentations)
» Savoir exprimer clairement des idées complexes
» Satisfaire les attentes des parties prenantes en matière de qualité et répondre aux exigences du projet
» Travailler pour servir la raison d’être de l’organisation
Alors que le monde a émergé de la pandémie et du confinement, de nombreux employés envisagent encore maintenant de retourner au bureau. Pour certains, la transition vers le retour au bureau peut être accueillie avec hésitation ou anxiété. Cependant, il existe de nombreuses raisons impérieuses pour lesquelles retourner au bureau peut être la bonne et la meilleure chose à faire.
Le retour au bureau peut servir de lieu où les employés peuvent interagir avec leurs collègues, collaborer sur des projets et établir des relations significatives. Cette interaction sociale fait souvent défaut lorsque l’on travaille à distance et peut conduire à des sentiments d’isolement et de solitude.
Le retour au bureau fournit une routine quotidienne qui aide à augmenter la productivité. Il donne un sens de but et de direction.
Le retour au bureau offre un meilleur accès aux dirigeants et aux décideurs. Être au même endroit physique que les dirigeants peut offrir des occasions de conversations et de discussions plus informelles et peut aider à établir des relations plus solides.
Le retour au bureau peut être un endroit où les employés peuvent se concentrer sur leur travail. Par conséquent, faire une différence dans leur organisation et leur communauté.
L’énergie du collectif peut également être un avantage majeur du retour au bureau. De plus, le buzz et l’excitation d’un bureau occupé peuvent être énergisants et motivants.
Le retour au bureau offrira un meilleur accès aux ressources telles que les imprimantes et les fournitures. En outre, il peut améliorer l’efficacité et la productivité.
Bien que le travail à distance ait facilité la communication avec les collègues par vidéoconférence et d’autres outils numériques, rien ne remplace la communication en personne.
Le retour au bureau peut nous redonner le pouvoir de regarder, d’observer et d’écouter les indices non verbaux qui sont souvent perdus dans les réunions virtuelles. Ce qui peut être crucial pour une communication et une collaboration efficaces.
La possibilité de socialiser ne doit jamais être sous-estimée. Travailler dans un environnement de bureau permet des conversations informelles et une socialisation avec des collègues, ce qui peut aider à créer un sentiment d’appartenance.
Le retour au bureau peut également aider à séparer la vie personnelle et professionnelle, ce qui peut être flou lorsque vous travaillez à domicile.
Travailler à proximité de collègues plus expérimentés peut offrir des possibilités de coaching et de perfectionnement.
Le retour au bureau permet de retrouver l’environnement qui favorise un sentiment de camaraderie et d’appartenance, connu sous le nom de « commanderie », qui peut contribuer au bien-être général.
Les réunions en face à face sont en général plus efficaces que les réunions virtuelles. Elles permettent une meilleure communication et la possibilité d’établir des relations.
De retour au bureau, les employés ont l’occasion d’apprendre de leurs collègues et de leurs mentors grâce à des conversations et des interactions informelles. Ce type d’apprentissage informel peut être plus difficile à réaliser lorsque vous travaillez à distance.
Le travail à distance a ses avantages, il peut être facile de prendre l’habitude de rester en pyjama toute la journée. Tandis que retourner au bureau peut être une bonne excuse pour s’habiller.
Le retour au bureau peut avoir des effets positifs sur le bien-être général. Le bureau peut fournir un sentiment de structure et d’objectif qui peut améliorer la santé mentale.
Le retour au bureau offre l’opportunité de poser une question rapide ou de demander conseil à un collègue.
Le retour au bureau peut être l’occasion d’observer et d’interpréter le langage corporel, qui est un outil puissant pour une communication et une collaboration efficaces.
Le retour au bureau fournit un espace de travail dédié avec une configuration appropriée peut également améliorer l’ergonomie et prévenir les efforts physiques.
Travailler dans un environnement de bureau permet le travail d’équipe et la possibilité de rebondir sur les idées de vos collègues.
Nous devons nous rappeler que le travail à distance peut avoir ses avantages, mais il peut aussi s’accompagner de défis tels que l’isolement, plus d’heures de travail, de mauvaises configurations de bureau à domicile, des périodes prolongées de position assise et des lignes floues entre la maison et le bureau.
Ces défis peuvent avoir un impact négatif sur les équipes et peuvent avoir un impact négatif sur la productivité et le bien-être.
Le retour au bureau peut fournir un sentiment de structure et de soutien, et peut aider à atténuer certains des défis du travail à domicile.
Diriger de l’intérieur: Les meilleurs leaders cherchent constamment à bien faire les choses et à trouver les raisons les plus convaincantes qui profitent à leurs employés.
La gentillesse est une attitude cruciale pour les leaders car elle leur permet de constituer des équipes fortes, collaboratives et productives avec des environnements de travail inclusifs.
Lorsque les leaders sont gentils, ils montrent qu’ils se soucient des autres et font preuve d’empathie et de compréhension. Par conséquent, cela peut aider à établir la confiance et le respect avec les employés et à favoriser une culture de collaboration et de soutien au sein d’une organisation.
Lorsque les dirigeants sont gentils, ils créent une culture de collaboration et de soutien en encourageant les employés à travailler ensemble et à se soutenir mutuellement.
En conséquence, cela peut aider à constituer des équipes solides et efficaces et permettre aux organisations d’atteindre leurs buts et objectifs.
Lorsque les leaders sont gentils, ils créent un environnement dans lequel les employés se sentent à l’aise et en sécurité pour communiquer ouvertement et honnêtement. En retour, cela peut aider à améliorer la communication et l’établissement d’un bon relationnel, et permettre aux dirigeants de mieux comprendre les besoins et les perspectives de leurs équipes.
Lorsque les leaders sont gentils, ils créent un environnement de travail positif et favorable. De plus, cela montre aux employés qu’ils sont valorisés et appréciés, ce qui peut aider à promouvoir une culture de travail positive et permettre aux organisations d’attirer et de retenir les meilleurs talents.
Il y a de nombreuses raisons pour lesquelles les leaders doivent toujours être gentils, mais la plus importante est peut-être que la gentillesse montre que les gens comptent pour leur leader.
Diriger de l’intérieur : La gentillesse compte dans le leadership. Il permet aux dirigeants d’instaurer la confiance, de créer un environnement de travail positif et inclusif et de favoriser la collaboration et le soutien au sein de leurs équipes.
Dans le monde en changement accéléré qui est le notre, cesser de chercher ailleurs des boucs émissaires, et prendre le risque de la gentillesse et de la bienveillance et de l’engagement collectif est un pari qui redonne à chacun des marges de manœuvre pour construire un environnement meilleur.
Les bon(ne)s managers de projet créent des cultures de projet dénuées de stress et confusion et facilitant la progression. Avez-vous déjà adopté ces bons comportements ou bien sont-ils déjà vôtres même inconsciemment ?
Passons en revue une liste de huit comportements que tous les excellent(e)s managers de projet ont en commun. De plus, parlons de la façon d’accentuer ces bons comportements.
Vous savez éliminer les réunions récurrentes lorsque cela est possible. De même, vous avez déjà éliminé les réunions d’avancement car vous collectez ces informations à travers votre système d’information de projet et les partagez électroniquement par le biais de rapports d’avancement.
Avant de proposer une réunion, vous vous demandez toujours : Y aurait-il une autre façon de manager cela sans une longue réunion avec beaucoup d’intervenants ? Peut-être une rapide visio ou conférence téléphonique ? Peut-être un simple e-mail, message instantané, ou coup de fil à la bonne personne ?
Sinon un stand-up meeting serait-il approprié pour faire bref et avoir le minimum de participants nécessaires et utiles.
Vous limitez la taille et le nombre de documentations sur tout le projet. Vous de produisez au sein du projet que des documentations dont vous êtes certains qu’elles seront lues et utilisées. S’il y a une raison légitime pour un long document, vous en fournissez un résumé qui permet aux personnes d’en digérer rapidement les points les plus importants.
S’il y a un manque de confiance, les équipes ralentissent jusqu’à s’arrêter. Vous ne faites que des promesses que vous saurez tenir et vous les tenez. 
Si vous avez de bonnes et justes intentions mais ne les exécutez pas, les gens n’auront plus confiance en vous.
Vous refusez d’être le/la manager de projet qui se promeut continuellement en donnant peu de crédit à l’équipe. A l’inverse, vous cherchez constamment des moyens de reconnaître et de remercier les membres de votre équipe pour leur travail. Lorsqu’il y a des problèmes, vous en prenez la responsabilité, vous dites à vos parties prenantes que vous êtes responsable et ce que vous ferez pour résoudre les problèmes. En cas de succès, vous mettez surtout en évidence les contributions concrètes du ou des membres de l’équipe.
Plutôt que d’interrompre pour faire valoir votre point de vue, vous écoutez dans l’intention de creuser plus profondément et de comprendre le point de vue de l’autre personne.
Vous savez concentrer toute votre attention sur la personne qui parle et sur le message qu’elle veut vous faire passer. Vous établissez un bon contact visuel. Et vous posez des questions de clarification appropriées qui montrent votre empathie et votre souci de ce sujet.
Vous vous assurez d’être clairs comme de l’eau de roche sur ce qui est attendu, qui va le faire et quand les choses sont dues.
Vous n’improvisez pas la délégation mais au contraire, vous la planifiez. Puis, vous communiquez ce que vous déléguez, le niveau d’autonomie accordé, les dates d’échéance et le moment où vous ferez un suivi. Vous êtes disponible pour discuter des problèmes et fournir un soutien et la personne à laquelle vous déléguer une tâche le sait parfaitement.
Vous planifiez vos réunions avec un ordre du jour clair et des questions préparatoires pour engager l’équipe. Lorsque vous demandez si les participants ont des commentaires, vous ne laissez pas le silence vous inciter à le combler trop vite en parlant prématurément. Vous donnez aux autres le temps de réfléchir et de réagir. Vous appréciez les personnes lorsqu’elles répondent.
Vous coachez individuellement les membres problématiques de votre équipe quand vous commencez à rencontrer des problèmes avec eux et vous clarifiez vos attentes. Vous demandez à la personne de s’engager venir vous voir le plus tôt possible si quelque chose commence à nuire à sa capacité d’accomplir les tâches qui lui sont assignées. Si vous n’êtes pas en mesure d’obtenir les réponses souhaitées au fil du temps, vous en parlez avec votre sponsor de projet et établissez les étapes à suivre pour éventuellement remplacer la personne.
Avez-vous remarqué que bon nombre des comportements dans ce post sont liés au leadership et aux compétences relationnelles et interpersonnelles ?
Si vous souhaitez renforcer vos compétences générales, consultez le livre : The Purpose Driven Project Manager .
Harry Hall y aborde 10 problèmes de projet courants et comment appliquer vos compétences générales pour atteindre vos objectifs et faire progresser votre carrière.
« Ce livre donne au manager de projet les outils dont il a besoin immédiatement pour améliorer la performance de ses équipes. C’est une lecture rapide qui vous donnera un retour immédiat.
Harry fait un excellent travail pour résumer les problèmes complexes auxquels sont confrontés les PM aujourd’hui et présente les solutions d’une manière que même un manager de projet novice peut comprendre et appliquer. »
Jeremy Causey, PGP
En temps de crise, un petit merci fait beaucoup. Sabina Nawaz
L’article de Sabina Nawaz « In Times of Crisis, a Little Thanks Goes a Long Way », publié sur HBR.org, est un excellent rappel du besoin que nous avons tous d’être appréciés.
Dans un article de blog datant de quelques années, j’avais écrit que les membres de l’équipe devaient posséder suffisamment de compétences, de capacités et d’engagement pour contribuer au succès de l’équipe. Autonomy, Mastery and Purpose (L’autonomie, la maîtrise et le but: La vérité sur ce qui nous motive) de Daniel Pink peuvent certainement aider à allumer la motivation intrinsèque, mais nous ne devrions pas nous arrêter là.
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.
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.
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.
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.
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.
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.
https://kbondale.wordpress.com/2022/12/19/five-benefits-to-creating-a-schedule-network-diagram/
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.
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.
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.
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 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.
Si vous avez aimé cet article, pourquoi ne pas lire mon livre Easy in Theory, Difficult in Practice qui contient 100 autres leçons sur le leadership de projet ?
Ces définitions et analogies vous aideront à leur répondre.
https://enterprisersproject.com/article/2019/8/devops-explained-plain-english
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.
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.
« 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é. »
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. »
« 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.
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.
Jayne Groll, PDG du DevOps Institute, 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.
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. »
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. »
Si comme de nombreux et nombreuses managers de projets, vous pensez que vous pourriez accroître grandement la productivité et l’innovation si tout le monde était vraiment impliqué au sein de votre organisation projet, mais que vous ne savez pas comment vous y prendre…
Les Liberating Structures sont des méthodes nouvelles, pratiques et simples pour vous aider à atteindre ces objectifs productivité et innovation avec des groupes de toutes tailles (et dans une bonne ambiance).
https://wellingtone.co.uk/how-to-prepare-for-a-project-audit/
Ne nous leurrons pas : Les audits peuvent être effrayants, surtout si c’est la première fois que vous en faites partie. Le simple mot « audit » sonne immédiatement comme une affaire sérieuse, non ?
Les audits de projet sont une enquête détaillée et formelle sur le management d’un projet, ses processus, ses dépenses, son avancement, ses risques, etc. et pour beaucoup, ils sont (à tort, je dois dire) considérés comme le dernier recours dans l’assurance du projet. Cela a principalement à voir avec la façon dont les audits sont déclenchés, lorsqu’il y a des préoccupations avec la gouvernance du projet, ses finances et/ou pour déterminer sa viabilité future. Le projet est considéré comme un projet « qui rencontre des difficultés ».
De plus, les audits de projet ne sont pas toujours accueillis à bras ouverts, car ils sont souvent effectués par une entité externe au projet et, parfois, par l’organisation (p. ex., PMO/bureau de projet ou auditeur indépendant).
Cependant, les audits de projet n’ont pas besoin d’être effrayants !
En fait, ils devraient être reçus comme un autre type de revue d’assurance qualité, visant à renforcer le modèle des trois lignes de défense, prévu dans le cadre du plan intégré d’assurance et d’approbation du projet, et intégré dans le standard en matière d’assurance.
Si vous n’êtes toujours pas convaincu ou si c’est la première fois que vous participez à un audit de votre projet (que ce soit en tant qu’équipe de management de projet ou dans la fonction PMO/Assurance coordonnant l’assurance qualité), continuez à lire.
Utilisez une check-list d’audit
Simples mais efficaces, les check-lists vous permettent de lister rapidement ce qui est nécessaire versus ce qui est prêt pour l’audit.
Convenez de qui, quoi et quand
Les conditions de la mission doivent être clairement définies avant le début de l’audit. Cela comprend une identification claire des personnes qui doivent être impliquées/consultées, de ce qui est dans la portée de l’audit et du calendrier de l’audit.
Établissez un calendrier d’audit et attribuez les responsabilités
En matière d’assurance, « pas de surprises » est toujours une stratégie gagnante. Ainsi, avoir une visibilité sur le moment où les éléments probants seront recueillis ou sur le moment où l’équipe peut s’attendre aux résultats de l’audit est primordial pour réussir. Cela inclut également une compréhension claire des responsabilités pendant et après la vérification.
Faites connaissance avec l’auditeur
Vous ne voulez pas compromettre l’indépendance qui devrait exister en tant que principe de l’audit (nous devrions donner aux auditeurs l’espace dont ils ont besoin pour faire leur travail). Cependant, avoir une réunion de pré-audit ne fera aucun mal et vous aidera à établir des relations (et à être plus détendu lorsque l’audit aura lieu).
Posez des questions
Les audits suivent des directions d’enquête structurées afin d’éviter les « zones grises » sujettes à interprétation. Cependant, il peut être utile de savoir quel est le modus operandi de l’auditeur ou simplement de confirmer comment il souhaite avoir accès aux données du projet à consulter.
Préparez la paperasse
Les audits peuvent être bureaucratiques, avec de nombreux documents à préparer, à examiner et à partager plus tard en tant que résultats. Ne négligez pas l’importance d’avoir des éléments de configuration à jour, de clarifier quelle version d’un document est la plus récente et où elle peut être trouvée. Faites en sorte qu’il soit facile pour l’auditeur de trouver ce qu’il cherche.
Préparez votre équipe
Préparez le terrain sur les raisons pour lesquelles l’audit est nécessaire, ce qui va se passer comme prochaines étapes, ou simplement clarifiez certaines idées fausses sur ce qu’implique un audit car cela aide à créer le bon état d’esprit au sein de l’équipe projet et à intégrer l’audit projet dans les activités quotidiennes du projet sans trop de perturbations.
Soyez collaboratif
Soyez conscient du but ultime de l’audit. Ce n’est pas de signaler vos faiblesses (que ce soit en tant que manager, projet ou organisation), mais d’aider le projet à réussir en proposant des mesures préventives et correctives. Pour cette raison, il est fondamental d’être coopératif lorsqu’on vous demande de fournir une information ou de clarifier un aspect du projet.
Soyez proactif
Ne vous contentez pas d’appliquer une attitude de laissez-faire. Soyez disponible et proactif dans l’audit en offrant votre aide le cas échéant et en communiquant toute information qui, selon vous, pourrait être utile à l’auditeur.
Détendez-vous
L’audit est en cours, l’auditeur sait ce qu’il fait, vous avez complété votre préparation. Maintenant, respirez. Les résultats vous seront communiqués sous peu.
Mettez en œuvre des mesures
L’assurance projet ne prend pas fin lorsque les résultats de l’audit du projet sont connus. Elle doit être orientée vers l’action ; en fonction du mandat de la mission, un plan d’action doit être mis en œuvre, identifiant clairement les propriétaires, les délais et les priorités pour chaque action.
Tirez les leçons du passé
Les audits de projet devraient générer de la confiance et mener à la création et au transfert de connaissances qui pourraient être utiles non seulement pour les étapes restantes du projet, mais aussi pour les projets futurs de l’organisation. Ne vous y trompez pas : L’assurance n’a de valeur que si elle conduit à de meilleures décisions !
Quelle est la réponse à la question « et alors ? » envers l’audit de projet ?
Pour aller plus loin, jetez un coup d’œil au cours APM-accredited Assurance Practitioner
Nous vivons dans des réseaux dynamiques et multidimensionnels de leaders qui puisent dans les connaissances et la créativité de chacun. Gitte montre comment cela permet à vos équipes de faire plus et de le faire mieux.
Un bon leadership est un réseau, pas une hiérarchie.
Gitte Frederiksen
N’est-il pas nécessaire de maîtriser les tenants et les aboutissants du domaine dans lequel on opère ?
Quel serait l’impact d’un tel gap sur la légitimité du chef de projet ou même sur les performances du projet ?
Et comment compenser le manque d’expertise par une autre compétence ?
Toutefois, son pouvoir provenant de son statut formel n’est pas toujours suffisant pour réussir à influencer les membres de son équipe. Il aurait besoin de l’expertise métier pour compléter encore sa légitimité surtout dans un monde où l’autorité hiérarchique fait, de plus en plus, place à l’influence et la collaboration. D
e plus, s’appuyer trop sur son pouvoir hiérarchique quand les choses vont mal, pourrait avoir l’effet inverse et causer la perte de la cohésion de l’équipe. Alors, que faire sachant qu’en tant que Chef de projet, on est souvent le visage du projet pour le management et les clients ?
« Temporairement », car un jour ou l’autre on serait rattrapé par la nécessité de comprendre le métier, de parler le jargon et de vivre avec l’équipe les contraintes techniques plutôt que de garder tout ceci consigné dans des registres d’hypothèses et de contraintes sans le maîtriser en profondeur. Et la complémentarité revoie au fait d’apporter son savoir-faire en management de projet, sujet sur lequel on va être l’expert, pour contribuer avec l’équipe à arracher une belle réussite du projet. Ainsi, on aurait affirmé sa position d’expert en management de projet tout en vivant pleinement le projet avec son équipe.
Ceci aide à bien scanner l’environnement des risques mais exige un minimum de compréhension du métier du projet. Par conséquent, ne pas essayer de combler le vide expose le projet à des risques majeurs, des risques qui resteront non identifiés ou sous-estimés. Alors, comment faire face à cela dans un monde, de plus en plus, incertain, volatile et complexe ? La réponse magique est « l’avis des experts ».
Dans chaque organisation et chaque projet, on retrouve des collaborateurs qui ont bien roulé leur bosse dans un domaine spécifique et qui disposent à la fois de l’expertise technique, d’une grande expérience sur des projets similaires et bien d’autres connaissances tacites plutôt qu’explicites. Tout ce trésor bien gardé est une ressource inestimable pour le chef de projet qui en aurait besoin pour étoffer son processus de gestion des risques afin d’immuniser son projet contre des surprises malencontreuses. Encore une fois, il faudrait bien faire l’effort de monter en compétence sur le métier et ne pas toujours reposer son évaluation des risques sur l’avis des experts qui contient souvent une belle part de subjectivité.
Ceci les met face à une nouvelle réalité où les priorités ne sont pas les mêmes et où la valeur n’est pas perçue de la même manière. Là encore, s’il y avait quelque chose d’urgent et d’important à faire, ce serait d’échanger le plus possible avec les experts du métier et ses pairs et de consulter les archives et les documents des projets antérieurs. Cela permettrait, de réussir une navigation à deux vitesses, en gérant le projet au quotidien tout en rattrapant l’équipe en termes de connaissances métier.
En fin, ce qui fait la vraie richesse d’un chef de projet, c’est le fait d’avoir accumulé des expériences sur différents domaines, exercé différents métiers et surtout de disposer de suffisamment de courage pour aller à la recherche de nouveaux défis.
Il faudrait juste disposer de l’humilité nécessaire pour ouvrir son esprit à toute information utile à la réussite de ses projets.
“PMI,” the PMI logo, “PMP,” “PMBOK,” “PM Network,” “Project Management Institute” and “Pulse of the Profession” are registered marks of Project Management Institute, Inc.
ELGUARNI Mehdi est ingénieur diplômé des Arts & Métiers et de l’École des Ponts ParisTech, certifié PMP®, Prince2, ISO31000, SMAC et SPOAC et actuellement Chef de Projet dans le secteur des Énergies.
Mehdi a géré des projets pendant 9 ans dans des projets de construction, de maintenance, d’études et de digitalisation.
Mehdi est aussi formateur en management de projet, bénévole du PMI France et rédacteur d’articles pour le PMI Lévis-Québec.
Face à un conflit, cela vaut la peine de considérer les parties impliquées et votre résultat préféré avant la négociation. Considérez quelles fins de partie vous êtes prêt à accepter et déterminez la meilleure approche à adopter pour atteindre votre fin de partie préférée.
Le Project Management Institute® (PMI®) propose de nombreuses formations en particulier pour préparer les certifications. Certaines, plus généralistes ou introductives sont ouvertes à toutes et tous gratuitement.
Voici le lien que j’utilise et qui liste toutes les formation en anglais et français de la gratuite à la plus onéreuse.
Chacun a sa propre interprétation de ce que signifie un produit minimum viable (MVP) pour son organisation et, bien que les spécificités d’une définition de MVP puissent varier, ce billet explore ce qu’est un MVP et ce qu’il n’est certainement pas.
Bien que votre définition personnelle du MVP de votre produit puisse varier, assurez-vous que vous ne vous basez pas sur l’une de ces fausses idées.
https://seths.blog/2021/11/the-lifeguard-hack/ par Seth Godin
Qui suis-je pour m’approcher de quelqu’un lors d’une soirée et me présenter ?
Qui êtes-vous pour démarrer un nouveau projet ?
Qui sont-ils pour donner une conférence sur la scène principale ?
Ne levez pas la main, quelqu’un d’autre pourrait avoir une meilleure question. Ne livrez pas ce travail, il n’est pas prêt…
Il y a des excuses, des comparaisons et des raisons infinies de se retenir.
Sauf si…
Sauf si vous êtes maître-nageur et que quelqu’un se noie. Dans cette situation, même si vous n’êtes pas le meilleur sauveteur du monde, et même si l’eau n’est pas à la parfaite température, et même si vous ne vous souvenez pas très bien comment faire la dernière version du porté croisé sur la poitrine… Vous sautez à l’eau.
Parce que ce n’est pas pour vous. C’est pour eux.
Le manager de projet se doit également d’intervenir si des membres de l’équipe rencontrent des difficultés qui mettent le projet en péril.Sans pour autant se prendre pour superman ou superwoman capables de résoudre seuls tous les problèmes et risques qui se présentent sur le projet.
Work Solo or Collaborate? How to Choose Based on What Benefits You
Pragmatic Manager Newsletter par Johanna Rothman
Certains d’entre vous préfèrent travailler seuls parce que vous savez être efficaces, même si votre travail n’est pas indépendant du travail des autres. Ou, si vous travaillez dans le cadre d’un groupe de travail, tel que les ressources humaines ou les finances, vous ne partagez qu’un objectif départemental, pas un objectif produit. Les groupes de travail peuvent ne pas avoir besoin de collaborer car leur travail peut être indépendant des livrables de quelqu’un d’autre.
Je vois trop de facteurs qui dissuadent de collaborer, même lorsque des personnes font partie d’équipes produits ou fonctionnalités, lorsque ces équipes partagent un objectif commun.
Mais, parfois, cela dépend non seulement du type de travail, mais aussi du contexte culturel.
La plupart des gens me disent qu’ils aiment le travail en solo parce qu’ils peuvent se concentrer. Cette approche « d’entrée dans la zone » vous permet de :
Vous sentez que vous avez davantage d’autonomie, de maîtrise et de sens lorsque vous travaillez seul.
Mais que se passe-t-il lorsque votre travail doit s’insérer ou s’intégrer au travail d’autres personnes ? L’un d’entre nous, même concentré, pourrait retarder tout le travail. (Vous pouvez mesurer le temps de cycle pour mesurer et visualiser ces délais.)
Bien que les gens puissent travailler seuls, le travail n’est pas indépendant.
C’est pourquoi je recommande aux responsables et aux équipes produit/fonctionnalité de collaborer dans leur travail.
Lorsque vous collaborez même avec une seule personne, vous pouvez :
Cependant, la collaboration n’est ni pour tout le monde ni pour chaque équipe ou groupe de travail. Souvent, c’est à cause de la culture de votre organisation.
À quel point êtes-vous occupé ? Vous démenez-vous pour atteindre votre objectif quotidien ou hebdomadaire parce que vous avez tellement de travail individuel à compléter ? C’est un signe que vos managers pensent à l’efficacité des ressources, pas à l’efficacité des flux. Vous pouvez choisir de collaborer avec d’autres, mais vous sentez-vous suffisamment en sécurité pour le faire, surtout si vous pensez que soutenir quelqu’un d’autre pourrait affecter négativement votre salaire ou votre prime.
Mais vous pourriez aussi vous sentir en danger pour d’autres raisons. Parfois, les managers croient que des personnes 10x (des surhommes) existent. Ensuite, les managers permettent aux supposées « superstars » de travailler comme des « empêcheurs ». Les empêcheurs détruisent le potentiel travail d’équipe et renforcent une culture désagréable.
Je vois ces options, surtout si vous vous sentez débordé de travail :
Vous pouvez imaginer d’autres options…
De nombreux managers croient que les gens peuvent travailler en solo parce que le travail de chaque personne est indépendant de l’autre. Cela peut être vrai pour un groupe de travail, tel que les ventes, les finances ou les ressources humaines. Mais ce n’est pas vrai pour les équipes de développement de produits.
Bien que vous puissiez travailler de manière indépendante, beaucoup d’entre vous apprennent mieux lorsque vous travaillez – au moins un peu – avec les autres. Considérez vos options pour le travail solo ou collaboratif et ce que vous ferez pour créer la culture souhaitée.
Je suis presque prête à annoncer le writing workshop du premier trimestre 2023. En attendant, n’hésitez pas à vous ajouter à la liste de diffusion si vous pensez que vous pourriez vouloir suivre cet atelier à l’avenir.
J’envisage également d’offrir des ateliers de management publics. Jusqu’à présent, je ne les proposais que sous forme d’ateliers privés internes. Si vous êtes intéressé par de tels ateliers, jetez un coup d’œil à cette page et ajoutez-vous à la liste de diffusion.
DantotsuPM.com 