La raison pour laquelle le titre de cet article est entre guillemets est qu’il s’agit d’une question fréquemment posée dans les groupes de discussion sur http://projectmanagement.com et le groupe LinkedIn Project, Program and Portfolio Management de PMI. Avec un certain nombre d’autres contributeurs, je l’ai vue et y ai répondu suffisamment de fois pour que je pense que cela vaut la peine de partager mes réflexions avec mon lectorat.
Détails de la certification sur le site du PMI
La certification PMP® est la référence en management de projet que la plupart des recruteurs et des managers connaissent. Les personnes averties savent que si elle ne fournit aucune garantie de compétence, elle démontre au moins qu’un praticien a une certaine compréhension de base de la nomenclature, des outils et des techniques.
Bien qu’avoir obtenu cette certification ait été un facteur de différenciation au cours des premières décennies suivant son introduction, à ce stade, elle l’est moins, mais dans certaines industries et régions spécifiques, ne pas l’avoir pourrait entraîner le rejet d’une candidature par le processus de filtrage initial.
Mais une fois qu’un praticien a obtenu sa certification PMP, que se passe-t-il ensuite ?
Le développement professionnel devrait être la quête de toute une vie (ou du moins d’une carrière), et les certifications fournissent des preuves tangibles qu’une personne investit dans son développement, donc cette question semble raisonnable.
Avant de poser cette question, la personne doit avoir identifié un objectif de carrière ou de développement spécifique. Dans certains cas, cela peut être simple, par exemple si une certification particulière est requise dans le cadre des conditions préalables à une promotion dans l’entreprise.
Mais c’est rarement le cas et c’est ce qui rend les choses plus difficiles.
Les entreprises qui développent et gèrent des certifications de compétences déclareront toutes avec confiance que leurs produits vous aideront à faire progresser votre carrière. Pourquoi pas ? Pour chaque personne qui adhère à cette justification, l’organisation d’accréditation gagnera généralement un montant initial puis un flux de revenus continus.
Mais à moins qu’un rôle particulier auquel vous aspirez exige que vous ayez une certification de compétence spécifique, dans la plupart des cas, tout ce que cela prouvera, c’est que vous avez appris quelque chose et que vous avez réussi un test. Vous l’avez peut-être fait sans pratique concrète dans ce domaine.
Visitez ce site
Maintenant, si vous avez déjà acquis de l’expérience dans un domaine et que vous souhaitez ensuite avoir des preuves visibles de votre acquisition de certaines connaissances, alors un certificat de compétence est un moyen de le faire. Mais si vous voulez apprendre une nouvelle compétence, vous feriez mieux de vous auto-éduquer ou de prendre un cours sans certification et de les faire suivre d’un travail pratique réel supporté par un praticien chevronné.
Aussi, les seules réponses correctes à la question initiale sont :
Quels sont vos objectifs de développement ?
ou
Pourquoi recherchez-vous une autre certification ?
“PMI,” the PMI logo, “PMP” and “Project Management Institute” are registered marks of Project Management Institute, Inc.
Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes
Si vous ne savez pas où vous allez, n’importe quelle route vous y mènera – Lewis Carroll
partagez ce billet avec vos amis, collègues et relations professionnelles
Vous avez du mal à expliquer DevOps et tout ce qu’il englobe aux non-techniciens ? Les gens se demandent-ils ce que font réellement les ingénieurs DevOps de votre équipe ?
Ces définitions et analogies vous aideront à leur répondre.
Le terme DevOps a été créé il y a plus de 10 ans, et ce qui a commencé comme un hashtag est devenu un mouvement culturel dans l’informatique. Cette philosophie encourage les développeurs à aller vite, à expérimenter et à itérer. DevOps est devenu intrinsèquement lié à la transformation numérique. Mais en ce qui concerne la terminologie informatique, une décennie est amplement suffisante pour accumuler des définitions, des interprétations et une grande confusion autour de ce que DevOps signifie réellement.
DevOps est-il la même chose qu’Agile ? Est-ce une méthodologie ? Est-ce juste une autre façon de dire collaboration ? Que font réellement les ingénieurs DevOps ? Avons-nous besoin de ce titre, ou n’est-ce qu’un effet de mode ?
Parce que DevOps englobe de nombreux concepts différents (livraison continue, intégration continue, automatisation, etc.), il peut être difficile, en particulier pour ceux qui sont les plus passionnés par ce sujet, d’essayer de réduire DevOps à une courte phrase. Mais, rappelons-nous, les petites phrases peuvent être utiles, que vous essayiez de vendre l’idée dans la chaîne de management ou d’expliquer ce que vous faites à quelqu’un lors d’une fête. Donc, pour l’instant, mettons de côté les nuances autour de termes spécifiques à DevOps et concentrons-nous sur la vue d’ensemble.
Qu’est-ce que DevOps en 6 définitions et analogies ?
Nous avons demandé aux experts DevOps comment ils expliquent DevOps avec leurs mots les plus courts et les plus simples afin que tout le monde puisse comprendre sa valeur, quelle que soit sa formation technique. Voici quelques définitions percutantes et quelques analogies utiles pour vous aider à raconter votre propre histoire DevOps.
1. DevOps est un mouvement culturel
Visitez ce site
« DevOps est un mouvement culturel où les deux principaux groupes de parties prenantes (développeurs de logiciels et opérations informatiques) conviennent que le logiciel n’ajoute pas vraiment de valeur tant qu’il n’est pas utilisé par quelqu’un – clients, utilisateurs, employés, etc. » explique Eveline Oehrlich, directrice de recherche en chef au DevOps Institute.
« Pour cette raison, les deux équipes veillent ensemble à ce que les logiciels soient livrés avec rapidité et qualité. »
2. DevOps responsabilise les développeurs
DevOps permet aux développeurs de posséder, d’exécuter et de manager de bout en bout la livraison d’une application.
« Il est communément admis que DevOps permet une livraison en production plus rapide en mettant en œuvre et en exploitant des processus automatisés. Pour moi, c’est beaucoup plus fondamental », explique Jai Schniepp, propriétaire de produit senior de plates-formes DevOps sécurisées chez Liberty Mutual.
« DevOps permet aux développeurs de posséder, d’exécuter et de manager de bout en bout la livraison d’une application ou d’un logiciel. DevOps élimine la confusion autour de la propriété et conduit l’équipe vers une infrastructure automatisée et managée par les développeurs. »
3. DevOps est une approche collaborative de création et de livraison de logiciels
« En termes simples, DevOps est une approche de création et de fourniture de logiciels informatiques dans laquelle tout le monde travaille ensemble », explique Gur Steif, président de l’automatisation des activités numériques chez BMC.
4. DevOps est comme une chaîne de montage
Pour qu’une chaîne de montage fonctionne, les composants doivent être conçus pour s’assembler de manière transparente.
« Je comparerais DevOps à une chaîne de montage », déclare Gur Steif. « L’idée est de concevoir et de construire toutes les pièces à l’avance, de manière à ce que toutes les pièces s’emboîtent. Pour qu’une chaîne de montage fonctionne, les composants doivent être conçus pour s’assembler de manière transparente. Les gens qui conçoivent et construisent les moteurs doivent penser au châssis et aux supports de moteur. Les gens qui construisent des freins doivent penser aux jantes et aux pneus, et ainsi de suite. C’est comme ça que ça doit être dans le logiciel. Les développeurs qui écrivent la logique métier ou l’interface utilisateur doivent penser à la base de données qui stocke les informations client, à la sécurité qui protège les données utilisateur et à la façon dont tout cela fonctionne lorsque le service est exposé à ce qui peut être des millions d’utilisateurs.
« Amener les gens à collaborer et à penser au travail effectué par d’autres plutôt que de se concentrer uniquement sur leur(s) tâche(s) individuelle(s) est le plus grand obstacle à surmonter. Si vous y parvenez, vous avez d’excellentes chances de réaliser la transformation numérique », ajoute Steif.
5. DevOps est une recette – combinant les personnes, les processus et l’automatisation
Jayne Groll, PDG du DevOpsInstitute, a une excellente analogie culinaire pour expliquer DevOps :
DevOps est une recette qui repose sur des ingrédients de trois grandes catégories : les personnes, les processus et l’automatisation.
La plupart des ingrédients peuvent être adaptés à partir d’autres pratiques et sources bien connues telles que Lean, Agile, SRE, CI / CD, ITIL, le leadership, la culture et les outils. Le secret derrière DevOps est la façon dont ces ingrédients sont combinés et dans les bonnes proportions (comme toute bonne recette) afin d’augmenter le flux et la valeur pour le client.
6. Les équipes DevOps sont comme les équipes de course NASCAR
Les équipes de course ne réfléchissent pas du départ à l’arrivée; Elles tournent la table pour considérer la course de la ligne d’arrivée au départ.
« Lorsque je parle des résultats souhaités pour une initiative DevOps, je mentionne NASCAR ou les courses de F1 », explique Chris Short, responsable marketing technique principal, plates-formes cloud, chez Red Hat, et éditeur de la newsletter DevOps’ish.
« Les chefs d’équipe de ces équipes de course n’ont qu’une mission : Finir à la meilleure place possible avec les ressources dont ils disposent tout en surmontant l’adversité à laquelle ils sont confrontés. Les équipes de course ne réfléchissent pas du départ à la ligne d’arrivée ; Elles renversent la problématique pour regarder la course de la ligne d’arrivée au départ. Elles se fixent un objectif, un objectif ambitieux, puis commencent à travailler à rebours à partir de ces objectifs pour déterminer comment y arriver. Le travail est délégué aux membres de l’équipe pendant la semaine de la course pour atteindre l’ensemble des objectifs qui permettent d’obtenir le résultat souhaité. »
« Les équipes de course pratiquent les arrêts aux stands toute la semaine avant la course. Elles suivent des programmes de musculation et de cardio pendant la semaine pour se garder physiquement prêtes pour les conditions exténuantes du jour de la course. Elles collaborent continuellement pour résoudre tout problème qui pourrait survenir. De même, les équipes logicielles devraient pratiquer souvent les livraisons. Si les systèmes de sécurité sont en place et que les essais se déroulent bien, la mise en production se produit plus fréquemment. La vitesse rend les choses plus sûres avec cet état d’esprit », explique Short.
« Il ne s’agit pas de faire la « bonne » chose », ajoute-t-il, « il s’agit d’adresser autant de choses qui pourraient vous empêcher d’obtenir le résultat souhaité que possible. Collaborez et ajustez en fonction des retours en temps réel que vous observez. Attendez-vous à des anomalies et travaillez pour améliorer la qualité afin de minimiser l’impact de ces anomalies sur l’objectif. Ce sont les attentes de chacun dans un monde DevOps. »
Qu’est-ce qu’un ingénieur DevOps ?
Un mouvement culturel, une méthodologie, une recette pour réussir : Remarquez comment personne n’a fait référence à DevOps comme à un rôle.
Pourtant, l’ingénieur DevOps figure en bonne place sur la liste des meilleurs emplois de Glassdoor en Amérique, et ce chaque année depuis 2017. Est-il logique d’étiqueter le mot « DevOps » sur le titre d’une personne lorsque des organisations informatiques toutes entières sont invitées à travailler d’une nouvelle manière ?
Certains croient fermement que la réponse est non.
« DevOps est une méthodologie, pas un rôle», explique Neelan Choksi, président et chef de l’exploitation chez Tasktop. « Plutôt que d’étiqueter vos ingénieurs « ingénieurs DevOps », vous devez reconnaître que le rôle de l’ingénieur dans le développement et les opérations a évolué et continue de le faire. Parce que le cloisonnement des organisations en départements appartient au passé, le changement perpétuel n’est plus le travail d’un département et le problème d’un autre.
En fait, trop se concentrer sur les rôles individuels peut freiner les organisations, dit Choksi. « Si [dans votre organisation] la culture DevOps est plutôt considérée comme un job ou un rôle unique, vous pouvez toujours apporter de petites améliorations locales en adoptant les meilleures pratiques DevOps, mais l’impact de ces pratiques sera limité. »
A l’autre extrémité du débat, certains soutiennent que les titres sont significatifs, surtout lorsque les industries traversent des transformations majeures. Inclure le terme DevOps sur un CV ou une description de poste indique un niveau de compétence qui est actuellement difficile à trouver, dit Oehrlich.
« J’ai suivi la transformation DevOps en tant qu’analyste de l’industrie depuis ses débuts », a récemment écrit Oehrlich. « Aujourd’hui, l’utilisation de la méthodologie DevOps est de 74 % (en dehors des méthodologies complémentaires), avec une adoption à l’échelle de l’entreprise de 24 % et une adoption projet (ou projets multiples) de 42 %, selon le rapport Upskilling 2020 : Enterprise DevOps Skills Report. »
Le défi numéro un auquel est confronté DevOps est de trouver et d’attirer des personnes DevOps qualifiées. 58 % des personnes interrogées ont déclaré que trouver des personnes qualifiées est un énorme défi, tandis que 48 % disent que la rétention de personnes DevOps qualifiées est un challenge.
Quelle que soit votre position dans le débat en cours sur les ingénieurs DevOps, Choksi et Oehrlich ont tous deux des conseils sur ce qu’il faut rechercher chez les personnes qui dirigent DevOps dans votre organisation :
« Les ingénieurs DevOps doivent se concentrer sur leurs compétences en résolution de problèmes et sur leur capacité à accroître l’efficacité, à gagner du temps et à automatiser les processus manuels et, surtout, à se soucier de ceux qui utilisent leurs livrables », explique Choksi. « L’ingénieur à l’épreuve du temps est capable de travailler entre les équipes et les fonctions, non seulement au sein de l’informatique, mais aussi dans l’ensemble de l’entreprise. Ils sont en mesure de tirer parti de spécialistes et d’intégrer les approches et méthodologies optimales qui offrent de la valeur dans un environnement concurrentiel rapide avec la qualité requise par les clients. »
« Le titre d’ingénieur DevOps décrit une façon différente de concevoir », explique Oerhlich. « Bien qu’il existe des responsabilités fondamentales pour un ingénieur DevOps (codage, script, ré-ingénierie, automatisation, collaboration et communication), le rôle lui-même est un rôle d’ingénierie. L’ingénierie est une question d’innovation, la créativité étant un trait humain fondamental qui stimule le développement de nouvelles technologies et de nouveaux produits, processus ou services. La combinaison des mots « DevOps » et « ingénieur » met en avant que l’avenir est à l’innovation autour de la façon dont le développement et les opérations sont effectués ensemble : Le titre « ingénieur DevOps » souligne cet état d’esprit. »
partagez ce billet avec vos amis, collègues et relations professionnelles
Votre management des risques doit rester aussi simple que possible et néanmoins vous garantir que les réponses sont faisables, économiquement viables et efficaces.
#1 – Identifiez correctement le propriétaire de chaque risque.
Une fois qu’un risque a été identifié, En tant que manager de projet, vous devez vous demander : « À qui appartient le risque ? ». Le propriétaire de risque est la personne responsable de l’élaboration et de l’exécution du plan de réponse à ce risque.
#2 – Détectez et réagissez aux petits risques connexes.
De nombreux risques sont connectés.
Plusieurs petits risques connexes peuvent avoir un effet boule de neige qui mène éventuellement à un événement important. Apprenez à bien mettre en évidence les connexions entre les risques, comment les percevoir, puis travaillez à les détecter.
#3 – Identifiez et managez les risques secondaires.
Certaines réponses à un risque peuvent déclencher une avalanche d’autres risques.
Lorsque les propriétaires des risques élaborent des plans de réponse à leurs risques, elles ou ils peuvent ne pas tenir compte des risques secondaires. Les risques secondaires sont ceux qui découlent directement de la mise en œuvre d’une réponse au risque primaire. Certaines solutions et plans d’action pour manager un risque pourraient générer d’autres problèmes potentiels.
En tant que manager de projet expérimenté, vous éduquez et demandez à vos propriétaires de risques d’identifier et de planifier les risques secondaires importants.
#4 – Élaborez des plans de contingence.
Certains plans de réponse aux risques doivent être exécutés immédiatement, d’autres sont de ‘contingence’. Ces plans conditionnels ne seront exécutés que si certaines conditions prédéfinies sont remplies.
#5 – Préparez des plans de secours.
Quel est votre plan de secours si celui prévu pour manager le risque échoue ?
Que doit faire un propriétaire de risque si le plan de réponse au risque échoue ?
Elles ou ils devraient mettre en place et être prêts à exécuter un plan de secours pour les risques importants.
Le plan de secours peut être utilisé pour atténuer une menace ou tirer bénéfice d’une opportunité.
#6 – Identifiez clairement les déclencheurs de risque.
Qu’est-ce qui pourrait déclencher ce risque ?
Certains managers de risques font un excellent travail de définition des plans de réponse, mais ne parviennent pas à définir clairement quel serait le déclencheur du risque, comme manquer un jalon.
Aidez-les à travailler ce point.
Les déclencheurs peuvent être utilisés pour avertir que le risque est sur le point de se produire, ce qui donne au propriétaire du risque le temps de mettre en œuvre le plan de réponse à ce risque.
#7 – Sachez saisir les opportunités.
Parmi tous les risques potentiels se cachent aussi des opportunités très positives pour le projet.
Les risques comprennent aussi des événements ou des conditions positives, qui, s’ils se produisent, auront un impact positif sur les objectifs du projet.
Vous serez beaucoup plus efficace si vous parvenez à identifier ces événements positifs et ne ratez aucune chance d’en faire bénéficier votre projet et vos clients
#8 – Tenez à jour vos plans de management de projet.
Vous devez rester synchrone dans l’ensemble de vos plans de projets avec celui de management des risques.
Les plans de management de l’échéancier, des coûts, de la qualité, des approvisionnements, des recrutements et du périmètre. Au fur et à mesure que les propriétaires de risques élaborent des plans de management, vous devez en tant que manager de projet mettre à jour tous ces autres plans en conséquence.
Par exemple vous ajouterez si nécessaire de nouvelles activités au WBS et définirez plus en détail la façon dont les provisions pour éventualités seront utilisées.
#9 – Maintenez un journal des hypothèses.
Tenez votre journal des hypothèses à jour et visible de votre équipe et de votre sponsor.
Vous-même et les membres de l’équipe projet faites beaucoup d’hypothèses, en particulier dans les premières phases d’un projet en fonction des informations disponibles. Au fur et à mesure que l’équipe de projet découvre de nouvelles informations, les hypothèses déjà identifiées peuvent nécessiter une mise à jour ou vous pourriez devoir ajouter de nouvelles hypothèses. En gardant ces hypothèses visibles de tous, vous permettez à chacun d’intervenir et de les corriger ou enrichir si nécessaire.
#10 – Créez des contrats ou des accords avec les parties prenantes externes.
Certains propriétaires de risques peuvent souhaiter faire appel à un tiers pour répondre aux risques.
En tant que manager de projet, vous allez vous assurer que ces décisions et contrats soient documentés et approuvés si besoin.
Voyez-vous d’autres mesures à prendre pour mieux pour planifier la réponse aux risques ?
Envisagez d’utiliser cette liste comme une simple liste de contrôle et appliquez-la sur l’un de vos projets actuels pour la tester.
Votre management des risques doit rester aussi simple que possible et néanmoins vous garantir que les réponses sont faisables, économiquement viables et efficaces.
partagez ce billet avec vos amis, collègues et relations professionnelles
Vous avez certainement entendu parler de ChatGPT. Qu’est-ce ChatGPT ?
Il y a un buzz incroyable autour de cette intelligence artificielle avec laquelle on peut discuter et qui répond sur un style quasi humain. Les enthousiastes en font des tonnes. On prédit la fin du moteur de recherche de Google puisque ChatGPT répond à toutes vos questions, la fin des codeurs car ChatGTP crée du code sur demande dans le langage de votre choix, la fin des auteurs humains puisque Chat GPT rédige sur demande sur le sujet de votre choix… Christian Hohmann
Christian a eu l’idée de demander directement à ChatGPT ce qu’est ChatGPT !
Sa réponse écrite sera lue par un convertisseur vocal. Pourquoi tant d’engouement autour de ChatGPT ? Réponse dans cette courte vidéo !
La roue de croissance du coaching agile est un outil pour les coachs agiles, les scrum masters, les leaders et tous ceux qui souhaitent accroître leur capacité à aider et à développer les équipes et les organisations en utilisant les principes et les pratiques agiles.
La roue vous permet de réfléchir et de grandir dans votre cheminement agile.
Faites-vous aider d’un autre coach Agile pour progresser.
HBR n’avait jamais entendu parler de ce terme et ils appelèrent Mintzberg pour lui demander ce que signifie l’adhocratie.
Il corrigea son article pour que ce soit plus clair. Même si, à la relecture, avant de publier l’article, les relecteurs de HBR ne comprenaient toujours pas ce qu’était l’adhocratie… (H. Mintzberg,2004)
L’adhocratie, est une structure qui est basée sur des relations informelles.
Structure axée sur l’informel
Pensez aux entreprises agiles ou libérées. Ces entreprises innovent constamment, elles fonctionnent en mode projet.
Quand une équipe a terminé un projet, ses membres sont ré-alloués sur d’autres projets. À l’exception par exemple des tâches opérationnelles dans l’industrie comme c’est le cas dans certaines entreprises.
Mintzberg a défini deux sous-catégories de bureaucraties.
Structure axée sur le formel
Tout d’abord, la bureaucratie Mécaniste, c’est une entreprise où le personnel devra se référer rigoureusement aux procédures afin de mener une tâche. Imaginez une usine industrielle.
Enfin, la bureaucratie Professionnelle, où, il y aura un système de classement, pour évaluer le personnel. Pensez aux cabinets de conseil où chaque consultant est évalué sur l’atteinte de ses objectifs.
Comme le dit Max Weber, le père de l’organisation bureaucratique : c’est une entreprise axée sur le formel. Tout est hiérarchisé avec des rôles clairement définis.
Revenons au sujet de cet article, quelle posture doit adopter le chef de projet au sein de deux structures ?
Le Project Management Institute® (PMI) a pris conscience qu’un chef de projet doit adapter son comportement à la structure de l’entreprise. C’est la raison pour laquelle, le nouvel examen PMP® est, depuis 2021, axé sur des questions situationnelles et moins techniques.
Autrefois, on attendait principalement d’un chef de projet qu’il maîtrise l’aspect technique de la planification d’un projet. Il n’est pas rare, d’entendre que ceux qui ont passé le PMP avant 2021 avaient à réaliser des calculs sur les coûts et délais d’un projet. Aujourd’hui, ce n’est plus le cas. Le PMI, recherche des chefs de projet qui savent gérer les relations informelles avec les membres de leurs projets.
Dans une entreprise bureaucratique, on attend du chef de projet qu’il soit hautement compétent d’un point de vue technique. Autrefois, nous étions dans un paradigme qui considérait que si le chef de projet savait faire un GANTT, cela suffisait pour qu’il soit un bon chef de projet sans prendre en compte le côté management des parties prenantes.
Aujourd’hui, l’adhocratie semble se démocratiser. De nombreuses, entreprises qui fonctionnement toujours en mode bureaucratique ont compris qu’il fallait être plus souple sans forcément devenir une structure adhocratique. C’est pourquoi, le PMI a accentué le côté « leadership » lors de la certification PMP. En effet, PMI veut sensibiliser les (futurs) chefs de projets à prendre conscience que la réussite d’un projet passe par le pilotage des Hommes et ainsi aider les entreprises bureaucratiques ou adhocratiques à mieux réussir leurs projets. Comme le dit si bien PMI, le PMBoK® 7 est bien adapté pour les projets traditionnels, hybrides, aussi bien qu’Agiles.
Si vous pilotez un projet dans une entreprise bureaucratique vous serez fortement confronté aux cloisonnements des différentes entités et à la réticence aux changements. Car, ces entités n’ont pas l’habitude de communiquer ensemble. Il vous faudra vous armer de patience. La démarche du Lean Management semble très intéressante pour vous aider à piloter vos projets au sein de ces organisations.
Salle Obeya
Car, elle va vous permettre de mettre en place une salle Obeya, similaire à un Comité de Pilotage de Projet (COPIL) où les différentes parties prenantes rattachées à plusieurs entités, pourront travailler ensemble de manière visuelle avec un management collaboratif. Il est fort possible que votre entreprise n’ait pas de référentiel en gestion de projet. Si vous êtes certifié (PMP ou Prince2…), il vous faudra encore une fois, être patient et convaincre le sponsor de l’utilité du PMBoK ou autres référentiels.
Ce qu’il faut comprendre est que, si vous souhaitez mener à bien vos projets dans une bureaucratie, il vous faudra être un accompagnateur du changement en plus d’être un chef de projet. Faites preuve d’empathie et impliquez les parties prenantes vers le management participatif.
Livre sur Amazon
La démarche du Lean Management est efficace pour vous aider. Si le Lean vous est inconnu, n’hésitez pas à faire appel à un certifié Green/Black Belt Lean ou responsable amélioration continue de votre entreprise, il vous fournira des outils efficaces pour piloter vos projets.
Il ne faut pas oublier que l’entreprise automobile Toyota à l’origine du Lean est passé d’une bureaucratie inefficace à une bureaucratie habilitante ou excellente selon Isaac Getz, Liberté & Cie. et Jeffey Liker dans son ouvrage : Le modèle Toyota, 14 principes.
Si vous pilotez votre projet dans une adhocratie, le chef de projet est avant tout, un leader et coach.
Si vous êtes moins confronté à la réticence aux changements, il n’en demeure pas moins que vous devez savoir laisser vos parties prenantes prendre des décisions (contrairement à une bureaucratie où vous avez un pouvoir de décision assez élevé). Il est primordial que vous soyez sociable et connaissiez bien les démarches Agile ou Lean car elles sont souvent utilisées pour rester innovant.
Étant donné, que nous sommes dans l’informel, l’équipe projet collabore et travaille dans la même pièce. Toutefois, il faudra être précautionneux sur le fait de bien centraliser les données pour que l’équipe puisse avoir toutes les bonnes informations nécessaires au bon endroit. Cela nécessite, donc que vous appréciez travailler en équipe et gérer les conflits axés sur les relations. Comme il y a plus d’informel que de formel, il y a une plus grande probabilité que des conflits apparaissent. N’oubliez pas si vous avez travaillez depuis longtemps dans une structure traditionnelle et que vous devez maintenant travailler dans une adhocratie que la responsabilité de la planification revient à l’équipe projet.
CSP DOCENDI est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
Finalement, que vous pilotiez un projet dans une bureaucratie ou adhocratie, vous devez faire preuve d’empathie, écoute active et avoir le sens du relationnel.
Cela semble être du bon sens.
Mais, dans une bureaucratie, vous devrez :
Vous armer de patience
Être un facilitateur
Accompagner le changement vers le management participatif
Savoir utiliser les bons outils car vous avez tout de même un pouvoir conséquent.
A la différence, de l’adhocratie, où votre pouvoir est limité. Vous serez tel le Scrum Master qui est présent pour guider son équipe (mais sans la diriger), tout en sachant canaliser et centraliser les relations informelles.
Sources :
[1] Mintzberg H. (2004). Le management : Voyage au centre des organisations. Eyrolles, Paris. Page. 348.
“PMI,” the PMI logo, “PMP,” “PMBOK” and “Project Management Institute” are registered marks of Project Management Institute, Inc.
IOUALITENE Yanis est chef de projet Lean.
Yanis Ioualitene
Il est diplômé de Skema Business School en management de Projets & Programmes. Il est certifié PMP ®, Prince2, ITIL 4, PSM I, Agile PM DSDM et Green Belt Lean.
Yanis a contribué au groupe de travail sur le PMBoK 7 organisé par le PMI Francophone.
Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes
partagez ce billet avec vos amis, collègues et relations professionnelles
Si vous êtes consultant ou manager de projet et souhaitez que #ChatGPT vous aide à expliciter pourquoi votre activité est importante pour vos clients ou bien si vous avez tout simplement entendu parler de ChatGPT et souhaitez avoir un exemple concret, ce billet est fait pour vous.
En effet, ce #script réutilisable est fait pour vous !
En quelques heures, Lenda a entrainé l’outil à parler d’un de ses domaines d’expertise de plus en plus précisément.
Remarquons aussi que le résultat est multi-niveaux :
argumentaire commercial
parcours de formation pour les béotiens sur le sujet
script pour continuer la conversation sur d’autres thèmes de l’exemple (#agilité, #contrôle de gestion, #audit,…)
début de script pour assigner une compétence donnée à ChatGPT, et méthode pour y injecter de plus en plus de précision pour l’amener à donner un avis d’expert, à la condition essentielle d’en savoir un minimum sur le sujet.
Vous êtes curieux et désirez aller plus loin ?
Adhérez au groupe « ChatGPT pour les Nuls » sur LinkedIn, nous nous efforçons de mettre en commun nos réflexions et nos productions en langue française.
Si vous êtes intéressé par les nouvelles technologies de l’IA conversationnelle et que vous souhaitez partager vos cas d’usage et vos retours d’expérience avec chatGPT, ce groupe est fait pour vous !
Rejoignez-le pour échanger avec d’autres professionnels, découvrir de nouvelles possibilités et développer vos compétences avec chatGPT.
Lenda Aït Kaddour
Lenda Aït Kaddour est une consultante indépendante franco marocaine, experte en transformationdes organisations et en management de projets complexes.
Elle possède trois diplômes de niveau BAC+5, initialement en tant qu‘Ingénieur Agronome à Bordeaux Sciences Agro en 1997, complété en 2011 par un Master2 en Mathématiques appliquées à lagestion des risques à l’Institut d’Administration des Entreprises de l’Université Montpellier II, et renforcé en 2012 avec l’obtention du Mastère Spécialisé SILAT d’AgroParisTech Executive formant aux Systèmes d’Informations Géographiques.
Lenda a débuté sa carrière entre le Luxembourg et Paris, en tant que formatrice et consultante en bureautique et en gestion de projets. Au fil de ses missions, au sein d’organisations parfois multinationales aux métiers très divers (Télécommunication, Energie, Construction, Fonction publique, Coopération internationale, …) elle continue à développer ses compétences dans un esprit pluridisciplinaire, interculturel et amplement dédié à l’intelligence collective et à la construction des connaissances.
Actuellement établie au Maroc, elle intervient désormais majoritairement en accompagnement de décideurs dans les organisations souhaitant répondre à des enjeux stratégiques impliquant des transformations.
Avec l’apparition de ChatGPT, Lenda cherche à développer de nouvelles formes de conseilet d’intervention à l’aide de cet outil à la productivité remarquable.
partagez ce billet avec vos amis, collègues et relations professionnelles
The Standard for Program Management 5ème version va introduire de nouveaux principes autour du Leadership du management des risques et des changements.
Vous pouvez contribuer à cet effort en donnant vos commentaires au PMI® avant le 16 février.
La quatrième version est disponible en ligne en format PDF pour les membres du PMI
The Standard for Program Management est un document de valeur utilisé par de très nombreuses et nombreux managers de programmes dans le monde entier. Ajoutez-y votre propre expérience et vos réflexions.
“PMI,” the PMI logo and “Project Management Institute” are registered marks of Project Management Institute, Inc.
Pour rappel, voici ce que Mike Clayton nous propose comme introduction au Program Management.
In this Program Management 101, you’ll learn what Program Management is, what the main Program Management disciplines are, the Program lifecycle, and my top 7 Program Management principles.
Et j’avais précédemment publié ce billet sur l’ensemble des certification proposées par le PMI.
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
Nous tirons un énorme avantage de prendre un engagement simple :
Nous respectons les délais.
L’avantage est qu’une fois que nous avons convenu de la date limite, nous n’avons plus à nous en soucier. Nous n’avons pas à négocier, à trouver des excuses ni même à stresser à ce sujet.
Il ne sera pas livré quand il sera parfait.
Il sera livré quand nous avons dit qu’il le serait.
Une fois que ceci est clair, la qualité de ce que nous expédions augmente grandement. Au lieu de passer du temps et de l’énergie à chercher des raisons, des excuses ou à être dans le déni, nous faisons simplement le travail.
Et au fil du temps, nous estimons de mieux en mieux les délais sur lesquels nous engager. Parce que si nous promettons, nous livrons.
Selon moi, comme avec l’approche Agile, les délais et les moyens sont fixés au départ, la variable d’ajustement devient le contenu et surtout la priorisation de ce contenu en fonction de sa valeur business et de la capacité de l’équipe à livrer.
partagez ce billet avec vos amis, collègues et relations professionnelles
Le Project Management Body of Knowledge® (PMBoK7) parle de reconnaître, d’évaluer et de répondre aux interactions du système, ce qui signifie que les managers de projet doivent s’engager dans une réflexion systémique pour générer une performance positive du projet.
Voici quelques perspectives significatives sur la pensée systémique qui améliorent la performance du projet.
Le changement au niveau du business de l’entreprise est l’objectif (pas seulement l’achèvement du projet).
l’objectif business est souvent bien plus large que l’objectif du projet
Les organisations intelligentes clôturent les projets lorsqu’elles ont atteint les résultats business souhaités, et non pas lorsque les livrables du projet sont terminés. Dans un monde projets, l’intégration de l’analyse d’affaires (business analysis), du management de projet et du changement organisationnel sont au cœur de la pensée systémique.
Par exemple, un nouveau processus opérationnel ou une nouvelle description de produit devrait mener à un plan de production de livrables. Ce plan décrira la valeur commerciale souhaitée. Au fur et à mesure que les livrables sont produits, les parties prenantes ont besoin de conseils de mise en place du changement organisationnel pour s’assurer que les produits et les changements opérationnels génèrent cette valeur.
Bâtissez sur le passé.
Les livrables du projet peuvent être plus efficaces lorsqu’ils tirent parti de ce qui est déjà mis en place via d’autres projets. Les approches agiles le font bien et rapidement. Parce que les livrables sont déployés en sprints courts, le processus agile s’appuie constamment sur le passé en améliorant les fonctionnalités qui ne sont pas aussi efficaces qu’elles pourraient l’être et en développant les fonctionnalités qui ajoutent déjà de la valeur commerciale. Néanmoins, vous n’avez pas besoin d’agilité pour construire sur le passé.
Les projets classés dans des portefeuilles bien organisés représentent souvent des étapes vers un ensemble stratégique de changements. En cours de route, de nouvelles exigences et de nouveaux besoins de l’entreprise créent des obstacles ou des opportunités qui doivent être managés. Vous pouvez améliorer les performances du projet en comprenant les objectifs de chaque projet du portefeuille et la valeur qu’ils apportent à l’entreprise. Ensuite, vous pouvez déterminer comment intégrer des objectifs business nouvellement découverts dans une liste de projets.
Comprenez les « dominos ».
Le changement est une constante dans le monde des affaires. Les changements d’activité, les changements de personnel et les nouvelles exigences peuvent créer une cascade d’éléments à traiter.
Par exemple, un changement dans un projet de construction modifie la triple contrainte de contenu, de coût et de délais. Mais il peut également modifier les contrats des sous-traitants, les processus des fournisseurs, le financement et les exigences en matière d’inspection.
Comprendre les changements en cascade qui surviennent au cours d’un projet et les aborder de manière proactive est un moyen fondamental par lequel la pensée systémique stimule les performances du projet.
L’intégration est un processus HUMAIN.
L’intégration des produits est difficile car les produits ne s’assemblent pas toujours comme prévu. Cela peut entraîner des retards dans les projets et des budgets qui augmentent. Un exemple est la sonde vers Mars qui a été perdue en raison d’un simple échec d’intégration, lorsqu’un module utilisait des mesures impériales et un autre utilisait les mesures métriques. La meilleure approche systémique de l’intégration consiste à travailler sur les personnes, les compétences et l’intégration des équipes.
Vos intégrations de produits se dérouleront sans heurts lorsque vous vous assurerez que les compétences que vous déployez ont des relations interpersonnelles positives et font preuve de respect les unes envers les autres et la contribution que chacune peut apporter.
Ces relations augmentent l’efficacité de la communication et le sentiment d’un objectif commun. De meilleurs produits, avec moins d’éléments d’intégration manqués, sont le résultat lorsque les équipes travaillent plus efficacement ensemble.
CSP DOCENDI est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
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
Les gens font des choix quant à leurs préférences en matière de contrôle et de prise de responsabilité. Lorsque nous combinons ces choix, nous nous retrouvons avec une matrice assez simple.
En haut à droite se trouve une combinaison idéale. Quelqu’un avec le contrôle et l’autorité qui prend également la responsabilité quand les choses tournent mal. Cela crée une boucle de rétroaction utile, car ces personnes peuvent réellement faire quelque chose à propos des problèmes qu’elles ont causés.
En bas à droite se trouve une catastrophe en attente de se produire. C’est un mégalomane fragile, Robert Moses, un bâtisseur, qui a passé près d’un siècle à paver New York tout en négligeant le logement et autres questions de justice sociale, mais n’a jamais assumé la responsabilité des effets de son travail. Les personnes qui prennent le contrôle et évitent la responsabilité sont souvent facilement identifiables parce qu’elles passent beaucoup de temps à se plaindre.
Dans le coin supérieur gauche se trouve ceux qui s’en soucient vraiment. Ils apportent une énorme empathie à la situation et aident les gens à se sentir reconnus. Hélas, parce qu’ils n’ont pas de pouvoir (soit parce qu’on leur a refusé, soit parce qu’ils l’évitent), leur volonté de prendre leurs responsabilités est en quelque sorte creuse. C’est l’une des raisons pour lesquelles les travailleurs de première ligne qui doivent exercer un travail émotionnel et faire preuve d’empathie au travail s’épuisent si souvent.
Et enfin, dans la plupart des situations, la majorité des gens sont en bas à gauche. Le système nous pousse à être des rouages, à accepter ce qui est donné en échange d’être blanchis et de ne pas être tenus responsables de ce qui se passe ensuite.
Dans de nombreuses situations, nous avons la liberté de choisir. Nous pouvons choisir un quadrant ou nous pouvons choisir de ne pas participer. Et si nous sommes assez chanceux ou attentionnés, nous pouvons choisir pour qui voter, pour qui travailler et où nous allons.
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).
Les audits de projet peuvent être intimidants. Discutons de certaines mesures que vous pouvez prendre pour rendre ce processus plus fluide et sans stress !
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.
Discutons de certaines mesures que vous pouvez prendre pour rendre ce processus plus fluide et sans stress !
Avant l’audit
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.
Au cours de l’audit
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.
Après l’audit
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 ?
Qu’en est-il maintenant ? Êtes-vous mieux préparé pour votre prochain audit de projet ?
Ce dicton est particulièrement applicable dans le monde des projets que vous en soyez le manager de projet, le sponsor, le leader, un membre de l’équipe ou même une partie prenante plus éloignée.
En matière d’alignement de l’équipe projet, l’ambiguïté est votre ennemi.
Faites l’assomption qu’une personne ou un service va prendre en charge certaines tâches dont votre projet dépend parce que c’est dans sa description de poste ou la fonction attendue de ce service et cela risque fortement de vous conduire à une catastrophe majeure.
En plus de clarifier les rôles, la question du « Qui fait quoi ? » crée également une opportunité de clarifier les échéances et de confirmer leur faisabilité.
En tant que manager de projet, vous allez, pendant que l’équipe discute des mesures à prendre pour atteindre les objectifs ciblés, vous assurer que chaque action est bien assignée à une personne ou à une équipe spécifique et qu’une date limite précise et acceptée de cette personne/équipe est confirmée.
Capturez par écrit ces engagements et distribuez ceux-ci à l’équipe sous forme de compte rendu de réunion de travail.
Préciser avec tous « qui fait quoi » peut vous sembler une étape évidente et même inutile car toute l’équipe projet, en particulier en approche Agile, connait les objectifs et les compétences de chacun.
Mais, ne le faites pas et vous risquez fort d’attendre des semaines qu’une personne termine une tâche dont elle n’a aucune idée qu’elle était censée la faire !
Levez toutes les ambiguïtés liées à « Qui fera Quoi » et vous avez déjà fait un énorme pas vers la réussite !
Comme le dit David Burkus « Ambiguity is the ennemy of clarity ».
partagez ce billet avec vos amis, collègues et relations professionnelles
Le cas d’affaire est un document qui aide une organisation à décider d’approuver ou non le démarrage d’un projet. En règle générale, nous disons quele cas d’affaire justifie le projet parce qu’il doit indiquer clairement que les bénéfices de la réalisation du projet l’emportent sur le coût et les efforts, c’est-à-dire que le projet est la bonne chose à faire. En tant que tel, il s’agit de l’un des documents les plus importants du cycle de vie du projet. Un cas d’affaire médiocre ou manquant peut indiquer que le projet n’est pas justifié, c’est-à-dire qu’il n’a pas été correctement vérifié que c’est la bonne chose à faire pour l’organisation.
Partenaire de DantotsuPM, visitez le site pour toutes les formations certifiantes proposées
Que devrait inclure un cas d’affaire ?
Imaginez que vous ayez la tâche de prendre une décision concernant un investissement important en fonction du contenu d’un document. Que voudriez-VOUS que ce document contienne ?
Les sections qui sont typiquement utiles
Contexte – Une explication du problème ou de l’opportunité auxquels le projet répondra. Pourquoi ce cas d’affaire est-il même envisagé ? Quelles situations ou circonstances nous ont amenés à ce point ?
Avantages – Quels seront les résultats mesurables de la réalisation de ce projet ? En quoi et pourquoi ces avantages sont-ils bénéfiques pour l’organisation ? Peut-on établir un lien avec la stratégie ?
Budget – Vous n’aurez probablement pas de budget détaillé à ce stade, mais vous devrez donner une indication ou une estimation de haut niveau des coûts.
Risques – Dans quelle mesure le projet proposé est-il risqué ? Est-ce une « chose sûre » ou les chances d’échec sont-elles plus élevées ?
Évaluation des investissements – Une analyse des raisons pour lesquelles l’investissement est une bonne idée. Cela peut inclure à la fois des facteurs financiers et non financiers, et devrait essayer d’expliquer en termes tangibles et mesurables pourquoi le projet est une bonne idée.
Analyse des options – Évidemment, ce projet que vous proposez doit être votre moyen préféré de résoudre le problème ou de tirer profit de l’opportunité. Vous devez expliquer comment cette option est devenue votre préférée. Quelles autres options avez-vous envisagées ? Pourquoi celle-ci est-elle la meilleure ?
Qui devrait créer le cas d’affaire?
Dans de nombreuses instances, le cas d’affaire du projet est rédigée par le manager de projet. C’est une façon un peu renversée de faire les choses. Repensez-y … le cas d’affaire est rédigé pour justifier le projet.
Sans cas d’affaire, il ne devrait pas y avoir de projet. Alors, comment un manager de projet peut-il rédiger un cas d’affaire pour son propre projet ?
Le fait même qu’il y ait un manager de projet en place implique que la décision de faire le projet a déjà été prise.
Alors, qui devrait l’écrire ?
L’Association for Project Management (APM) est assez claire : c’est le sponsor. Le sponsor est le champion principal et actif du projet et en détient la responsabilité globale (en fait, la responsabilité s’arrête avec lui si c’est le mauvais projet ou si le projet est mal fait), donc naturellement il devrait lui incomber de justifier officiellement le projet.
En règle générale, les sponsors ne le rédigent pas eux-mêmes, mais confient plutôt cette tâche à quelqu’un. Cette personne peut très bien s’avérer être la personne qui deviendra plus tard le manager de projet. Quoi qu’il en soit, le cas d’affaire bénéficie de l’apport de plusieurs personnes :
Si un manager de projet et/ou une équipe projet ont été identifiés, ils apporteront une précieuse contribution .
Le client/utilisateur final
Le fournisseur
D’autres experts (selon le projet, ce peuvent être des avocats, des RH, du personnel technique, etc.)
Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes
Conseils clés
Ne confondez pas le cas d’affaire avec le plan de projet. Le cas d’affaire doit être préparé avant que le projet ne soit démarré et, à ce moment-là, il n’y a pas encore de définitions détaillées de la portée, d’échéancier et de budgets. Le contenu du cas d’affaire est indicatif.
Gardez-le vivant. Pour faire suite au point précédent : Lorsque vous commencez, vous en savez très peu et le contenu ne peut être que de haut niveau. Mais au fur et à mesure que vous progressez dans le projet, de plus en plus de détails seront découverts pour que le cas d’affaire puisse être mis à jour et approuvé à nouveau.
Faites simple. N’exagérez pas avec une mise rédaction compliquée ou une formulation sophistiquée. Un simple document Word très direct avec un vocabulaire simple est préférable. Ce n’est pas le moment d’embrouiller le public avec votre écriture créative.
Avez-vous des préoccupations au sujet d’un aspect du projet ? Documentez-les dans le cas d’affaire ! Si vous dissimulez des informations aux décideurs, c’est de votre faute si les choses tournent mal plus tard et qu’il s’avère que la mauvaise décision a été prise.
Et ensuite ?
Wellingtone peut vous aider à définir votre cas d’affaire et d’autres livrables de management de projet grâce à leurs services complets de conseils PMO.
partagez ce billet avec vos amis, collègues et relations professionnelles
Il est crucial pour les entreprises et l’IT de travailler en équipe pour atteindre l’objectif commun : Ajouter de la valeur à l’entreprise et à ses parties prenantes et clients.
Le but du management de portefeuille de projets est de déterminer quelles initiatives ajoutent le plus de valeur à l’entreprise et à ses clients. Il est important de tenir compte des délais dans lesquels les initiatives commenceront à ajouter de la valeur.
Il y a deux ans, avec l’équipe @DKR, j’ai fait une randonnée cycliste caritative de sept jours des Pays-Bas à l’Alpe d’Huez en France, appelée le Gran Fondo. L’une des clés du succès a été notre feuille de route. Cela nous a donné une direction, une structure et un focus. Nous avions un plan.
Ici, je constate un énorme parallèle avec le Management de Portefeuille de projets IT, IT Portfolio Management. Vous avez besoin d’un plan et d’une structure pour donner une direction au management de portefeuille afin de pouvoir déterminer quelles initiatives se qualifient le mieux pour ajouter de la valeur.
Exécution de la stratégie
Le management de portefeuille est un élément important du modèle d’exécution de la stratégie.
En cette ère numérique, de nombreuses entreprises sont inondées de demandes des clients pour de nouveaux produits et services. Il en résulte de nombreuses initiatives informatiques générées par le business.
Mais comment une organisation peut-elle rationaliser et sélectionner les initiatives qu’elle développera et lancera ?
C’est là qu’intervient l’Organisation de Management de Portefeuille ou PFMO. Son rôle est de prioriser les initiatives qui doivent mener à une proposition de feuille de route pour décision finale par le Comité Décisionnel du portefeuille, le board. Ce board est un organe de gouvernance mis en place et mandaté par la direction de l’organisation.
Priorisation des initiatives
Lorsque nous avons planifié le Gran Fondo, nous avons dû faire des choix. Sur la base de la condition physique de l’équipe, de combien de kilomètres et de dénivelé l’équipe pourrait-elle accomplir de manière réaliste en sept jours ? Les sept étapes ont dû être adaptées à cela en tenant compte également d’autres éléments, tels que les routes qui n’étaient pas ouvertes aux cyclistes et l’emplacement des hébergements.
Dans le management de portefeuille, les mêmes principes s’appliquent. Des choix doivent être faits et il est nécessaire d’établir des priorités.
Les critères typiques de priorisation des initiatives sont les suivants
Contribue-t-elle à la stratégie de l’organisation ?
Comment aide-t-elle à atteindre les objectifs que l’organisation s’est fixés et contribue-t-elle à l’atteinte des avantages escomptés ?
Les cadres juridiques auxquels l’organisation doit se conformer sont-ils en jeu ? Par exemple, les règles liées à la protection de la vie privée et à la sécurité.
Est-elle conforme à l’architecture technique de l’entreprise ?
Quand l’initiative pourra-t-elle commencer à ajouter de la valeur à l’entreprise et à ses clients ? Ceci en fonction de la durée, de l’échelonnement, de la taille, de la complexité et de l’impact sur les ressources.
Le produit/service envisagé est-il reproductible ? Peut-il être utilisé chez d’autres clients ?
Quelles sont les dépendances et l’impact sur les autres initiatives et le portefeuille actuel de produits et services ?
De toute évidence, le budget est un élément important à considérer. Mais d’après mon expérience, les initiatives sont généralement financées par le demandeur, l’entreprise; ni par l’organisation informatique ni par le PFMO. C’est pourquoi je ne considère pas que cela fasse partie des critères de priorisation. Dans certains cas, j’ai vu le service informatique se voir accorder un budget annuel fixe pour effectuer, par exemple, des travaux de développement. Ceci sur la base de la feuille de route élaborée par le PFMO. Mais ensuite, une nouvelle initiative a été priorisée qui ne figurait pas sur la feuille de route et qui nécessitait davantage de capacités de développement. Cela a conduit à un financement supplémentaire pour l’IT afin d’assurer une capacité de développement suffisante.
L’examen et la priorisation des initiatives IT nécessitent une analyse approfondie de la part de l’Organisation de Management de Portefeuille (PFMO). Le Product Owner a un rôle clé à jouer pour mener l’analyse approfondie et impliquer les architectes techniques d’entreprise soutenus par des spécialistes.
Critères de succès
L’un des plus grands défis que j’ai vus est l’adoption du management de portefeuille par l’entreprise et l’utilisation du PFMO. Le rôle du PFMO est de fournir une vision holistique de toutes les initiatives informatiques et d’assurer une priorisation correcte pour l’organisation. Mais ces priorités ne correspondent pas toujours aux attentes des différentes unités opérationnelles.
Ici, je vois un parallèle avec le Gran Fondo. Tous les coureurs de notre équipe n’avaient pas le même niveau de forme physique. Nous courrions le risque que les coureurs veuillent faire leur propre choix en termes d’itinéraire, de montées et d’étapes. C’est pourquoi nous avons créé la feuille de route, le roadbook, qui a canalisé l’équipe. Suivre le roadbook nous a donné la meilleure chance d’atteindre notre objectif et de passer la ligne d’arrivée ensemble en tant qu’équipe.
Pour donner une direction à votre organisation et éviter le risque que les unités commerciales ne sortent du cadre du PFMO, je recommande de construire une structure solide demanagement de portefeuille informatique qui soit formellement approuvée au niveau de la direction.
Cette structure devrait servir de ligne directrice à l’organisation sur comment et quand utiliser le PFMO. Elle devrait décrire la gouvernance de management du portefeuille, son mandat, les rôles et responsabilités et les routines de réunion.
Une vue de la gouvernance du portefeuille.
Un autre challenge est de savoir comment l’établissement des priorités, tel que réalisé par le PMFO, est traduit en une feuille de route. On s’attend souvent à ce que le comité de management du portefeuille, le board, établisse la feuille de route en fonction des priorités établies par le PMFO.
Avec l’afflux élevé de nouvelles initiatives numériques, le board n’est pas équipé pour élaborer une telle feuille de route. Souvent, les membres du comité font partie de l’équipe de direction. Ils n’ont tout simplement pas le temps ni la capacité et n’ont généralement pas les connaissances approfondies. Par conséquent, ma recommandation est de mettre en place un forum des propriétaires business et produits (portfolio forum of business and product owners) qui développe une feuille de route conceptuelle pour la prise de décision finale par le conseil d’administration. L’avantage est davantage de responsabilisation pour les équipes, plus de flexibilité et des propriétaires business et produits qui réfléchissent pour l’entreprise et pas seulement pour leur propre organisation.
Management des parties prenantes
Pour les unités commerciales, le délai de mise sur le marché et la rapidité de livraison de nouveaux produits/services aux clients sont d’une importance majeure.
Le risque est que les unités commerciales sortent du management de portefeuille si les exigences ne peuvent pas être remplies comme elles le souhaitent. Elles passeront probablement à côté de sujets importants tels que le respect des normes de l’entreprise (comme celles de confidentialité, techniques, standards de données) et génèreront de la duplication d’initiatives, ce qui signifie des investissements supplémentaires. Un bon exemple que j’ai rencontré était le développement d’une application de reconnaissance faciale qui n’était pas conforme aux normes de l’entreprise.
Comme indiqué précédemment, il est essentiel de rendre obligatoire pour l’entreprise de mener toutes les nouvelles initiatives par l’intermédiaire du PFMO.
Cependant, le PFMO doit se rendre compte que le management de portefeuille n’est pas l’activité principale des principaux contributeurs de l’entreprise. Surtout au début, il faut de gros efforts pour les embarquer dans le voyage du management de portefeuille et leur faire comprendre la valeur du management de portefeuille, le rôle qu’ils jouent, le mandat qu’ils ont et l’environnement dans lequel ils opèrent.
Par conséquent, passez du temps avec les parties prenantes de l’entreprise, non seulement par le biais de la gouvernance formelle, mais aussi par le biais de réunions individuelles. La communication est la clé.
Nous avons vécu la même chose dans notre Gran Fondo. Certains cyclistes ont mal interprété le roadbook, et nous nous sommes trompés de sortie. Cependant, en communiquant et en nous orientant collectivement dans la bonne direction, nous sommes revenus en piste et nous avons franchi la ligne d’arrivée ensemble.
Les points à retenir
Produisez un « roadbook», feuille de route, pour structurer l’orientation du management de portefeuille dans votre organisation.
Obtenez l’adhésion de la direction exécutive, car elle est essentielle pour vous assurer que toutes les nouvelles initiatives IT au sein de l’organisation passeront par l’organisation de management de portefeuille.
Établissez une structure de portefeuille pour fournir des directions sur la façon dont l’entreprise et le service informatique collaborent pour faire les bons choix pour l’organisation en termes d’initiatives à prioriser et à déployer.
Laissez l’organe de management de portefeuille déterminer quelles initiatives/projets contribuent le plus aux thèmes stratégiques de l’organisation et lesquels peuvent apporter le plus de valeur à l’organisation dans les plus brefs délais.
Embarquez les parties prenantes seniors sur le chemin du management de portefeuille.
Rappelez-vous, comme le Gran Fondo, il est crucial pour les entreprises et l’IT de travailler en équipe pour atteindre l’objectif commun : Ajouter de la valeur à l’entreprise et à ses parties prenantes et clients.
Qui est René Klunder van Gijen (avec lequel j’ai eu le privilège de travailler chez Orange) ?
René Klunder van Gijen
I’m an experienced Business Unit and Transformation Leader. I’m passionated about building high performance teams, help customers in their transformation and help them to achieve their business objectives.
I have a solid background in ICT and Telecoms. I’m used to operate at the cutting edge of business and ICT /Telecom and I have worked in both domestic and international B2B environments.
Building bridges between teams and departments is one of my key qualities.
partagez ce billet avec vos amis, collègues et relations professionnelles
DantotsuPM.com 