3 articles très différents vous ont attiré en Novembre. Alors, prenez confiance en vous, ne copiez pas « bêtement » quelqu’un d’autre et facilitez l’enracinement des changements qu’apporte votre projet.
La confiance arrive souvent avant le succès. Vous pourriez même dire que le succès est dû à la confiance.
Vous ne pouvez pas copier-coller l’approche de quelqu’un d’autre en matière d’agilité. Leur approche s’est développée à partir de leur peuple et de leur culture. Zoom sur Spotify.
Manager sa charge de travail, ses compétences relationnelles (soft skills), ou encore savoir gérer les agendas cachés des uns et des autres… Pas si facile !
Êtes-vous un manager de projet surchargé ?
Si vous ne l’êtes pas déjà, ces signaux d’alerte devraient vous être utiles. Et si vous l’êtes déjà que faire ?
Les non-intuitifs et de nombreux professionnels techniques me disent que maîtriser les aspects pas si évidents des compétences relationnelles (c’est-à-dire les soft skills ou compétences interpersonnelles) représente pour eux un grand défi et même un véritable casse-tête.
Y-a-t-il une liste des vérités sur les compétences relationnelles à apprendre et à utiliser ?
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
Dans le domaine des projets, la méthodologie de gestion de projet, la gestion des parties prenantes et la planification occupent une place cruciale, et elles ont un impact très significatif sur le résultat final du projet, qu’il soit couronné de succès ou qu’il échoue.
Curiosité, Chef d’orchestre et maturité digitale : Des sujets très différents et pourtant tous intimement lié à votre réussite en tant que manager de projet.
Lefebvre Dalloz Compétences est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
Vous n’avez pas besoin d’être intelligent pour être curieux, mais poser des questions vous rend intelligent(e) !
3 billets très différents et complémentaires sur mieux manager le changement, mieux communiquer avec son sponsor et garder son projet sous contrôle.
Lorsque vous essayez de mettre en œuvre le changement au travail, vous pouvez ressentir que ceux qui ont un état d’esprit figé bloquent vos progrès. Comment manager ceci ?
De nombreux managers de projet travaillent dur pour établir un échéancier précis, puis omettent la dernière étape de la sauvegarde d’une base de références !
ChatGPT n’est pas juste un outil, c’est un collaborateur qui peut métamorphoser votre gestion de projet.
Êtes-vous prêt à débloquer les possibilités illimitées qu’offre l’IA ?
Un guide enrichi, peaufiné, et prêt à transformer votre approche de la gestion de projet, quel que soit votre niveau d’expérience.
Suite à son intervention au PMI Côte d’Ivoire Chapter, Anne-Emmanuelle a été inspirée et a décidé de se plonger entièrement dans la création d’une ressource exhaustive pour les gestionnaires de projet désireux d’exploiter pleinement ChatGPT.
Le résultat est là elle est donc extrêmement fière de vous le présenter.
𝐂𝐡𝐚𝐭𝐆𝐏𝐓 𝐩𝐨𝐮𝐫 𝐥𝐞𝐬 𝐠𝐞𝐬𝐭𝐢𝐨𝐧𝐧𝐚𝐢𝐫𝐞𝐬 𝐝𝐞 𝐩𝐫𝐨𝐣𝐞𝐭
Ce guide dépasse le cadre d’une simple introduction à ChatGPT. C’est un véritable passeport pour une gestion de projet plus astucieuse et efficace grâce à l’IA.
Le contenu à haut niveau
Des 𝐞𝐱𝐩𝐥𝐢𝐜𝐚𝐭𝐢𝐨𝐧𝐬 𝐝𝐞́𝐭𝐚𝐢𝐥𝐥𝐞́𝐞𝐬 sur ChatGPT et comment il révolutionne la gestion de projet.
Plus de 𝟒𝟎 𝐩𝐫𝐨𝐦𝐩𝐭𝐬 𝐩𝐞𝐫𝐬𝐨𝐧𝐧𝐚𝐥𝐢𝐬𝐞́𝐬 pour simplifier et optimiser vos tâches quotidiennes.
4 𝐞́𝐭𝐮𝐝𝐞𝐬 𝐝𝐞 𝐜𝐚𝐬 illustrant l’impact réel de ChatGPT dans des situations concrètes.
Une « 𝐜𝐡𝐞𝐚𝐭𝐬𝐡𝐞𝐞𝐭 » pour une mise en pratique immédiate et efficace.
Une section 𝐅𝐀𝐐 𝐞𝐭 𝐫𝐞́𝐬𝐨𝐥𝐮𝐭𝐢𝐨𝐧 𝐝𝐞 𝐩𝐫𝐨𝐛𝐥𝐞̀𝐦𝐞𝐬 pour surmonter aisément les obstacles courants.
Que vous soyez un expert aguerri ou un débutant dans le domaine, ce guide est une ressource inestimable, regorgeant d’informations et de stratégies pour maximiser l’utilisation de l’IA dans vos projets.
𝐋𝐞 𝐠𝐮𝐢𝐝𝐞 𝐞𝐬𝐭 𝐠𝐫𝐚𝐭𝐮𝐢𝐭 et 𝐯𝐨𝐢𝐜𝐢 𝐜𝐨𝐦𝐦𝐞𝐧𝐭 𝐯𝐨𝐮𝐬 𝐩𝐨𝐮𝐯𝐞𝐳 𝐫𝐞𝐦𝐞𝐫𝐜𝐢𝐞𝐫 Anne-Emmanuelle de ses efforts et son travail.
1. Partagez ce billet pour aider d’autres managers de projet.
2. Lisez le guide et fournissez vos commentaires pour l’améliorer.
3. Contactez directement Anne-Emmanuelle pour une formation personnalisée pour vous et votre équipe.
Consultante en transformation digitale. Anne Emmanuelle est un(e) véritable couteau suisse digital, engagée pour la transformation numérique des entreprises africaines.
Média et développement au conseil d’administration de Sayaspora Média Inc.
Le scepticisme est une vertu. Il faut être prêt à remettre en question la sagesse conventionnelle et avoir le courage d’accepter quelque chose après avoir découvert que c’est vrai.
Le déni, en revanche, est un rejet volontaire de la réalité. C’est sûr, facile et improductif. Parce qu’il n’y a pas de place pour changer d’avis.
Pour être un sceptique généreux, vous devez indiquer à l’avance précisément ce qu’il faudrait pour que vous vous engagiez dans l’idée proposée, puis le faire une fois que vos normes sont remplies.
C’est un travail difficile. Il n’est pas facile de changer d’avis. C’est difficile mais ça vaut le coup. Les grands changements de perception sont rares et ce n’est pas quelque chose que vous attendez avec impatience.
Les sceptiques sont la clé de la méthode scientifique, de la conception organisationnelle et même de l’investissement. Vous vous engagez à douter, à remettre en question et à pousser, puis vous devenez un contributeur productif en adoptant les nouveaux outils et résultats.
Souvent, les gens dans le déni font semblant d’être des sceptiques. Cela semble mieux que de reconnaître que vous évitez simplement le changement.
partagez ce billet avec vos amis, collègues et relations professionnelles
Les écureuils se réveillent en pensant aux noisettes. Si vous aimez sauter d’une chose à l’autre, dépassez la distraction. Choisissez 5 règles simples pour votre journée.
Vous devenez fou quand la poursuite de la prochaine noisette domine votre esprit.
5 règles simples pour votre journée
#1. N’interrompez pas.
L’écoute est un travail difficile pour vous, mais cela est ressenti comme du respect par les autres.
De nombreuses difficultés de leadership disparaissent lorsque les gens se sentent entendus. Chaque fois que vous interrompez quelqu’un, vous rendez votre leadership plus difficile.
#2. Ne terminez pas les phrases des autres.
Les gens brillants ont besoin de patience pour écouter. Vous savez ce que quelqu’un va dire avant qu’il ne le dise. Ou du moins, c’est ce que vous pensez.
Vous n’avez pas l’air intelligent lorsque vous terminez les phrases de quelqu’un. En fait, vous semblez non intéressé et impatient.
Bas du formulaire
#3. Posez une question avant de parler.
Changez la raison pour laquelle vous écoutez. La plupart écoutent pour répondre. Écoutez pour poser une question qui fait avancer la conversation.
Votre curiosité prouve que vous vous intéressez aux gens. Lorsque vous vous intéressez aux autres, vous devenez intéressant pour les autres.
Écouter pour poser une question vous oblige à faire attention.
La curiosité est une plate-forme pour des réponses fortes.
#4. Confirmez que vous avez bien compris en résumant et en rephrasant.
Faites des choses qui aident les gens à se sentir entendus. Quand les gens se sentent écoutés, ils se sentent…
Respectés.
Compris.
Supportés.
Motivés.
Les gens se sentent bien dans leur peau ET avec vous-même lorsque vous leur prêtez toute votre attention. Vous semblez intelligent quand les gens ont l’impression que vous les entendez.
#5. Souriez, respirez et remarquez la personne qui se tient devant vous.
Les émotions sont contagieuses. Lorsque vous vous détendez, les gens autour de vous ont tendance à se détendre.
Lefebvre Dalloz Compétences est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
Conseil aux introvertis : Vous avez l’air beaucoup trop sérieux quand vous réfléchissez. Essayez de vous relaxer un peu. Peut-être un sourire de temps en temps. Hochez la tête. Haussez les sourcils.
Attention tout de même : Un auditeur trop détendu semble peu intéressé et trop confiant.
Quelles sont parmi ces règles simples celles qui vous semblent les plus importantes ?
Quelles autres règles simples pourriez-vous ajouter ?
partagez ce billet avec vos amis, collègues et relations professionnelles
Voici ce que vous pouvez faire – AUJOURD’HUI pour faire de votre projet un lieu de travail positif (et attrayant). Et cela vous aide à faire de votre projet un succès.
Recevez les nouvelles, bonnes et mauvaises, avec une attitude constructive.
Manager un projet, c’est comprendre l’actualité : l’achèvement des tâches, les retards, les conversations avec les parties prenantes, les nouvelles idées et les conflits. Pour comprendre la nouvelle, il faut en entendre parler. Et cela ne se produit que si vous soutenez vos équipes. Faites en sorte qu’il soit difficile ou désagréable pour les membres de l’équipe de partager des nouvelles avec vous (pensez à l’expression « tuer le messager ») et vous ne saurez pas ce qui se passe sur votre projet. Remerciez les personnes qui partagent des informations, qu’elles soient bonnes ou mauvaises. De cette façon, vous pouvez répondre de manière proactive aux problèmes du projet, au lieu de réagir à la bombe (de vérité) qu’une partie prenante clé lâche dans votre bureau parce que votre équipe n’a pas partagé le problème avec vous.
Constituez une équipe.
Oui, même pour un projet de courte durée. Trouvez un nom d’équipe, pas le nom business du projet. (Personne ne veut travailler sur le projet de gestion de la production et de l’efficacité du Velcro fusionné… mais ils apprécieront peut-être de faire partie de l’équipe « Better Rip and Stick » !)
Agissez comme si VOUS faisiez partie de l’équipe (parce que vous en êtes) et encouragez le travail d’équipe pour accomplir les tâches. Partagez la responsabilité. Célébrez les petites victoires. Vous aurez des membres de l’équipe dévoués qui voudront travailler avec vous… aujourd’hui et à l’avenir.
Assurez-vous que les membres de l’équipe comprennent la pertinence business de leurs tâches.
Les membres de l’équipe seront plus engagés lorsqu’ils sauront comment leurs livrables s’intègrent dans la vue d’ensemble. Le travail devient plus significatif et plus satisfaisant pour eux ! Parler de l’objectif des tâches peut également réduire les erreurs. Les membres de l’équipe soulèveront plus facilement les problèmes potentiels lorsqu’ils comprendront le contexte de leur travail. Vous obtiendrez de meilleurs livrables et plus de dévouement de la part de votre équipe.
Aidez les membres de l’équipe à se sentir à leur place.
Une équipe diversifiée, c’est bien, mais ce n’est que la première étape. Impliquez tous les membres de votre équipe dans la prise de décision et la planification de votre projet. Dépassez cela, prenez le temps de comprendre qui ils sont, quels sont leurs objectifs et quelles expériences de projet seront les plus significatives pour eux. Aidez-les à atteindre ces objectifs dans la mesure du possible.
Quels conseils avez-vous pour créer un environnement de projet positif ? Quels bénéfices avez-vous obtenus en offrant aux membres de l’équipe un environnement de travail positif ?
Bonjour, j’ai trouvé ce billet de Nicolas très intéressant même s’il ne correspond à aucune de mes expériences professionnelles. Dans mon parcours professionnel, le directeur (ou la directrice) de projet était en fait soit manager d’un très gros projet, soit manager de programme composé de plusieurs projets connectés et de chefs de projets pour chacun.
« A l’heure où l’interprétation de certaines méthodologies pourrait laisser penser au déclin des Chefs de Projet, qu’en est-il de celui de Directeur de Projet ? Comment son interaction avec le Chef de Projet revêt il en fait un caractère essentiel dans les dispositifs projet, et surtout dans l’atteinte de la satisfaction des parties-prenantes ?
Lorsqu’il est habilement établi, ce dispositif de binôme apporte une valeur essentielle aux objectifs des organisations grâce notamment à des responsabilités réparties entre visions stratégiques et tactiques :
Le « Directeur de Projet », en incarnant l’alignement stratégique, la communication exécutive, l’aide à l’élimination des obstacles, à la formation, ainsi que l’évaluation des performances,
Le « Chef de projet », en se consacrant davantage sur la gestion opérationnelle, l’exécution des tâches, la gestion des équipes ainsi que la réalisation des livrables spécifiques des projets »
Les piliers essentiels de la contribution de la Direction de Projet :
L’alignement Stratégique
Les Ressources et le Budget
La Communication « Exécutive »
La Gestion des Risques
L’élimination des Obstacles
La Formation et le Développement
L’évaluation des performances
Nicolas GOBILLON
Savoyard, certifié PMP® depuis 2011
Directeur de Projet informatique, je guide et forme activement depuis plusieurs années des équipes de chefs de projet dans la planification, l’exécution, et le suivi de projets informatiques d’envergure.
Responsable Opérationnel pendant 6 ans Chez Atos Origin après un DESS de Génie Informatique obtenu à Grenoble en 1997, j’ai construit mon parcours professionnel autour de la conviction que la dérive projet n’est pas une fatalité.
Au sein des Groupes Altran et Devoteam, mes postes successifs de Facilitateur Assurance Qualité, de Project Manager, de Senior Project Manager puis Project Director m’ont permis pendant 18 ans d’appréhender progressivement un spectre large de problématiques liées au pilotage de projets.
Convaincu que la collaboration et le partage de la connaissance avec mes pairs est une clé essentielle de la réussite, j’ai également animé avec passion en parallèle pendant près de 10 ans des formations dans ce domaine.
partagez ce billet avec vos amis, collègues et relations professionnelles
Le cycle en V, ce n’est pas de la gestion de projet, mais de l’ingénierie système.
Parler d’hybride, agile ou cycle en V, ce n’est pas de la gestion de projet.
Imaginer que le périmètre est figé en cycle en V est irréaliste.
Ce serait bien de rappeler ces fondamentaux pour éviter des erreurs de mise en œuvre ensuite.
De très juste remarques… d’où ce billet écrit conjointement avec Jean-Charles !
Le cycle en V est un modèle de cycle de développement d’un système qui se caractérise par un flux d’activités descendant qui détaille le système jusqu’à sa réalisation, et un flux ascendant, qui assemble le système en vérifiant sa qualité.
Cette approche associe chaque activité de définition ou conception à une activité d’intégration, vérification ou validation.
Comme indiqué par Jean-Charles, le cycle en V bien que souvent considéré comme du management de projet, est en fait de l’ingénierie système, et les 2 sont nécessaires et complémentaires !
Le cycle en V (ingénierie) se concentre sur le développement du système, c’est-à-dire et pour simplifier le livrable technique du projet, alors que le management de projet va se concentrer plus largement sur toutes les activités menant à la réalisation des bénéfices attendus par les utilisateurs, clients, et autres parties prenantes : pilotage financier, volet logistique, pilotage des fournisseurs, formation des utilisateurs ou exploitants, conduite du changement, maîtrise des risques et opportunités, …
Le cycle en V n’est donc pas une méthode management de projet.
Les grandes étapes du cycle en V
La branche descendante
Vous y détaillez le produit jusqu’à sa réalisation. Expression des besoins, analyse, conception, développement des livrables (matériels, logiciels, processus opérationnels…).
Le cycle en V requiert dans la branche descendante de réaliser une conception générale du système dans son ensemble, puis une conception détaillée de chaque composant.
Le développement se fait ensuite composant par composant.
La branche ascendante
Vous y avez pour objectif de valider le produit jusqu’à son acceptation par les clients. Il comprend principalement une série de tests unitaires, d’intégration puis de bout en bout jusqu’à pouvoir vérifier que le produit répond bien aux exigences.
Dans la branche ascendante, on va effectuer des tests unitaires de chaque composant, les intégrer dans le système (assembler ces composants), puis réaliser un test d’intégration.
Vérification et la validation confirment non seulement que le système répond à la conception, mais qu’il répond aux exigences des clients.
Limites et Risques principaux avec le cycle en V
#1 – Approche assez théorique
Le Cycle en V propose en réalité une approche assez théorique qui ne s’applique qu’à un système relativement simple, réalisé en un exemplaire, et pas au développement d’un système complexe à multiples niveaux de décompositions.
#2 – Représentation parfois trompeuse
Si le cycle en V représente un cycle de vie, les éléments le composant sont bien des activités et non des phases.
Appliquer cette représentation stricto sensu sans apporter de nuance conduit aux risques récurrents présentés ci-après.
#3 – Différence entre la théorie (les spécifications) et la pratique (ce qui a été produit).
Cette représentation induit le risque important de se rendre compte au cours de la mise en œuvre finale que les spécifications initiales étaient incomplètes, fausses, voire irréalisables. De fait, les processus se chevauchent et peuvent s’étendre sur plusieurs phases du projet.
#4 – Évolution des besoins
Comme le déroulement du cycle en V peut être assez long (plusieurs mois au minimum), vous avez de fortes chances pour que de nouveaux besoins requis par les clients et peut-être plus importants ou critiques au business que ceux en cours de développement apparaissent. Hors l’approche vous incite à figer le plus possible un jeu d’exigences au départ afin d’y répondre avec un livrable complet avant de considérer de nouveaux besoins.
#5 – Démobilisation et turnover
Plus le cycle en V dure longtemps et plus grands seront les risques de démobilisation de vos clients (et équipes de développement). L’effet ‘tunnel’ du cycle en V (on ne voit la lumière / le résultat qu’à la sortie du cycle en V) ne favorise pas la visibilité par les clients des réelles avancées sur votre projet lors de revues intermédiaires comme ce serait le cas avec une approche Agile.
Quels remèdes ?
Afin de pallier ces travers, l’Association Française de l’Ingénierie Système préconise une approche par les processus.
Sur vos projets, à défaut d’utiliser les approches itératives dites Agiles, un compromis pour vous consiste à appliquer un cycle en V le plus court possible et à faire évoluer vos livrables sous forme de versions. Vous prenez ainsi en compte le fait que le livrable ne sera pas parfait au départ et que vous l’améliorerez au fil des versions.
En vous rapprochant ainsi des Sprints et Releases des approches Agiles, votre cycle en V court vous permet de montrer plus rapidement des livrables concrets et utilisables aux clients.
Vous pourrez aussi à la fin de chaque version bénéficier du retour d’expérience de la ou des versions précédentes.
Sources et références :
Découvrir et comprendre l’ingénierie système, Ouvrage collectif AFIS, 2009
NASA systems engineering handbook, National Aeronautics and Sapce Administration, 2007
System Engineering Guidebook, INCOSE, 2018
System Engineering Hanbook, INCOSE, 2015
partagez ce billet avec vos amis, collègues et relations professionnelles
Le stress vous rend stupide et il vous rend intelligent. Il affûte votre concentration avant une réunion du conseil d’administration et met fin à votre bon raisonnement lorsque le patron est en face de vous.
Le stress est sain et il vous rend malade, c’est une question de degré.
« Le stress nous aide à rester motivés, à atteindre nos objectifs et à nous sentir bien dans la vie. » Dr. Michael Genovese
Le stress dit que vous vous souciez de quelque chose. Les mains moites avant votre évaluation des performances indiquent que vous vous souciez des performances, des promotions et de l’augmentation de salaire.
La pression que vous vous mettez sur vous-même provoque un stress auto-infligé. Parfois, ce n’est pas nécessaire.
Lefebvre Dalloz Compétences est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
5 questions pour réduire le stress auto-infligé
Un employé déverse un problème sur votre bureau et vous vous mettez la pression pour le résoudre. Posez des questions avant de vous précipiter pour le résoudre.
#1. Depuis combien de temps cela dure-t-il ?
Détendez-vous si cela dure depuis des années.
N’ajoutez pas de pression de temps imaginaire aux conversations de résolution de problèmes.
Réduisez le stress auto-infligé en disant : « Eh bien, cela dure depuis longtemps. Nous n’allons probablement pas régler ce problème rapidement. »
#2. Comment avez-vous essayé de résoudre ce problème ?
Apprenez aux gens à trouver des solutions. Vous n’êtes pas la fée de la résolution de problèmes.
S’ils n’ont rien fait pour résoudre leur problème, ils doivent reconnaître qu’ils veulent que vous le résolviez pour eux.
#3. Comment puis-je vous aider à résoudre ce problème ?
Soyez un supporter, pas un sauveur sur un cheval blanc.
Le stress auto-infligé écrase les « leaders-sauveurs ».
#4. Si les choses se passaient parfaitement, à quoi cela ressemblerait-il ?
Mettez-vous d’accord sur une image de ce qui serait mieux avant de vous mettre la pression pour résoudre les problèmes.
#5. Que pourrions-nous faire aujourd’hui pour améliorer cette situation ?
Surveillez vos pronoms. Si vous avez l’intention de vous impliquer, utilisez « nous ». Si c’est votre problème, utilisez « je ». S’il s’agit de leur problème, utilisez « vous ».
Déplacez les conversations de résolution de problèmes depuis les paroles vers les comportements.
Laquelle des questions ci-dessus pourriez-vous utiliser dès aujourd’hui ?
Quelles autres questions pourraient réduire le stress auto-infligé lorsque vous êtes confronté à des plaintes ou à des problèmes ?
partagez ce billet avec vos amis, collègues et relations professionnelles
Les projets CRM sont complexes et nécessitent un Product Owner dédié et compétent pour assurer leur succès. Un Product Owner est chargé de combler le fossé entre les besoins de l’entreprise et les équipes de développement, tout en optimisant le système pour réussir.
Laissez-moi vous parler des avantages à avoir un Product Owner sur un projet CRM.
Comprendre les besoins et les exigences de l’entreprise
Le Product Owner travaille en étroite collaboration avec les utilisateurs et les parties prenantes pour comprendre leurs besoins et leurs exigences. En cartographiant les processus métier et les parcours des utilisateurs, le Product Owner comprend mieux comment le CRM peut être adapté pour répondre aux besoins spécifiques de l’entreprise. Cela permet de s’assurer que le système est conçu et construit de manière à s’aligner sur les processus métier et les besoins des utilisateurs, tout en offrant une réelle valeur ajoutée.
Guider le processus de développement
Une fois les processus métier définis, le product owner collabore avec l’équipe de développement pour concevoir et mettre en œuvre la solution CRM. Cela implique de définir les histoires et les exigences des utilisateurs, de hiérarchiser les fonctionnalités en fonction de la valeur business et de travailler en étroite collaboration avec l’équipe de développement pour s’assurer que le système est conçu et construit d’une manière qui s’aligne sur les processus métier et les besoins des utilisateurs. Tout au long du processus de développement, le Product Owner fournit des conseils et des commentaires pour s’assurer que le système répond aux exigences qui ont été définies avec les utilisateurs et les parties prenantes.
Trouver l’équilibre entre les besoins de l’entreprise et la convivialité
Trouver le bon équilibre entre les besoins des uns et des autres.
L’un des rôles les plus importants du Product Owner est d’équilibrer les besoins de l’entreprise avec les besoins des utilisateurs. Bien que le Product Owner soit chargé de s’assurer que le système répond aux besoins de l’entreprise et apporte une réelle valeur ajoutée, il donne également la priorité à la facilité d’utilisation pour s’assurer que le système est intuitif et facile à utiliser pour les utilisateurs.
Cet équilibre entre les besoins de l’entreprise et la facilité d’utilisation peut parfois être un défi.
Par exemple, une entreprise peut exiger que certaines données soient saisies dans un certain format à des fins de reporting, tandis que les utilisateurs peuvent trouver ce format fastidieux et long à utiliser. Le product owner doit travailler à la fois avec l’entreprise et les utilisateurs pour trouver une solution qui réponde aux besoins de chacun. Il peut s’agir de trouver un compromis satisfaisant pour les deux parties, ou de trouver une solution de contournement qui répond aux exigences de l’entreprise tout en facilitant la saisie des données par les utilisateurs.
Communiquer avec les parties prenantes
En plus de travailler avec l’équipe de développement, le Product Owner communique régulièrement avec les parties prenantes de l’entreprise. Il s’agit notamment de fournir des mises à jour sur l’état d’avancement du projet, de solliciter des commentaires sur les conceptions et les fonctionnalités, et de s’assurer que le système répond aux besoins de toutes les parties prenantes. Cela permet de s’assurer que toutes les personnes impliquées dans le projet sont tenues au courant et ont leur mot à dire dans le processus de développement.
Assurer le succès du lancement et de l’adoption
Enfin, le Product Owner est responsable de s’assurer que le CRM est lancé et adopté avec succès par l’entreprise. Il s’agit de contribuer à des activités de formation et de soutien aux utilisateurs afin de s’assurer qu’ils sont à l’aise avec le nouveau système et qu’ils sont en mesure de tirer pleinement parti de ses capacités. En optimisant le système pour qu’il réussisse et en comblant le fossé entre les besoins de l’entreprise et le développement, le propriétaire du produit peut assurer le succès du projet CRM.
En conclusion, avoir un Product Owner sur un projet CRM offre de nombreux avantages.
Le Product Owner apporte la plus grande valeur possible, aussi rapidement que possible.
Un Product Owner s’assure que le système répond aux besoins de l’entreprise et apporte une réelle valeur, fournit des conseils et des commentaires tout au long du processus de développement, équilibre les besoins de l’entreprise avec les besoins des utilisateurs, communique régulièrement avec les parties prenantes et veille à ce que le système soit lancé et adopté avec succès par l’entreprise.
Si vous vous lancez dans un projet CRM, il est essentiel d’investir dans un Product Owner solide et expérimenté pour en assurer le succès.
Mohamed Michael Kazak
Mohamed Michael Kazak
Mohamed Michael Kazak dispose de plus d’une décennie d’expérience à travers diverses industries et plusieurs pays, avec un riche parcours en transformation technologique, gestion de projet, et excellence commerciale. Actuellement, Mohamed Michael occupe le poste de Salesforce Service Product Owner chez Imerys SA, où il dirige les initiatives liées à la digitalisation des activités Service Client Salesforce. Il a lancé plusieurs produits Service Cloud réussis qui ont nettement amélioré l’efficacité du service client et la satisfaction client. Ayant travaillé pour des organisations telles qu’EY et Deloitte, il a géré des équipes diverses et dirigé des projets de transformation avec un focus sur la création de valeur et la satisfaction des besoins des utilisateurs. En tant qu’Administrateur Certifié Salesforce, Mohamed Michael apporte une compréhension approfondie de la manière dont la technologie apporte des résultats commerciaux optimaux.
Le PMBOK® est et restera la référence la plus largement reconnue par les professionnels du projet dans le monde entier.
Il fournit des conseils utiles pour la plupart des projets dans la plupart des cas. Et il est certainement une lecture incontournable pour tous ceux qui dirigent un projet.
Voici donc une fantastique opportunité de contribuer au métier de management de projet si vous êtes un expert reconnu : Participez à la réalisation de PMBOK 8.
PMI a lancé l’élaboration du Guide PMBOK® – Huitième édition.
Le PMBOK V7 est disponible gratuitement en version électronique pour les membres du PMI ainsi que payant en version papier
S’appuyant sur la septième édition fondée sur des principes, une étude approfondie a été réalisée pour comprendre les meilleures pratiques dans le domaine.
Elle a aussi mis en évidence le contenu requis pour répondre aux besoins en constante évolution de notre communauté du management de projet comme l’impact de l’IA, des conseils d’experts sur les approches de travail agiles et prédictives, et davantage de contenu de soutien dans la pratique.
La daily scrum est censée être une réunion de synchronisation d’équipe rapide et factuelle. Elle peut rapidement se transformer en cauchemars récurrents si les gens parlent trop ou trop peu. En tant que Scrum Masters, notre travail consiste à faciliter ces réunions quotidiennes afin qu’elles atteignent leur objectif et restent dans leur zone de temps.
Deux vidéos suivent. Et vous devrez peut-être regarder les deux, en fonction de votre équipe !
La première vidéo présente quatre choses que vous pouvez essayer pour faire bouger la réunion lorsque quelqu’un domine la conversation. La deuxième vidéo traite des choses à essayer lorsque certaines personnes donnent des réponses vagues (ou ne parlent pas du tout !). Si vous préférez lire, une transcription suit chaque vidéo.
Les deux vous aideront à éviter deux monstres des daily scrum : Les vampires qui sucent le temps et les zombies qui tuent l’énergie.
4 choses à essayer lorsque les gens parlent trop dans les mêlées quotidiennes
Certaines personnes ne veulent tout simplement pas se taire. Peut-être qu’elles sont nerveuses à propos de quelque chose, alors elles parlent. Peut-être pensent-elles que tout le monde veut entendre chacune de leurs pensées. Peut-être elles ne sont même pas conscientes qu’elles parlent autant. Mais trop parler peut être un énorme problème, surtout dans une réunion avec une limite de temps courte comme le daily scrum. Voyons ce que vous pouvez faire à ce sujet.
1. Mettez une minuterie
Une solution courante pour un membre de l’équipe trop bavard consiste à lancer un chronomètre d’une minute lorsque chaque personne commence à donner sa mise à jour pendant le daily scrum. Ce n’est pas grave, mais je trouve que cela oblige souvent une équipe à finir trop vite. La mise à jour de quelqu’un gagnerait souvent à prendre 2 à 3 minutes. Ceci est déconseillé, cependant, avec une minuterie d’une minute par personne.
2. Faites en sorte que l’horloge soit bien visible
Un Scrum Master, Kayleigh, m’a enseigné notre deuxième technique. Au fur et à mesure que chaque personne donne une mise à jour, elle tient un ballon de 3 kg droit devant elle.
La balle n’est pas très lourde, mais la tenir bras tendus devant vous deviendra plus difficile au fur et à mesure que vous parlerez. Ce que j’aime dans cette technique, c’est que la position devient de plus en plus difficile à tenir au fil du temps. Cela le rend très efficace.
3. Interrompez poliment
Voici un troisième conseil pour faire face à un membre de l’équipe trop bavard. Interrompez-le, surtout si vous êtes le Scrum Master ou le coach. Nous hésitons à l’interrompre parce que nous pensons que ce serait impoli. En réalité, ce qui est impoli, c’est que cette personne monopolise la réunion avec son soliloque.
Si quelqu’un est vraiment en train de blablater, le Scrum Master (ou, vraiment, n’importe qui sur le Équipe Scrum) doit les interrompre. Sinon, c’est impoli envers tout le monde dans la réunion.
Voici une bonne façon de l’interrompre poliment. Dites à la personne qui parle qu’il semble qu’elle ait encore beaucoup à dire sur ce sujet. Ajoutez ensuite que tout le monde doit avoir la possibilité de faire le point dans le délai prescrit de 15 minutes. Enfin, proposez de revenir vers l’orateur loquace une fois que tout le monde aura eu l’occasion de partager.
Certaines équipes utilisent l’idée bien connue d’un parking (parking lot) pour de tels sujets. Annoncez simplement que vous ajoutez cet élément au parking et que vous y reviendrez une fois que chacun aura fourni sa mise à jour.
D’autres équipes s’intéressent un peu plus à l’esprit agile des choses et se référeront au parking comme à la « seizième minute ».
4. Créez un signal
Si vous avez du mal à interrompre quelqu’un, voici une technique qui vous aidera. Au lieu d’interrompre la personne, donnez aux membres de l’équipe un moyen de signaler poliment à la personne qu’elle est trop longue. Pensez aux discours de remise des Oscars. Parlez trop longtemps et l’orchestre commence à jouer. Continuez à parler et ils jouent plus fort.
Une façon amusante d’obtenir le même effet est d’utiliser Elmo, le personnage de Sesame Street. Ensuite, utilisez son nom comme acronyme : Assez, passons à autre chose. Si vous êtes tous en présentiel, achetez un Elmo en peluche et gardez-le dans votre salle de réunion. N’importe qui peut brandir l’Elmo en peluche s’il pense que quelqu’un se perd. Cela fonctionne encore mieux pour les visioconférences. Encouragez tout le monde à trouver leur arrière-plan Elmo préféré et à le remonter lorsque quelqu’un parle trop longtemps.
Les daily Scrum sont censées être des réunions rapides et précises. Je ne veux pas qu’une équipe en termine en 5 minutes. C’est certainement trop court pour que quoi que ce soit de significatif ait été discuté ou partagé.
Mais je ne veux pas non plus que la réunion dure trop longtemps, et je ne veux certainement pas qu’une personne monopolise la conversation.
4 choses à essayer lorsque les gens ne parlent pas dans les mêlées quotidiennes
Parlons maintenant de ne pas parler. Comment faire en sorte que quelqu’un s’exprime lors d’une réunion quotidienne ?
Cela ne me dérange pas si quelqu’un reste silencieux lors d’une réunion alors qu’il n’a rien à apporter. C’est très bien, et il faut le féliciter davantage pour ce comportement de quelqu’un qui se sent obligé d’intervenir sur tout.
Mais, rester silencieux dans un stand-up quotidien est un problème parce que chaque personne est censée contribuer.
Pendant des années, les réunions quotidiennes scrum (ou réunions debout quotidiennes) ont suivi le même format. Chaque participant devait dire ce qu’il avait fait depuis la réunion précédente, ce qu’il ferait avant la prochaine réunion et décrire tout ce qui entravait ses progrès. Ces trois éléments représentaient les progrès, les plans et les problèmes d’une personne.
Ces trois éléments ne sont plus exigés d’une équipe Scrum dans ses daily scrum. Ils restent une bonne option par défaut pour la plupart des équipes sur ce qui devrait être couvert lors de la réunion. Mais la façon dont vous arrivez aux progrès, aux plans et aux problèmes n’est pas gravée dans le marbre. Vous devriez changer un peu, surtout si vos mêlées quotidiennes ne fonctionnent pas. Je recommande d’y aller histoire par histoire, plutôt que personne par personne.
Mais que devez-vous faire si vous êtes un Scrum Master ou un coach avec des membres de l’équipe qui fournissent une mise à jour mais ne disent rien de significatif ? Quelque chose comme : « Hier, j’ai travaillé sur quelques tâches. Aujourd’hui, je vais travailler sur quelques tâches. Pas de bloqueurs. »
J’ai entendu cela trop de fois pour les compter. Et ça ne vaut rien.
1. Recherchez les détails
Quand quelqu’un donne une mise à jour comme celle-ci, vous devez le pousser sur les détails. S’ils disent simplement qu’ils ont « travaillé sur certaines tâches », demandez-leur de nommer les tâches spécifiques. Ou si vous êtes physiquement avec un tableau des tâches sur Kanban, demandez-leur de pointer vers les lignes ou les cartes spécifiques.
2. Revenez à la structure
Posez une question à la fois aux personnes qui donnent des mises à jour vagues. Si votre équipe suit la convention de parler des progrès, des plans et des problèmes, posez d’abord des questions sur les progrès.
Ne laissez pas cette personne vous parler des trois aspects de son travail. S’ils commencent à se transformer en plans ou en problèmes, ramenez-les d’abord au progrès. Dites quelque chose comme : « C’est génial, et nous voudrons tous en savoir plus dans une minute sur votre plan pour aujourd’hui, mais sur quelles tâches spécifiques avez-vous travaillé hier ? » Ramenez-les à un seul sujet.
Donnez une structure et rappelez-la souvent.
Souvent, quelqu’un qui donne une mise à jour vague, comme dire qu’il a travaillé sur certaines tâches, est introverti. Et je peux comprendre : moi aussi. Mais ce qu’il faut savoir sur les introvertis, c’est que même si nous redoutons les bavardages, la plupart d’entre nous se débrouillent bien avec les conversations structurées. Alors, renforcez la structure de ces réunions.
Si vous voulez que les gens parlent des progrès, des plans et des problèmes, mettez l’accent sur cette structure en posant des questions sur chacun d’entre eux à tour de rôle.
Une autre façon d’ajouter de la structure à la réunion est de demander aux gens de donner leurs mises à jour dans un ordre connu. Et envisagez de demander aux membres de l’équipe, calmes et vagues, de passer en premier. Ou vous pouvez même y aller en premier vous-même. (Oui : je pense que les Scrum Masters et les coachs devraient aussi donner des mises à jour.)
Une bonne façon de le faire est de commencer par quelque chose comme : « OK, écoutons d’abord Ajay, puis Astrid, mais je vais commencer. » Ensuite, donnez votre propre mise à jour, ce qui donne aux deux personnes que vous avez nommées une chance de préparer les leurs.
Pourquoi est-ce que j’aime commencer par les gens qui donnent des mises à jour vagues? Parce que sinon, ils sont nerveux tout au long de la réunion à l’idée qu’ils seront appelés ensuite. Il est préférable de leur faire savoir quand ils parleront. Et quand vous y allez en premier, vous leur offrez un moment pour rassembler leurs pensées.
4. Renforcez l’objectif
Une autre mesure que vous pouvez prendre est de renforcer l’objectif des réunions debout quotidiennes. Il ne s’agit pas de microgérer une équipe. Les daily scrum ne sont pas des réunions d’étape conçues pour vérifier l’état des choses. Ce sont des réunions de synchronisation. Les membres de l’équipe synchronisent leurs efforts pour s’assurer que rien d’important n’est négligé et que deux personnes ne font pas la même chose sans être conscientes l’une de l’autre.
Lorsque les gens connaissent le but d’une réunion, ils sont plus susceptibles de comprendre la bonne façon de participer, en ne parlant ni trop ni trop peu, mais juste assez !
Affirmation: « La grande majorité des risques identifiés dans les projets ne sont pas gérés. »
Vraiment ?
Cette affirmation est-elle calibrée par rapport aux performances historiques ? En fait non. C’est plutôt intuitif, après avoir réfléchi au nombre de risques qu’un projet d’envergure rencontre.
Et nous parlons de risques ; pas de problèmes.
Donc, lorsque vous examinez cela, gardez à l’esprit la distinction entre un risque et un « problème »
Les risques sont des événements ou des résultats qui sont caractérisés comme ayant une éventualité probabiliste (c’est-à-dire qu’ils peuvent ou pas se produire) et un impact probabiliste, pour lequel il existe une cause fondamentale à l’origine des incertitudes du résultat et de l’impact.
Exemple : Lors de la construction d’une digue, il existe un risque que l’onde d’une tempête dépasse une certaine limite de conception, causant des dommages inhabituellement graves, si une coïncidence temporelle de marée haute, de lune et de pic de tempête se produit.
Les problèmessont des circonstances (des événements, des faits) qui entravent l’efficacité, conduisent à des choses à refaire et, de manière générale, freinent les progrès.
Exemple : Manager les inefficacités de communication dues aux différentes langues et multiples fuseaux horaires est un problème. Il ne s’agit pas d’une probabilité ; Les circonstances sont déterminées et quelque peu figées. Les « coûts » des inefficacités en matière de temps et de langue doivent être établis dans le budget et l’échéancier.
Définir les éléments non gérés
Quand je dis « non gérés », je veux dire qu’une décision a été prise consciemment, je l’espère.
Les conséquences du risque seront prises en compte si et quand un événement se produirait, plutôt que d’établir un plan de management des risques pour identifier la cause profonde et essayer activement (c’est-à-dire en dépensant des ressources) de réduire l’impact et influer sur la probabilité qu’il survienne.
Conséquences
Et donc vous décidez de ne pas gérer certains risques. Qui paie alors pour les conséquences non gérées ? En soi, leur coût n’est pas dans le scénario de référence. La réponse de première instance est d’utiliser des réserves de projet. Une deuxième possibilité est celle des primes de garantie, ou des réserves pour retour de produit. Malheureusement, l’utilisateur/propriétaire peut également devoir payer (j’espère que cela ne vous reviendra pas sous forme de procès car j’ai déjà travaillé dans le domaine de la responsabilité des produits).
Non géré est une décision
Il existe plusieurs raisons pour lesquelles les risques peuvent ne pas être gérés ou ne pas être activement atténués :
#1 – Manque de sensibilisation : Parfois, les parties prenantes du projet et les membres de l’équipe ne sont pas pleinement conscients de tous les risques potentiels associés à un projet.
#2 – Ressources limitées : Les projets, en particulier les plus petits, peuvent manquer de ressources (en termes de temps et de personnel) nécessaires à une gestion holistique des risques.
#3 – Excès de confiance : Les chefs de projet ou les membres de l’équipe peuvent être trop optimistes quant à la réussite du projet et sous-estimer des risques potentiels.
Ne pas décider est déjà une décision.
#4 – Planification inadéquate : Si la phase de planification du projet est précipitée ou manque de rigueur, les risques potentiels pourraient ne pas être identifiés et traités de manière adéquate.
#5 – Mauvaise communication : Une communication inefficace entre les membres de l’équipe et les parties prenantes peut entraîner des malentendus sur les risques du projet et sur la façon de les traiter.
#6 – Culture organisationnelle : Dans certaines organisations, il peut y avoir un manque de culture de sensibilisation aux risques et la gestion des risques n’est alors pas considérée avec l’importance qu’elle mérite.
Reconnaître la valeur du management des risques
Les méthodologies de gestion de projet telles que le PMBOK® de PMI et le PRINCE2 mettent l’accent sur la valeur de la gestion des risques pour la réussite du projet. Il existe des processus bien documentés pour l’identification, l’évaluation et l’atténuation des risques tout au long du cycle de vie du projet. Il en va de même pour une myriade de normes de l’ISO, du DoD des États-Unis, de la NASA, de l’AIA et ainsi de suite dans tous les principaux domaines et industries.
Les chefs de projet expérimentés comprennent l’importance de la gestion des risques.
Bien qu’il y ait des cas où les risques ne sont pas gérés, de nombreuses organisations et managers de projet sont suffisamment intelligents et expérimentés pour savoir qu’ils doivent s’engager activement dans le management des risques afin d’augmenter les chances de réussite du projet.
Partenaire de DantotsuPM, visitez le site pour toutes les formations certifiantes proposées. En particuliers celles sur Prince2.
partagez ce billet avec vos amis, collègues et relations professionnelles
Dans notre monde où les crises se succèdent et même se cumulent, les soft skills prennent de plus en plus de place dans cette nouvelle « normalité ».
Au cours de la crise sanitaire, ces compétences relationnelles avaient subi des tensions contradictoires comme l’avaient montré les précédentes éditions du baromètre des Soft Skills.
Le retour à une conjoncture « normale », faite de crises répétées, de contraintes et de risques multiples, change la donne et pose de nombreuses questions :
Le 4ème Baromètre des soft skills 2024
Comment se comportent les entreprises vis-à-vis des soft skills dans ce nouvel environnement ?
Comment les pratiques et les conceptions évoluent-elles ?
Comment les promesses, les espoirs et les discours théoriques nés de circonstances exceptionnelles évoluent-ils ?
Pourquoi a-t-on besoin d’un sponsor pour réaliser nos projets d’entreprise ? Quelle est la raison d’être du sponsor de projet ? Quels sont ses attributs et ses rôles et responsabilités dans la sélection de nos projets, leur réalisation et dans la maximisation et l’accélération des bénéfices attendus de ces projets ?
Il traite de l’importance du rôle de sponsor de projet dans la sélection, le suivi et la réalisation de nos projets d’entreprise, ainsi que dans la matérialisation subséquente de nos objectifs stratégiques.
Aujourd’hui encore, la fonction du sponsor de projet (aussi appelé parrain, promoteur, champion, commanditaire et/ou client du projet) semble toujours inexistante dans la majorité des organisations, tous domaines confondus.
Lorsque ce rôle existe, il n’est pas intégré de manière à s’assurer qu’il va contribuer à la réussite ultime d’un projet, soit la matérialisation, la maximisation et l’accélération des bénéfices et retombées prévus pour ces projets. Pourquoi ?
Cycle en V, Méthodes itératives, Méthodes agiles et maintenant méthodes hybrides, on ne sait plus où donner de la tête : à chaque décennie sa méthodologie, à chaque méthode ses supporters et ses détracteurs.
Avec 15 ans d’expérience en gestion de projet et en tant qu’intervenante auprès d’étudiants, la question sur la meilleure méthodologie projet revient très souvent.
En tant que chef de projet, vous devrez faire ce premier choix, choix qui peut être impactant pour la suite du projet. Je vous partage ici les quatre points clés vous permettant de choisir la bonne méthodologie.
#1 – Prendre le temps de connaitre le contexte du projet
Migration d’une application existante, volonté de mettre sur le marché une nouvelle offre digitale, mise en place d’un nouveau process : chaque projet est différent. Voici quelques repères « simples » permettant d’associer une typologie de projet à une méthodologie :
Parmi les atouts d’une méthode agile, nous pouvons citer les itérations courtes permettant d’avoir un retour sur le produit rapidement. Le travail conjoint au quotidien entre les métiers et les équipes techniques permet une adaptabilité rapide face aux changements. Cette méthode est adaptée pour le lancement de nouveaux produits.
A l’opposé, la méthode cycle en V a aussi un certain nombre d’avantages : les phases sont prévisibles (et donc la planification des ressources versus d’autres projets), le périmètre est connu à l’avance. Cette méthode est adaptée par exemple lors de migrations techniques : peu d’incertitude sur la finalité du produit, impératifs business réduits.
Et il y a la vraie vie : votre projet. Il n’est pas complètement agile parce que la direction des achats demande une estimation budgétaire (donc besoin d’un périmètre soi-disant figé). Néanmoins, le périmètre n’est pas suffisamment stable pour appliquer une pure méthode cycle en V parce que certaines fonctions sont encore « à creuser ». Dans ces cas-là, une approche itérative ou encore hybride peut être utilisée.
#2 – Se former… mais garder les fondamentaux toujours en tête
Mener un projet en mode agile quand on ne s’est jamais formé, c’est comme demandé à un développeur de développer une application en technologie Java alors qu’il ne connait que Python et ce dans les mêmes délais qu’un expert Java !
Mener un projet en cycle en V si on n’a fait que de l’agilité, c’est partir à l’échec !
En tant que chef de projet, vous devez donc vous former aux différentes méthodes : cela vous permettra de prendre du recul par rapport à l’existant, d’être confiant sur la méthodologie que vous souhaitez mettre en place et surtout de vérifier son adéquation à votre contexte projet.
Et même en étant formé, n’oubliez pas les fondamentaux d’un projet : fixation des objectifs du projet, gestion des risques, gestion de la communication, suivi budgétaire et du périmètre. Quel que soit la méthodologie ou les outils utilisés, tous ces aspects doivent être adressés pour garantir la maitrise du projet.
#3 – Connaitre les parties prenantes du projet
Une fois que vous avez pris connaissance du contexte et que vous avez acquis une bonne connaissance des différentes méthodologies projet, vous êtes convaincus : c’est la méthode agile qu’il faut utiliser sur ce beau projet à venir !
Sauf que la durée estimée du projet est de 6 mois, que votre équipe n’a jamais travaillé avec cette méthodologie et que les métiers ouvrent de grands yeux quand vous leur parlez de « User Stories » ; surtout ils ne sont pas du tout disponibles sur toute la durée du projet. Arrêtez tout !
Une méthodologie doit s’adapter non seulement au contexte du projet mais également aux parties prenantes du projet.
Si vous avez de la marge de manœuvre sur le planning, vous pourrez décider de prendre plus de temps pour planifier des formations, négocier les disponibilités. Dans le cas contraire, abandonnez la méthode agile de vos rêves pour revenir sur une méthode plus classique de type cycle en V ou hybride.
#4 – Savoir innover
Pour finir, ne soyez pas rigide sur une méthode. Ne perdez pas de vue l’objectif initial du projet, les fondamentaux du management de projet, le niveau de maturité des parties prenantes, vos propres connaissances et enfin vos marges de manœuvre.
Combiner à une approche Lean, vous serez en mesure de changer certains aspects de la méthodologie choisie initialement, d’innover et de rendre votre méthode de plus en plus efficace et efficiente au fil du temps projet.
Ophélie GOMES
43 ans, mariée 2 enfants de 16 et 13 ans
Ophélie Gomes
Je suis issue d’une filière technologique : diplômée MIAGe à Lyon en 2002. J’ai commencé ma carrière dans une Entreprise de Services du Numérique (ESN) en tant que développeuse Java en mars 2003 tout en continuant en parallèle une thèse en Business Intelligence que j’ai soutenue en 2010.
J’ai occupé différentes fonctions dans l’IT pendant 10 ans chez Capgemini à Grenoble: Business Analyst, Chef de projet run, chef de projet build dans différentes technologies (java, SAP, Documentum, .Net) et différents secteurs (Services privés, Énergies, secteur public, industrie). J’ai ensuite rejoint un éditeur de logiciel où j’ai occupé mon premier poste de manager. En 2017, je retourne chez Capgemini pour participer à la mise en place des processus de delivery pour toute l’entité au niveau France. En plus de mon rôle de manager, je suis coach agile certifiée SPC – Implementing SAFE.
Depuis 6 mois j’occupe le poste de Head of Delivery & digital chez Europ Assistance France
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
DantotsuPM.com 