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
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
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 !
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
Quelle que soit la façon dont votre équipe coordonne son travail, il est important que de tels événements ne soient pas perçus comme une perte de temps par l’équipe ou par les principales parties prenantes.
How does your team run their standups? par Kiron Bondale
Que vous les appeliez Scrums, stand-ups ou daily, une façon de planifier au fur et à mesure avec une approche adaptative est d’organiser régulièrement des événements de coordination pour s’assurer que tout le monde travaille de manière alignée et sur le travail le plus important.
L’un des sujets les plus courants pour de tels événements est de discuter de l’arriéré de travail de l’équipe à court terme.
Mais de telles discussions peuvent avoir lieu de différentes manières.
Pour s’assurer que tout le monde a la possibilité de s’exprimer, une approche pourrait être de discuter du travail incomplet personne après personne.
Bien que cela ait l’avantage de s’assurer que la voix de chacun soit entendue et donne à chaque membre de l’équipe l’occasion de remonter ses préoccupations ou de confirmer les hypothèses qu’il pourrait faire, cela peut également amener les membres de l’équipe qui ont déjà parlé à se désengager de ce qui est discuté par les membres de l’équipe qui viennent après eux. Bien que cela ne soit pas très préoccupant si le travail de chaque membre de l’équipe est indépendant des autres, dans la plupart des cas, il est probable qu’il y ait des dépendances entre les membres de l’équipe au niveau d’un élément de travail ou d’une activité.
Dans de tels cas, si un membre de l’équipe « s’est déconnecté » de la conversation, il pourrait manquer quelque chose d’important pour son travail ou manquer l’opportunité de corriger une hypothèse invalide faite par les autres.
Une alternative qui résout cet inconvénient est de travailler élément de travail par élément de travail. Cela est susceptible de garder la plupart des membres de l’équipe engagés plus longtemps que l’approche personne par personne, en particulier lorsque plusieurs membres de l’équipe doivent collaborer ensemble pour terminer un élément de travail. Cependant, lorsque certains membres de l’équipe ont terminé les éléments de travail qu’ils ont choisis et soutiennent maintenant activement les autres dans l’achèvement d’éléments de travail « étrangers », tous les membres de l’équipe peuvent ne pas avoir la chance de s’exprimer.
Lorsque les éléments de travail passent par un flux de travail bien défini, une autre option consiste à discuter des éléments de travail en fonction de la phase de développement dans laquelle ils se trouvent. En supposant que les membres de l’équipe travaillent sur des éléments à travers différentes phases, cela réduira la probabilité qu’un membre de l’équipe se désengage de la conversation générale, même s’il a déjà terminé la discussion des éléments de travail dans la phase en cours.
La plupart des outils de management du travail fournissent une méthode pour organiser les éléments dans les colonnes d’un tableau de travail afin que l’équipe puisse discuter des éléments incomplets dans l’ordre dans lequel ils sont présentés. Cependant, une approche plus efficace pourrait consister à donner la priorité aux quelques éléments vitaux qui méritent vraiment d’être discutés.
Il y a 3 façons courantes de le faire
Par coût du retard
Cela comprend des considérations telles que la valeur commerciale, la réduction des risques, la dépendance d’éléments de travail à venir ou la capacité d’exploiter une opportunité.
Par durée des éléments de travail
Visualisation sous forme de tableau Kanban
En supposant que l’équipe a atteint une maturité suffisante pour n’avoir que quelques tailles d’éléments de travail différentes, l’équipe pourrait se concentrer sur la discussion des éléments de travail actifs qui sont en dehors des attentes normales en matière de durée pour leur taille.
Par statut de l’élément de travail
Cela peut être fait en commençant par les éléments de travail bloqués, puis ceux avec des obstacles identifiés, puis (si nécessaire) les autres.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
Beaucoup d’équipes avec lesquelles j’ai travaillé utilisent une méthode personne par personne pour leurs événements de coordination, mais je voulais comprendre quelle était la répartition entre les différentes approches.
66 % ont utilisé une approche élément de travail par élément de travail,
20 % ont été traitées personne par personne,
11 % ont discuté des éléments de travail par étape de développement et
3 % ont eu une autre méthode.
Dans ce dernier cas, j’avais demandé aux répondants de fournir des détails, mais dans la plupart des cas, les commentaires reflétaient une approche par élément de travail et par ordre de priorité.
Quelle que soit la façon dont votre équipe coordonne son travail, il est important que de tels événements ne soient pas perçus comme une perte de temps par l’équipe ou par les principales parties prenantes. Discuter de l’efficacité et de l’efficience de tous les événements standard dans les sessions d’amélioration des processus, tels que les rétrospectives, est un moyen de s’assurer que cela ne se produise pas.
le livre de Kiron Bonale : « Easy in Theory, Difficult in Practice » contient 100 autres leçons sur le leadership de projet
(Si vous avez aimé cet article, pourquoi ne pas lire le livre de Kiron Easy in Theory, Difficult in Practice qui contient 100 autres leçons sur le leadership de projet ?)
Petit retour sur 7 précédents billets au sujet des Daily Scrum meetings
Dans ce billet, nous explorons comment les managers de projet peuvent se concentrer sur la création de valeur pour l’entreprise, l’un des nouveaux éléments de la réalisation de projet dans la septième version du Project Management Institute® du Project Management Body of Knowledge (PMBoK7).
Voici quelques façons importantes d’apporter de la valeur à votre entreprise lorsque vous managez des projets.
Concentrez-vous sur votre approche, pas seulement sur les résultats.
bien comprendre quelles sont les réalités business
La façon dont les managers de projet réalisent leurs projets peut être aussi importante que les résultats qu’ils et elles produisent. De nombreux projets sont perturbateurs parce qu’ils éloignent les dirigeants opérationnels de leurs tâches quotidiennes. Les managers de projet qui se concentrent sur la valeur consultent l’entreprise sur la planification du travail. Lorsque les délais sont menacés, ils et elles s’efforcent de comprendre les circonstances business.
Par exemple, des membres de l’équipe de projet peuvent être temporairement appelés pour régler une situation urgente qui est plus prioritaire que le projet. Compte tenu de cela, les managers de projet tiennent les parties prenantes informées de l’état du projet et écoutent lorsque des préoccupations sont soulevées. L’entreprise sera davantage susceptible de s’engager dans des projets futurs lorsqu’elle mettra l’accent sur la réalisation professionnelle des projets tout au long du cycle de vie du projet, ainsi que sur les résultats produits par les projets.
Considérez la valeur comme qualitative et quantitative.
PMI définit la valeur comme « la valeur, l’importance ou l’utilité de quelque chose ». Il est important de comprendre que l’évaluation par les parties prenantes de la valeur de « l’utilité » implique beaucoup plus que la façon dont les livrables satisfont une analyse de rentabilité.
La valeur est déterminée par la façon dont les livrables soutiennent les processus familiers et sont intégrés aux outils et aux processus en aval, bien plus que ce que montrent les bilans. La différence entre un livrable et une solution réside dans la façon dont les parties prenantes l’acceptent dans le cadre de leur routine quotidienne. Vous apportez de la valeur lorsque vos livrables sont considérés comme une solution.
Un projet de valeur n’est que le début.
Livrer des projets qui embrasse la valeur mène à plus de projets ! La valeur reçue inspire confiance et génère plus d’idées pour l’amélioration dans l’entreprise. Ceux-ci peuvent générer des demandes de modification de projet pour ajouter de la portée, ce qui peut ajouter de la valeur (ainsi qu’introduire des risques).
Les bons managers de projet discutent de la façon de maximiser la valeur, soit en intégrant la demande de changement, soit en organisant la demande pour la phase 2 du projet. Et ils et elles apprennent de ces demandes comment proposer des projets en aval pour apporter de nouvelles améliorations. De cette façon, la création de valeur est le début d’un parcours d’amélioration, pas la fin.
La valeur soutient la stratégie.
La façon dont les projets sont exécutés peut soutenir ou nuire à la stratégie de l’entreprise. Par exemple, une nouvelle application métier peut s’appuyer sur une plateforme technique existante, ou elle peut tirer parti d’une nouvelle architecture qui fait partie de la stratégie de l’entreprise. Dans un contexte différent, un bâtiment peut être construit avec des principes durables à l’esprit, en utilisant de l’énergie propre et en éliminant les déchets. Bien qu’il puisse être plus difficile de soutenir des initiatives stratégiques, les bons managers de projet travaillent avec leurs équipes et les parties prenantes principales pour mener leurs projets afin de satisfaire les objectifs à court et à long terme des stratégies d’entreprise.
Si vous avez des suggestions pour vous concentrer sur la valeur des projets, partagez-les.
“PMI,” the PMI logo, “PMP,” “PMBOK,” “Project Management Institute” and “Pulse of the Profession” are registered marks of Project Management Institute, Inc.
Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes
partagez ce billet avec vos amis, collègues et relations professionnelles
Bonjour, un pointeur fort utile aujourd’hui vers des méthodes (et une app) pour vous aider à impliquer tout le monde lors de vos sessions de travail de groupe.
Visitez le site en Français
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).
Le management du contenu consiste à s’assurer que votre projet produit ce qui est nécessaire et seulement ce qui est nécessaire pour atteindre les objectifs du projet.
Less Well-Known Benefits of Scope Management par Bonnie Biafore
Le management du contenu offre également des bénéfices supplémentaires dont vous entendez rarement parler.
Vous aidez à manager les risques.
Livre sur Amazon
Parlez à un chef de projet expérimenté et vous entendrez probablement une leçon durement apprise : Plus votre projet est grand, plus il devient risqué. Pour les initiatives qui nécessitent beaucoup de changements organisationnels et de livrables de projet, vous pouvez découper le périmètre et contenus en phases pour rendre les choses plus faciles à manager. Cette décomposition en morceaux plus petits réduit les risques et facilite l’absorption des changements par l’organisation, car ils sont appliqués par étapes progressives. À bien des égards, la façon la plus efficace de manager les risques d’un projet est de travailler en étroite collaboration avec vos parties prenantes pour gérer la portée.
Vous élargissez la compréhension des exigences de l’entreprise.
Le management du périmètre est mieux effectué par la discussion. Et la discussion aide non seulement l’équipe de projet à comprendre les besoins de l’entreprise, mais aide également l’entreprise à reconnaître ce qui est simple et ce qui est difficile à produire pour l’équipe projet.
De plus, une bonne gestion du contenu implique de hiérarchiser les exigences. Cela aide l’équipe projet à comprendre ce qui est vital pour l’entreprise et cela peut aussi améliorer la perspective de l’entreprise sur ses propres besoins ! Ainsi, l’entreprise et l’équipe projet sont mieux placées pour produire ce qui est le plus important, réduisant la portée et les risques.
Vous renforcez la confiance dans le projet.
Des conversations détaillées sur les contenus, y compris des questions bien réfléchies pour mieux comprendre les besoins opérationnels, peuvent aider à renforcer la confiance des parties prenantes dans la capacité de l’équipe projet à atteindre ses objectifs. Les bonnes questions qui inspirent l’analyse et la compréhension des besoins de l’entreprise peuvent renforcer la confiance : L’équipe projet sait ce qui doit être fait. Et démarrer un projet avec la confiance des parties prenantes de l’entreprise est un gros plus.
Vous vous adaptez aux ressources disponibles.
Les pénuries de compétences sont partout présentes et ont été amplifiées par les impacts de la pandémie Covid. Le management du périmètre et contenus aide tout le monde à être réaliste quant à ce qui peut et ne peut pas être fait. Les discussions sur les compétences disponibles aident à élaborer un échéancier de projet réaliste. La portée et la gestion des ressources favorisent des discussions productives sur la hiérarchisation des travaux, en particulier pour les ressources rares. Plus tôt ces conversations et hiérarchisations sont faites et comprises, plus il sera facile d’établir un planning robuste et de progresser tout au long du cycle de vie du projet.
Avez-vous observé d’autres bénéfices du management de la portée du projet ?
Si c’est le cas, partagez-les avec nous !
Pour en savoir plus sur Le management du périmètre et contenus, consultez le cours de Bonnie : Project Management Foundations.
Partenaire de DantotsuPM, visitez le site pour toutes les formations certifiantes proposées
partagez ce billet avec vos amis, collègues et relations professionnelles
« Mechanical Scrum » consiste à appliquer les principes et cérémonies de Scrum. « Professional Scrum » va plus loin, changeant la manière dont vous travaillez, pensez et agissez.
Cette brève vidéo de Scrum.org revient sur les idées qui supportent « Professional Scrum » et expose comment cela dépasse le Scrum Guide.
Et cette vidéo, plus longue et en français, entre dans les détails de ce qu’est Scrum Professionnel
French edition Scrum Pulse – Ne faites pas semblant, pratiquez Scrum professionnel ! avec Fabio Panzavolta
Scrum a été développé à l’origine pour des projets complexes de développement de logiciels. Il est maintenant utilisé pour presque tout type de produits crées en équipe. Le cadre, tel qu’il est défini dans le Guide Scrum, est un moyen simple mais puissant de mettre de l’ordre dans la complexité par l’apprentissage en fournissant des occasions fréquentes de feedback à la fois sur la façon de travailler et sur ce sur quoi nous avons et aurons à travailler.
Bien que de nombreuses personnes pratiquent Scrum, le pratiquer efficacement exige quelque chose de plus que de simplement suivre les mécanismes et les principes fondamentaux du cadre. Scrum professionnel aide les équipes à se défaire de cette habitude mécanique et routinière lorsqu’il s’agit de Scrum.
Dans ce webinaire Scrum Pulse, Fabio Panzavolta, PST @Scrum.org, partage avec les participants en quoi le Scrum professionnel est différent et comment il requiert les valeurs de Scrum, une mentalité et des méthodes de travail et de pensée différentes, en se concentrant sur les résultats et un environnement qui soutient le Scrum professionnel, y compris la confiance.
La septième édition du Guide PMBOK® définit une structure de répartition du travail (WBS) comme une « décomposition hiérarchique de la portée totale du travail à effectuer par l’équipe projet pour atteindre les objectifs du projet et créer les livrables requis ».
Bien que cette définition permette de bien comprendre ce qu’est une WBS, elle ne fournit pas de conseils sur la façon d’organiser la structure d’une WBS. Ceci est utile car cela donne aux équipes la flexibilité nécessaire pour déterminer quel est le moyen le plus approprié de le faire dans le contexte de leur projet.
Bien qu’il existe une variété infinie de projets, j’ai trouvé 3 approches utilisées par la plupart des équipes qui développent des WBS.
Axée sur les livrables – Chacun des composants de niveau supérieur de la WBS représente un livrable clé, et les niveaux suivants se concentrent sur la décomposition de ces livrables à un niveau de détail approprié.
Axée sur les phases – Chacune des composantes de niveau supérieur de la WBS représente une phase ou une étape du cycle de vie du projet, et les niveaux suivants se concentrent sur la décomposition des extrants de chacune de ces phases ou étapes.
Axée sur la responsabilité – Chacune des composantes de haut niveau de la WBS représente une partie prenante contribuant à l’exécution du projet, et les niveaux suivants se concentrent sur la décomposition des extrants produits par chacune de ces parties prenantes.
Une approche axée sur les livrables
Aide à concentrer l’équipe sur tout ce qui est nécessaire pour réaliser chaque livrable sans se soucier à ce stade de qui le fait ou quand cela serait fait. Cela peut bien fonctionner pour les projets où toute la portée d’un projet peut être décomposée dès le début, mais peut être difficile lorsqu’une approche par vagues (rolling waves) est adoptée, à moins qu’il n’y ait une identification claire des parties de planification qui doivent être élaborées à une date ultérieure.
Une approche axée sur les phases
Livre sur Amazon
Fonctionne bien avec une approche par vagues, car l’équipe n’a qu’à se concentrer sur ce qui sera achevé dans la phase à venir.
Cependant, il existe un risque que l’équipe manque des éléments clés de la portée pour des livrables spécifiques, car elle ne se concentrera pas sur la décomposition d’un seul livrable à la fois.
Une approche axée sur la responsabilité
Fonctionne bien lorsqu’il y a plusieurs parties prenantes et qu’il est nécessaire d’avoir une séparation claire des responsabilités en matière de planification et d’exécution. Elle présente le même risque que l’approche axée sur les phases, mais en plus grave, car il est possible que des livrables sous-composants soient assumés par chaque partie prenante comme étant la responsabilité d’une autre partie prenante.
Sondage auprès des professionnelles et professionnels du management de projet
57 % utilisaient une ventilation axée sur les livrables
28 % une approche axée sur les phases
9 % une approche axée sur la responsabilité
Les 6 % restants ont indiqué qu’ils utilisaient une autre approche, mais lorsque j’ai examiné les commentaires que ces participants avaient soumis, il semble qu’ils utilisent simplement une combinaison de ces méthodes plutôt que quelque chose d’entièrement nouveau.
Bien que le WBS soit un outil couramment utilisé avec des projets suivant un cycle de vie prédictif, cela ne signifie pas que ceux qui suivent un cycle adaptatif ne peuvent pas en bénéficier. Si nous considérons une user story map*, il s’agit simplement d’une WBS limitée entre deux et quatre niveaux et élaborée de manière progressive. Avec une Story Map, la structure peut être orientée persona (rôle des utilisateurs) ou thème/capacité.
Quelle que soit la façon dont votre équipe choisit de décomposer la portée du travail sur ses projets, une WBS ou une variante de celle-ci doit être considérée comme un instrument précieux dans sa boîte à outils.
Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes
* Une user story map est un outil puissant qui permet à une équipe agile de préparer son backlog de produit et de planifier plus efficacement les versions de produits. Une user story map capture le parcours d’un client avec le produit, y compris les activités et les tâches qu’il effectue avec le système.
partagez ce billet avec vos amis, collègues et relations professionnelles
Besoin d’aide sur la façon d’effectuer le travail en utilisant les pratiques traditionnelles de management de projet ?
Alors, « Process Groups: A Practice Guide » est le guide supplémentaire qu’il vous faut. Cet important complément A Guide to the Project Management Body of Knowledge (Guide PMBOK®) offre des conseils utiles et pratiques pour une approche prédictive ou en cascade des pratiques de management de projet. Ce guide de pratique influence votre façon de travailler, en veillant à ce que vous disposiez de l’information dont vous avez besoin pour réussir dans cette profession en constante évolution.
Une approche de management de projet basée sur les processus pour guider vos projets, aligner les méthodologies et évaluer les capacités en management de projet.
Ce guide utilise un modèle de groupes de processus populaire qui vous aidera à :
Le guide sur le site du PMI est disponible gratuitement pour tous les membres du PMI.
Initier
Planifier
Exécuter
Suivre et contrôler
Clôturer
En outre, vous découvrirez les 49 processus au sein de ces cinq groupes de processus, ainsi que les intrants, les outils et les techniques, ainsi que les extrants associés à ces processus. Ce guide pratique vous indique les processus considérés comme de bonnes pratiques sur la plupart des projets, la plupart du temps.
Langues : Anglais, d’autres langues seront disponibles début 2023.
Dans la 7e édition du Guide PMBOK, nous avions écrit que les groupes de processus de gestion de projet étaient toujours disponibles. Ils font partie des modèles répertoriés dans la section « Modèles, méthodes et artefacts ». Jusqu’à présent, ces groupes de processus étaient détaillés seulement dans la plateforme PMIstandards+. Maintenant, ils sont détaillés dans ce guide pratique, qui ne reprend du Guide PMBOK 6 que le contenu strictement nécessaire pour décrire les groupes de processus.
Nous avons maintenant un ensemble complet, cohérent et équilibré, avec l’édition 7 du Guide PMBOK, qui est la seule version de référence du PMBOK, complétée par une série de guides pratiques :
Livres sur Amazon
– Process Groups: A Practice Guide
– Agile Practice Guide
– Navigating Complexity: A Practice Guide, etc.
“PMI,” the PMI logo, “PMP,” “PMBOK,” “PM Network,” “Project Management Institute” and “Pulse of the Profession” are registered marks of Project Management Institute, Inc.
Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes
partagez ce billet avec vos amis, collègues et relations professionnelles
Ce modèle définit différentes approches pour résoudre les conflits, en tenant compte de deux dimensions :
Coopération (se préoccuper des besoins et désirs des autres)
Assertivité (se préoccuper de vos propres besoins et désirs)
Les 5 approches pour résoudre les conflits sont les suivantes
Compétition
Évitement
Compromis
Acceptation
Collaboration
Compétition : Vous gagnez, ils perdent
Utilisez cette approche lorsque la situation est urgente / critique (une résolution rapide est vitale) ou qu’il est essentiel que vous obteniez ce que vous voulez.
Attention, cela pourrait vous coûter votre relation avec l’autre partie !
Évitement : Personne ne gagne
Utilisez-le lorsque le problème n’est pas très important, ou du moins lorsque la relation avec l’autre partie est plus importante que ce problème.
Attention, cela ne fait pas disparaître le désaccord et il pourrait réapparaître plus tard.
Compromis : Personne ne perd… mais personne ne gagne vraiment
Utilisez-le lorsque vous avez besoin d’une solution temporaire à un problème complexe ou lorsque le problème est moins important que d’autres objectifs mutuels que vous avez avec l’autre partie.
Attention, cela pourrait convenir à court terme mais ce n’est pas tenable à long terme.
Acceptation : vous perdez, ils gagnent.
Utilisez-la lorsque le problème n’est pas aussi critique pour vous que pour les autres.
Quand il peut être important de faire preuve de souplesse ou d’être raisonnable. Elle peut aider à maintenir la coopération.
Méfiez-vous car cela pourrait renforcer la relation avec l’autre partie, mais cela pourrait aussi vous faire passer pour un « faible », de sorte qu’une situation similaire pourrait se reproduire.
Collaboration : vous gagnez tous les deux
Utilisez-la lorsqu’une solution à long terme et une relation durable sont essentielles.
Lorsque les problèmes des deux parties sont importants.
Les cinq méthodes sont légitimes.
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.
Bonne chance… oh, et les biscuits au chocolat aident aussi !
CSP DOCENDI est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
Petite vidéo en anglais.
partagez ce billet avec vos amis, collègues et relations professionnelles
Si déterminer quels systèmes, composants ou modules vous devriez « fabriquer » et lesquels vous devriez « acheter » reste un sujet difficile dans votre organisation informatique, quels sont les facteurs clés à considérer ?
« Agile » n’est pas une solution miracle. Le domaine est large, large et extrêmement sensible au contexte. Souvent, ce sont des nuances complexes qui font ou défont une approche. Dans ce billet, je veux partager mes expériences pour que d’autres puissent aussi apprendre.
Déterminer quels systèmes, composants ou modules nous devrions « fabriquer » et lesquels nous devrions « acheter » (par extension : utilisation à partir de l’Open Source) est un sujet difficile pour toute organisation informatique. Même lorsqu’il y a une position claire de la part de la direction du développement en faveur d’une option, ce vote est souvent formé avec une perspective myope : Les managers préfèrent « acheter » tout ce qu’ils peuvent, tandis que les développeurs hardcore préfèrent tout « faire ». Ni l’un ni l’autre n’est avisé. Mais comment décider ?
Il y a quelques facteurs clés en jeu
Facteurs
Détails
Disponibilité
Lorsqu’il existe une solution abordable et prête à l’emploi, « Achetez » pour éviter de réinventer la roue. Assurez-vous que prêt signifie prêt et « abordable » n’a aucune condition.
Unicité
Vous devez « faire » tout ce qui est unique à votre modèle business.
Adaptabilité
Lorsqu’il n’y a qu’un petit besoin de changement et de personnalisation, « Acheter » est préférable. Ne sous-estimez jamais « un petit changement ».
Durabilité
« Acheter » uniquement lorsque le coût initial et le coût du cycle de vie sont inférieurs. Inclure les coûts de migration et de décommissionnement.
Compétence
Si vous avez besoin de spécialistes que vous n’avez pas et que vous n’aurez pas, « Achetez » de quelqu’un qui les possède.
Dépendance
Si votre entreprise doit fermer ses portes quand la solution devient indisponible, « Acheter » vous met en dépendance de votre fournisseur.
Perte sèche
Vous pouvez « Acheter » pour gagner en vitesse même lorsque tous les indicateurs favorisent « Faire », si – et seulement si – vous êtes prêt à passer en perte sèche tout ce qui est investi dans la solution « Acheter ».
Choisissez judicieusement : Les réponses ne sont souvent pas si évidentes qu’elles en ont l’air.
Et vous, comment vous y prenez-vous pour répondre à la question : Faire ou acheter ?
partagez ce billet avec vos amis, collègues et relations professionnelles
Une estimation basée sur plusieurs points est-elle plus précise qu’une seule estimation ?
Si nous suivons la sagesse conventionnelle, il semblerait certainement que oui. La moyenne de plus d’une estimation est susceptible de nous donner un meilleur résultat.
En management de projet, il existe une technique d’estimation en trois points. Elle calcule la durée prévue sur la base de trois estimations différentes. Elle calcule la moyenne de trois estimations différentes pour déterminer l’estimation finale. Cette technique peut également être utilisée pour estimer les coûts et les ressources.
Bien qu’il semblerait qu’une moyenne basée sur trois points nous donnera de meilleurs résultats, a-t-elle une base scientifique ? Découvrons-le.
Historique de l’estimation en trois points
La méthode d’estimation en trois points a évolué à partir de la technique d’évaluation et d’examen des programmes (Program Evaluation and Review Technique : PERT). Elle a été développée pour la première fois par l’US Navy en 1958. Elle est couramment utilisée avec la méthode du chemin critique (Critical Path Method : CPM) qui a été introduite en 1957.
PERT a été développée pour soutenir le projet de sous-marin nucléaire Polaris de la marine américaine. Elle a été développée principalement pour simplifier la planification et la programmation de projets importants et complexes. Au fil du temps, elle a trouvé une application dans de nombreuses autres industries.
PERT essaie de déterminer le temps nécessaire pour terminer chaque activité de projet et tente de donner la durée minimale d’un projet.
Deux façons de faire une estimation en trois points
La technique d’estimation en trois points est utilisée lorsqu’il y a très peu d’informations. Elle est utilisée pour construire une distribution de probabilité approximative qui représente le résultat d’événements futurs.
Alors que la distribution normale peut être utilisée à des fins d’approximation, ce n’est pas toujours le cas. PERT utilise la distribution bêta pour calculer le résultat. Une autre façon de trouver le résultat est par la distribution triangulaire. Les deux techniques de distribution de probabilité peuvent être utilisées en fonction de l’application.
L’estimation en trois points a utilisé trois estimations différentes pour arriver à un résultat
Durée optimiste (O) : Elle représente le meilleur scénario ou le temps minimum possible requis pour terminer une activité. Elle suppose que tout se passera mieux que ce à quoi on s’attend normalement. Cette estimation est le scénario le plus idéal dans lequel tout fonctionnera parfaitement.
Durée pessimiste (P) : Elle représente le pire des scénarios ou le temps maximum requis pour terminer une activité. Elle suppose que tout ce qui peut mal tourner ira mal (sans compter les catastrophes majeures). Dans cette estimation, vous êtes confronté à des conditions ou des événements indésirables.
Durée la plus probable (M: Most Likely) : Elle représente le scénario réaliste ou la meilleure estimation du temps nécessaire à la réalisation d’une activité. Elle suppose que tout se déroulera normalement.
Sur la base de celles-ci, les trois estimations ci-dessus, la durée prévue est calculée.
La durée prévue est l’estimation moyenne du temps nécessaire pour terminer une activité. C’est la durée moyenne qu’une activité nécessiterait si elle était répétée plusieurs fois sur une longue période de temps.
En calculant la moyenne avec trois points, nous réduisons le risque de nous tromper.
Les deux méthodes pour faire une estimation en trois points
Distribution triangulaire
Elle calcule la moyenne ou la moyenne de trois estimations à l’aide de la formule suivante :
E = (O + M + P) / 3
Distribution bêta PERT
Cette distribution donne plus de poids au scénario le plus probable lors du calcul de la moyenne ou de la moyenne. Il utilise la formule suivante :
E = (O + P + 4*M) / 6
Exemples
Scénario I
O=9, M=12, P=18
Distribution triangulaire
E = (O + M + P)/3 => E = (9 + 12 + 18)/3 => E = (39)/3 => E = 13
Distribution bêta PERT
E = (O + P + 4*M)/6 => E = (9 + 18 + 4*12)/6 => E = (9 + 18 + 48)6 => E = (75)/6 => E = 12,5
Scénario II
O=9, M=15, P=18
Distribution triangulaire
E = (9 + 15 + 18)/3 => E = (42)/3 => E = 14
Distribution bêta PERT
E = (9 + 18 + 4*15)/6 => E = (9 + 18 + 60)/6 => E = (87)/6 => E = 14,5
Nous pouvons tirer deux observations des calculs ci-dessus.
Si la plus probable est plus proche de la valeur optimiste, la moyenne est supérieure à la durée la plus probable. D’autre part, si le plus probable est plus proche de la valeur pessimiste, la moyenne est inférieure à la durée la plus probable.
Les résultats de la distribution bêta PERT sont plus proches de la durée la plus probable que ceux de la distribution triangulaire.
Conclusion
Il est préférable de faire une estimation en trois points en faisant des recherches sur l’activité ou en contactant un expert. L’essentiel est de trouver des estimations raisonnables pour optimiste, très probable et pessimiste. C’est une bonne idée d’enregistrer des notes sur la base de chaque estimation. Pensez aux conditions qui sont susceptibles de se produire lorsque l’activité est entreprise.
Quelques points importants à noter
Cette estimation est plus précise que l’estimation analogue et paramétrique
Cette estimation permet de tenir compte des incertitudes et des risques.
Cette estimation est généralement utilisée lorsqu’il n’y a pas assez de données historiques ou lorsque vous utilisez des données plus subjectives.
Il n’y a pas de méthode correcte pour l’estimation en trois points. Les 2 méthodes de distribution triangulaire et bêta sont des méthodes valides. La méthode que vous choisirez dépendra de la nature de votre travail et de vos processus organisationnels. Vous pouvez essayer d’expérimenter avec les deux méthodes et découvrir quelle méthode vous donne de meilleurs résultats.
Les deux communautés, Agile et Kata, ne sont pas nouvelles. Ils ont des décennies d’expérience et de preuves de succès. Il y a des années, lorsque j’ai commencé à chercher de meilleures façons de diriger les transformations agiles, je suis tombé sur le Toyota Kata et j’ai construit un pont entre ces approches. Vous pourriez dire que le Agile Kata en lui-même est nouveau, mais les utilisateurs exploitent la richesse des expériences et des succès de deux communautés. L’intersection où Agile et Kata se rencontrent est nouvelle. Je l’ai nommé « Agile Kata » pour la rendre plus facile à référencer et à identifier.
À quoi sert l’Agile Kata ?
Agile Kata est un modèle pour aider les organisations à créer et à accroître l’agilité de l’entreprise. Comparativement, Agile Kata est appliqué au niveau organisationnel comme Scrum et Kanban le sont au niveau de l’équipe. Vous pouvez utiliser Agile Kata pour piloter une transformation agile, créer une culture agile ou conduire un changement organisationnel.
Si vous cherchez de meilleurs moyens d’augmenter l’agilité de votre entreprise avec Agile Kata
Consultez le livre blanc Agile Kata white paper sur www.agilekata.org.
Ne forcez pas l’agilité sur chaque projet que vous exécutez simplement parce que les méthodologies agiles et itératives sont « à la mode ». Pour réussir avec agile, assurez-vous que vos projets sont de bons candidats agiles.
Voici les questions à vous poser avant de sélectionner une approche agile pour un projet.
Le projet est-il suffisamment important pour que les bonnes personnes s’y consacrent ?
Agile produit des résultats rapidement, ce qui nécessite un gros investissement de temps pour les membres de votre équipe. Les équipes agiles sont composées de gens du business et de personnes techniques qui sont essentiels à vos opérations commerciales. Assurez-vous qu’ils ont suffisamment de temps pour contribuer à votre projet. Cela nécessite souvent des compromis difficiles entre le travail de projet et les opérations.
Les membres de votre équipe ont-ils suffisamment de profondeur et d’étendue de connaissances ?
Ce qui rend les méthodologies agiles agiles, c’est la réactivité à l’évolution des besoins. Les experts du métier travaillent en étroite collaboration avec les experts de l’équipe technique pour fournir ce qui est nécessaire -> rapidement. Pour cela, votre équipe a besoin d’une connaissance approfondie des domaines métiers et techniques touchés par le projet. L’équipe réévalue constamment les besoins business du projet aux niveaux du produit, les fonctionnalités macros et micros et la priorité du besoin.
Votre sponsor a-t-il un état d’esprit agile ?
La réactivité agile à l’évolution des conditions business et son approche apprentissage sont très différents des méthodes de projet traditionnelles.
Votre sponsor doit être à l’aise avec l’évolution des besoins et des priorités de l’entreprise, prêt à participer à des revues fréquentes du produit en pleine évolution et prêt à intervenir pour obtenir les ressources agiles dont le projet a besoin.
Votre équipe peut-elle être co-localisée ou virtuellement co-localisée ?
Agile implique un dialogue profond, interactif et souvent dérangeant, qui nécessite l’environnement le plus riche que vous puissiez créer. Co-localisez les membres de votre équipe de projet si possible. Si vous ne pouvez pas, simulez la co-localisation avec les meilleurs outils vidéo et audio que vous pouvez obtenir.
Y a-t-il une synergie entre les membres business/métiers et technique de votre équipe ?
L’agilité nécessite le dévouement d’experts business et techniques qui soient ouverts aux nouvelles idées et se soutiennent mutuellement. 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. Pour réussir, une équipe agile doit bien s’entendre.
Le produit peut-il être construit de manière itérative ?
Les meilleures qualités d’Agile proviennent de la fourniture de parties utilisables de la solution tout en apprenant de chaque itération. Bien que ce soit plus courant avec les produits logiciels, d’autres produits peuvent également être fabriqués de cette façon. Avec un peu de créativité, les déménagements, les déploiements de processus et même certains projets de construction peuvent être produits par étapes itératives.
Les mêmes leçons sont capturées projets après projets, mais rien ne change !
Un obstacle majeur à la livraison est l’incapacité des équipes de direction et de développement à apprendre des erreurs commises dans le passé. En n’appliquant pas les apprentissages, les équipes sont coincées dans un cycle semblable à celui de la journée de la marmotte où des problèmes similaires continuent de se produire, les mêmes leçons sont capturées projets après projets, mais rien ne change.
Inutile de dire que cela m’a rendu (plus) cynique. Mais hier, j’ai été témoin de quelque chose qui me donne de l’espoir pour certaines organisations.
Vivant au Canada, l’une des façons dont beaucoup d’entre nous marquent le changement de saison est de changer les pneus sur nos véhicules. Lorsque les températures commencent à être régulièrement basses, le caoutchouc des pneus toutes saisons ou été durcit comme du marbre et vous n’avez plus une adhérence sûre sur les routes.
Au Québec, les conducteurs sont tenus d’installer des pneus d’hiver, mais cela reste facultatif en Ontario. Quoi qu’il en soit, de nombreux conducteurs ontariens accordent la priorité à la sécurité plutôt qu’à la frugalité en changeant leurs pneus au mois de novembre.
J’avais pris rendez-vous avec mon association automobile locale pour qu’un mécanicien vienne chez moi pour changer les pneus de mon véhicule électrique.
Pour ceux d’entre vous qui ne sont pas familiers avec les conceptions des véhicules électriques, la batterie est positionnée normalement sur toute la longueur de la voiture et elle est située sous le véhicule. En conséquence, il faut faire attention lors de l’utilisation d’un cric pour élever la voiture car une pression excessive pourrait causer de graves dommages à la batterie. Et comme la batterie d’un véhicule électrique peut représenter jusqu’à 50% du coût de la voiture, la plupart des propriétaires voudraient éviter d’encourir des dommages dus à une négligence de leur part !
Lorsque le mécanicien est arrivé, il n’avait pas d’entretoise nécessaire pour créer un tampon entre le cric et le dessous de la voiture. Je lui ai expliqué que je ne le laisserais pas soulever la voiture sans cela, alors il a appelé son central. La personne s’est emparée du problème et l’a rappelé quelques minutes plus tard pour lui faire savoir qu’il pouvait récupérer un ensemble de dispositifs de protection dans un magasin de pièces automobiles situé à proximité. Le mécanicien est parti et est revenu peu de temps après et a terminé les travaux comme prévu.
Application et systématisation immédiate de la leçon apprise !
Je m’attendais à ce que la personne au central, le dispatcher ait autorisé l’achat d’un seul jeu d’entretoises pour le camion de ce mécanicien. Cependant, alors que je payais la facture, le mécanicien m’a dit que le dispatcher avait contacté le magasin de pièces automobiles et avait passé une commande de suffisamment d’appareils pour que chacun des camions de l’association automobile soit correctement équipé.
Intégrez la leçon apprise dans la formation de tous les managers de projets.
Lorsque vous identifiez une leçon sur votre projet, il est bon que vous puissiez l’appliquer peu de temps après. Mais pourquoi ne pas aller plus loin et trouver un moyen de s’assurer que cela fasse partie des normes et des pratiques de votre organisation ?
Les leçons que nous apprenons vraiment sont celles qui empêchent quiconque dans notre entreprise de répéter les erreurs que nous avons commises.
QRP est partenaire de DantotsuPM, visitez cette page pour en apprendre davantage
Précédents billets sur les leçons apprises / lessons learned
Les projets repoussent toujours les limites, combinant des éléments, des idées et des efforts pour faire quelque chose qui n’a jamais été fait auparavant, pas tout à fait comme nous le faisons ici et actuellement.
Et donc, parfois les projets audacieux ne parviennent pas à respecter leurs échéances. Même si nous construisons des systèmes et intégrons des marges de temps, parfois cela ne fonctionne pas.
Quelques réflexions
#1 – N’attendez pas la dernière minute.
Les vœux pieux sont parfois confondus avec l’optimisme, mais vous saviez probablement plus de quatre jours avant la date limite que vous n’alliez pas répondre aux attentes. Si les gens construisent des dépendances autour de vos promesses, alors attendre que vous n’ayez plus le choix ne fait qu’aggraver la situation. Parce que non seulement vous êtes en retard, mais vous le cachiez.
#2 – Ne minimisez pas le problème.
Vous êtes en retard. Clairement. Alors dites-le. Fort et (pas tout à fait) avec fierté.
En reconnaissant la promesse originale et en étant clair que vous êtes conscient de l’échec, vous aidez les personnes qui comptaient sur vous à se sentir entendues et respectées.
#3 – Créez des alternatives.
Ce n’est pas toujours possible, mais quand c’est le cas, cela conduit généralement à de meilleures relations. Si une compagnie aérienne ne peut pas avoir un avion à un certain endroit à un certain moment, cela va grandement contribuer si elle fait le travail de trouver une nouvelle proposition pour les 100 personnes qui ont incommodées, au lieu de mettre cette charge sur elles, une par une.
#4 – Il y a une différence entre observer les dégâts (et travailler pour améliorer la situation) et accepter la honte et le blâme.
Il est clair que l’avenir n’est pas clair et que des choses surviennent.
Téléchargez ce guide sur le site de notre partenaire Virage Group
#5 – En bref, il n’y a pas de bon moyen de faire en sorte qu’une échéance manquée n’ait aucun impact pour la personne qui comptait sur vous.
Que des gens comptent sur vous est un cadeau. Si vous voulez qu’on compte sur vous la prochaine fois, mieux vaut investir au plus tôt et souvent dans le respect de cette échéance, puis, dans les rares cas où ce n’est pas suffisant, traitez vos clients avec le respect que vous aimeriez recevoir dans une situation similaire.
Il y a de plus en plus de projets dans votre organisation et vous ne savez quelle méthode ou approche choisir pour le prochain ?
Travailler en mode projets est devenue la norme dans de nombreuses situations : digitalisation, innovation, développement de nouveaux produits et services, changement dans les organisations, télétravail généralisé, besoins de gains de productivité, amélioration de la qualité…
CSP DOCENDI est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
Les projets sont au cœur de nos entreprises et organisations. Cependant, derrière la notion du travail en mode projets, se cachent plusieurs méthodologies qui ont leurs supporters et leurs détracteurs. Souvent, ceux-ci sont extrêmement convaincus de détenir la seule et unique bonne méthodo : Prédictive/Cycle en V/Classique/Séquentielle ou bien Adaptative/Itérative/Agile, voire hybride…
Comment vous repérer dans ces approches et surtout choisir celles qui correspondent le mieux à vos besoins, votre contexte, votre culture d’entreprise, vos spécificités ?
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.
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 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.
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.
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.
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.
Le management du périmètre est mieux effectué par la discussion. Et la discussion aide non seulement l’équipe de projet à comprendre les besoins de l’entreprise, mais aide également l’entreprise à reconnaître ce qui est simple et ce qui est difficile à produire pour l’équipe projet.
Des conversations détaillées sur les contenus, y compris des questions bien réfléchies pour mieux comprendre les besoins opérationnels, peuvent aider à renforcer la confiance des parties prenantes dans la capacité de l’équipe projet à atteindre ses objectifs. Les bonnes questions qui inspirent l’analyse et la compréhension des besoins de l’entreprise peuvent renforcer la confiance : L’équipe projet sait ce qui doit être fait. Et démarrer un projet avec la confiance des parties prenantes de l’entreprise est un gros plus.
Les pénuries de compétences sont partout présentes et ont été amplifiées par les impacts de la pandémie Covid. Le management du périmètre et contenus aide tout le monde à être réaliste quant à ce qui peut et ne peut pas être fait. Les discussions sur les compétences disponibles aident à élaborer un échéancier de projet réaliste. La portée et la gestion des ressources favorisent des discussions productives sur la hiérarchisation des travaux, en particulier pour les ressources rares. Plus tôt ces conversations et hiérarchisations sont faites et comprises, plus il sera facile d’établir un planning robuste et de progresser tout au long du cycle de vie du projet.
Elle présente le même risque que l’approche axée sur les phases, mais en plus grave, car il est possible que des livrables sous-composants soient assumés par chaque partie prenante comme étant la responsabilité d’une autre partie prenante.
DantotsuPM.com 