Téléchargez gratuitement ce document de référence.
Ce cadre de travail est destiné à transformer la façon dont les entreprises intègrent le développement durable dans leurs opérations. Avec de nouveaux éléments ciblant des questions éthiques cruciales telles que le blanchiment d’argent et le financement du crime organisé, cette nouvelle norme souhaite établir de nouvelles références en matière de responsabilité des entreprises et de conduite éthique des affaires !
Pourquoi une nouvelle norme ?
Au cours de l’année écoulée, GPM a découvert que les organisations ont tiré parti de la norme P5 pour la durabilité dans la gestion de projet (P5 Standard for sustainability in project management) de manière innovante qui va au-delà du management de projet.
Cette version marque la deuxième norme de GPM en dehors du domaine du management de projet, après lanorme de compétence GPM pour le leadership en matière de développement durable (GPM Competence Standard for Leadership in Sustainability) lancée en 2023. Il s’agissait de la première norme au monde de ce type basée sur la performance.
Et voici la meilleure partie : c’est totalement gratuit !
Vous n’avez pas besoin d’être membre ni de payer pour l’obtenir.
GPM sait que la durabilité est le plus grand défi de notre époque, et des normes comme celles-ci, ainsi que les outils tels que l’évaluation d’impact et le plan d’intervention en matière de durabilité, doivent être accessibles à tous.
Alors venez les chercher ! Utilisez-les ! Soyons les architectes d’un monde meilleur !
La Charte Projet est le début officiel du projet. Elle vous autorise formellement vous et votre équipe à commencer le travail sur les tâches requises. Sans charte, vous n’avez pas le mandat de faire faire des choses !
Billet Original d’après « 6 Things to Include in Your Project Charter » de Jennifer Whitt
Voici 6 choses critiques à inclure dans votre charte.
Déclaration des besoins fonctionnels
Besoins du Projet
Chef de projet assigné
Jalons de Projet
Assomptions de projet
Parties prenantes du projet
Rappelez-vous d’inclure le développement de la charte projet dans le planning de projet.
La charte projet est un début essentiel à un projet. Vous pouvez la réviser plus tard, particulièrement si votre projet va avoir des phases multiples, ne considérez pas qu’elle soit gravée dans le marbre.
Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes
partagez ce billet avec vos amis, collègues et relations professionnelles
Les meilleures pratiques du management de projet, programme et portefeuille de projets, partage d’expériences, questions/réponses sur les thèmes de ce domaine qui vous intéresse.
Ce blog est également ouvert aux discussions sur le leadership, l’innovation, les petites idées qui permettent de se faciliter la vie professionnelle et de progresser.
Ci-dessus, un extrait du contenu du tout premier billet, le 26 Juin 2009 !
Le blog DantotsuPM est né de mon envie de partager (dans la continuité de la création du PMI® France-Sud dans les années 2000).
Pourquoi ce nom « DantotsuPM » ?
Comme beaucoup d’entre vous qui suivez mes publications, je cherche en permanence à améliorer les multiples compétences qui permettent de progresser dans ma vie et mes pratiques.
C’est d’ailleurs de là que vient le nom du blog car le mot Dantotsuque j’ai croisé lors de voyages professionnels au pays du soleil levant signifie en Japonais « rechercher en permanence le meilleur du meilleur ».
J’ai accolé PM à Dantotsu pour Project Management, ma passion : DantotsuPM était né !
Je sélectionne, traduit en français et publie sur ce blog des billets liés au management de projets, programmes, Project Management Office (PMO) et Portfeuilles de projets (PPM), aux soft skills, à l’agilité, à l’analyse des besoins business et au leadership.
N’hésitez pas à réagir aux billets avec vos commentaires.
Contactez-moi sur LinkedIn pour publier vos propres articles.
Si votre société souhaite accroitre sa visibilité auprès des managers de projets et de leurs organisations, devenez sponsor-partenaire du blog DantotsuPM.
Il y a déjà plus de 4000 billets en ligne et j’en publie un nouveau chaque jour…
Je vous invite donc à venir y piocher à votre rythme et selon vos besoins.
Visitez également l’espace ressources gratuitesqui contient de nombreux pointeurs vers des documents utiles aux managers de projets.
J’espère que vous apprécierez d’utiliser les catégories qui regroupent les billets autour de grands thèmes ainsi que les mots clés qui rendront vos recherches plus faciles (dans la colonne de droite).
Voilà, je vous souhaite de belles lectures et de riches échanges et contributions à notre communauté de passionné.e.s du management de projets.
partagez ce billet avec vos amis, collègues et relations professionnelles
Le management de projet hybride vient de connaître son heure de gloire !
Le Project Management Institute Pulse of the Profession® 2024 déclare que l’approche hybride (32 %) est maintenant la deuxième approche la plus couramment utilisée. L’approche prédictive (44 %) détient toujours une avance considérable. Et l’utilisation d’Agile(26 %) perd 2 points.
Avant de nous enthousiasmer, le rapport sur l’état de l’agilité (State of Agile Report) identifie différentes tendances. et ses répondants préfèrent l’agilité (70 %) à l’hybride (47 %) et à l’approche prédictive Waterfall (35 %).
Derrière cette annonce
Plusieurs facteurs peuvent être à l’origine de ces tendances récentes :
Agile et Waterfall sont les angles du continuum de management de projet, et l’hybride en est le vaste milieu. La plupart des organisations ne pratiquent ni l’agilité pure ni l’approche prédictive ; L’hybride est donc une description plus exacte.
L’intérêt pour les hybrides est nouveau et augmente rapidement. Le format de l’ examen PMP a changé en janvier 2020. Dans le nouveau test, 27 % des questions étaient hybrides et 23 % agiles. Cela a déclenché une explosion du trafic de recherche Google pour le « management de projet hybride ».
Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes
Agile a peut-être « heurté le mur ». L’agilité est fondamentalement un état d’esprit, pas une méthodologie. Les principaux défis de l’adoption de l’agilité sont organisationnels et culturels. Le rapport sur l’état de la culture Agile montre que seuls 10 % des leaders font preuve des qualités souhaitées.
La palette d’approches de projet
La profession de manager de projet se décrivait historiquement en termes discrets. Waterfall avait une emprise quasi monopolistique jusqu’à l’avènement de l’agilité. La profession est alors entrée dans un monde bipolaire : agilistes contre traditionalistes.
En réalité, le management de projet est désordonné. On peut le décrire comme « la cathédrale versus le bazar ». Les développeurs de cadres de travail parlent dans les termes absolutistes de la cathédrale, tandis que les managers de projet mélangent les pratiques comme on le voit dans un bazar.
Hybride nous permet de donner un nom à ce mélange de la vaste palette de couleurs. Prédictif, agile et Lean/Kanban peuvent être considérés comme les pointes d’un triangle avec un éventail presque infini d’options.
Le spectre des approches peut être étiqueté comme suit :
Prédictif. L’approche traditionnelle, prédictive et très structurée ;
Agile (Scrum). Une approche adaptative avec des équipes autonomes et auto-organisées ;
Lean/Kanban. Des principes axés sur les valeurs et les flux qui peuvent être intégrés dans toutes les approches ;
Hybride-prédictif. Des structures principalement traditionnelles avec des pratiques agiles intégrées ; et
Hybride-agile. Une approche adaptative tempérée par les contraintes traditionnelles.
Relisez ce billet : « Que signifie vraiment ‘en cascade’ (Waterfall) dans le management de projet ? Comment les gens utilisent-ils cette expression ? »
Prédictif
Winston Royce a décrit pour la première fois l’approche waterfallen 1971 comme une méthodologie de développement logiciel basée sur son expérience de la construction de systèmes pour les engins spatiaux. Il a défini une série d’étapes en cascade allant de la collecte des besoins aux opérations de déploiement.
relisez ce billet sur les bénéfices de l’approche Waterfall (‘en cascade’)
L’établissement précoce des exigences et des spécifications de conception est une caractéristique essentielle des projets prédictifs. Cette approche est utilisée dans la construction et les efforts similaires où le coût du changement est élevé. Les projets ont souvent des passages de phase rigides pour confirmer la viabilité et l’exhaustivité avant de passer à l’étape suivante.
Les équipes de projet travaillent sur leurs composants individuels et intègrent et testent périodiquement leur travail. Le rôle principal du manager de projet est de coordonner et de superviser les efforts de ces équipes alignées sur le plan fonctionnel. Une collaboration inter-équipes limitée est nécessaire.
L’engagement des parties prenantes est plus important au début du projet, lorsque les exigences sont collectées et analysées. Tout au long du cycle de développement, il y aura des réunions et des revues périodiques de l’état d’avancement. Il faut souvent des années avant que les parties prenantes ne voient le produit fini.
Agile (Scrum)
L’agilité est un état d’esprit, pas une méthodologie. De multiples cadres de travail frameworks (Scrum, eXtreme Programming, DSDM, Scaled Agile (SAFe), Disciplined Agile, etc.) permettent aux équipes de fournir de la valeur plus rapidement et de manière plus prévisible. Les cadres de travail ne sont pas monolithiques et représentent un éventail d’approches et de pratiques.
Scrum est la méthodologie la plus couramment utilisée et ancre cet angle du triangle. Scrum décrivait à l’origine comment développer un nouveau produit et a ensuite été adopté pour des projets logiciels complexes par Jeff Sutherland et Ken Schwaber.
Plusieurs vidéos intéressantes sur Scrum en langue anglaise
Royce s’est rendu compte que les cycles de test tardifs et les délais de livraison prolongés de l’approche prédictive waterfall posaient un risque important. Scrum atténue ces risques grâce à son approche itérative et incrémentielle. Les cycles de développement sont généralement limités à 2 semaines, après quoi les parties prenantes fournissent des retours. Le retour d’information est utilisé pour adapter et ajuster le produit et éviter le piège du « je le saurai quand je le verrai ».
Les équipes Scrum sont petites (moins de 10), auto-organisées et exploitent les énergies créatives des travailleurs du savoir. Le manager de projet de type « commande et contrôle » est remplacé par le scrum master serviteur, dont le rôle principal est d’aider l’équipe à mûrir. Le Product Owner est un membre à part entière de l’équipe et représente la voix du client.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
Lean/Kanban
Le Lean et le Kanban sont un ensemble de principes et de pratiques, datant des années 1950, développés à l’origine par Toyota. Le Lean se concentre sur la création de valeur et l’élimination du gaspillage. Kanban est une sous-pratique Lean qui se concentre sur la création et la gestion de flux.
Tableau Kanban pour tâches et projets avec Christian Hohmann
Lean/Kanban est la troisième extrémité du triangle. Bien qu’ils soient souvent associés à l’agilité, leurs pratiques sont universelles. Ceci est fondamental pour la plupart des frameworks agiles, et les équipes agiles très matures se concentrent souvent sur le flux (Kanban). Dans Disciplined Agile, le Lean est défini comme un cycle de vie autonome. SAFe 6.0 sépare l’équipe Kanban de son approche Scrum.
Hybride-Prédictif
L’hybride-prédictif suit principalement la structure linéaire waterfall et intègre des pratiques de type agile. La structure conception-construction-test-déploiement prend en charge efficacement de nombreux types de projets. Cependant, les approches purement prédictives peuvent être rigides et reposer sur l’hypothèse forte que la solution peut être définie dès le début du projet.
Avez-vous déjà lu ce billet : Qu’est-ce que Agile Hybride en réalité ?
Les équipes logicielles ont commencé à utiliser des approches en « waterfall modifié » dans les années 1970, bien avant l’avènement de l’agilité. Ils ont utilisé des approches itératives et progressives pour mobiliser les intervenants. Des sessions de prototypage et de conception d’applications conjointes (JAD) ont permis aux utilisateurs et aux développeurs de collaborer sur la solution.
Même la construction, qui est le bastion de l’approche en cascade, a adopté l’hybride. Traditionnellement, la conception et la construction sont des activités spécialisées et séparées. Les firmes d’architecture et d’ingénierie créent des plans et des devis qui sont ensuite exécutés par les entreprises de construction. Cependant, la conception-construction combine ces deux activités en un seul contrat exécuté par une seule entreprise. Cette approche améliore la collaboration, la coordination et la communication. Les avantages sont des cycles de développement plus courts, des coûts réduits, moins d’erreurs et une responsabilité claire.
L’approche prédictive-hybride peut être décrite comme penchant davantage vers la structure waterfall et intégrant des pratiques agiles. Il existe plusieurs modes d’utilisation. L’un est un projet structuré qui utilise des techniques agiles telles que des stand-ups quotidiens, une documentation minimale suffisante et un engagement fréquent des parties prenantes. Un autre modèle est la conception initiale de haut niveau avec un développement itératif et/ou une livraison incrémentielle.
Hybride-Agile
De nombreuses organisations prétendant être agiles utilisent probablement une approche hybride-agile. Elles suivent un modèle de type Scrum et utilisent de nombreuses pratiques agiles. Cependant, des contraintes empêchent l’adoption de l’état d’esprit agile. Ces limites sont souvent liées à la culture, à la structure et à la nature du travail de l’organisation.
Les grandes entreprises bureaucratiques, les agences gouvernementales et les organisations à faible maturité agile correspondent à ce modèle. Elles peuvent suivre de nombreuses pratiques de Scrum ; Cependant, elles font face à de nombreux défis, notamment :
Le contenu du projet est fixe et la solution complète est livrée à la fin du projet.
Les parties prenantes ne participent pas activement aux démonstrations progressives du produit et des tests d’acceptation approfondis par les utilisateurs sont effectués à la fin.
Les équipes ne sont pas habilitées à prendre des décisions. Les décisions sont prises par la direction ou par un comité.
Les équipes ne sont pas établies depuis longtemps et les membres sont affectés à plusieurs projets.
Le Product Owner vient de l’équipe technique et ne représente pas pleinement la voix du client.
“PMI”, the PMI logo, “PMP”, “PMBOK”, “PM Network”, “Project Management Institute” and “Pulse of the Profession” are registered marks of Project Management Institute, Inc.
partagez ce billet avec vos amis, collègues et relations professionnelles
L’approche Hybride va au-delà du cadre méthodologique incitant au mélange d’outils et de pratiques, elle est novatrice, essentielle et multidimensionnelle. Ceci a conduit à la structuration de 8 cas concrets et diversifiés selon 3 axes : Gouvernance, Cadre Méthodologique et Dimension Humaine.
C’est avec une grande joie que l’initiative Lab Hybrid du PMI France a annoncé la publication du 1er guide pratique en Management de projet « Hybride »!
Après deux ans de réflexions et de discussions, le groupe expérimenté en Management de Projet à finalisé l’élaboration de ce guide pratique définissant et illustrant le management de projet Hybride au travers de cas concrets. Ce guide décrit 8 situations professionnelles spécifiques reflétant la diversité des problématiques rencontrées et les solutions offertes par l’Hybridation.
Disponible sur Amazon
L’Approche Hybride va au-delà du cadre méthodologique incitant au mélange d’outils et de pratiques, elle est novatrice, essentielle et multidimensionnelle.
Ceci a conduit à la structuration de ces cas selon 3 axes : Gouvernance, Cadre Méthodologique et Dimension Humaine
Les ‘OKR’ (Objectives and Key Results), comme la plupart des méthodologies, supportent des principes sous-jacents qui, s’ils sont bien mis en œuvre, peuvent fondamentalement changer l’état d’esprit et la conversation au sein de votre organisation.
OKRs: So simple! So then why isn’t everyone using them? par Kim Atherton
Après 7 ans de mise en œuvre d’OKRs à la fois depuis l’intérieur et l’extérieur des organisations, j’ai appris qu’ils ne sont pas la solution miracle que je pensais qu’ils étaient. Cependant, comme la plupart des méthodologies, il existe des principes sous-jacents qui, s’ils sont bien mis en œuvre, peuvent fondamentalement changer l’état d’esprit organisationnel et la conversation.
Dans cet article, je vais vous donner quelques conseils pour vous remettre sur les rails avec les OKRs.
Soyez clair sur votre direction pour aider les équipes à aligner leurs objectifs et leurs résultats
Concentrez-vous sur ce qui compte vraiment lors de l’utilisation des OKRs. Limitez vos priorités et cherchez toujours à ajouter de la valeur à vos tâches.
Faites un suivi et apprenez tout en encourageant un état d’esprit expérimental. L’utilisation de données peut être utile pour assurer la transparence et le sens de tout ce que vous faites. Soyez toujours à la recherche de choses qui fonctionnent et qui ne fonctionnent pas pour créer une culture d’apprentissage au sein de votre équipe et de l’organisation au sens large.
L’utilisation d’OKRs promet des avantages alléchants pour l’organisation.
1) Alignez les équipes et apportez de la clarté
La cascade des OKRs, depuis la stratégie de l’entreprise jusqu’au niveau de l’équipe, signifie que les efforts de chacun sont liés. Plutôt que de travailler en solos indépendants, tous les efforts sont ciblés et coordonnés, ce qui donne un sentiment de clarté qui pourrait autrement manquer. Apprenez-en davantage sur la constitution d’équipes extraordinaires.
2) Mettez l’accent sur les résultats axés sur la valeur
Les résultats clés (Key Results) doivent être des mesures quantifiables de la réussite de l’entreprise plutôt que des projets ou des jalons indéfinis. Cela permet à tout le monde de se concentrer sur ce qui compte vraiment plutôt que sur une liste de projets de prédilection des équipes de direction et éviter le risque de devenir une usine à fonctionnalités. Tout le monde s’efforce de créer de la valeur pour l’entreprise.
3) Encouragez un état d’esprit expérimental
Le fait de relier les initiatives (qui sont des expérimentations ou des projets) à des résultats clés (Key Results) quantifiables (résultats business) signifie que l’impact qu’elles ont peut être suivi. Cela permet à l’ensemble de l’organisation d’adopter une approche plus entrepreneuriale et contribue à intégrer les principes Agile que beaucoup d’entre vous cherchent à adopter. De plus, la cadence des OKRs est généralement annuelle au niveau de l’organisation, mais trimestrielle au niveau de l’équipe, ce qui conduit à une approche plus dynamique et adaptable.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
4) Donnez de la transparence et une raison d’être
Alors qu’auparavant, les objectifs stratégiques plus larges d’une entreprise n’étaient peut-être connus que de la direction, les OKRs devraient être visibles par tout le monde à tous les niveaux d’une organisation. Cela permet de favoriser la collaboration et le sentiment d’utilité en donnant aux équipes une compréhension de ce sur quoi tout le monde travaille et des opportunités de collaborer ensemble sur des objectifs communs. Dans une récente enquête MTP sur les OKRs, 48 % des personnes interrogées ont déclaré que le principal avantage de l’utilisation des OKRs est une transparence accrue dans l’ensemble de l’organisation.
Ça a l’air génial, mais attention à certains pièges fréquemment rencontrés.
Jusque-là, c’est simple mais hélas, comme toujours, le diable est dans les détails. Lorsque j’ai mis en œuvre les OKRs pour la première fois avec OVO Energy, nous étions une entreprise en pleine expansion qui allait bientôt devenir une licorne et j’ai pensé que bon nombre des pièges dans lesquels nous sommes tombés pouvaient être attribués à cela. Cependant, depuis que j’ai lancé Just3Things il y a deux ans, en travaillant avec des clients de 200 à 20 000 employés, j’ai constaté qu’il existe des pièges communs aux organisations, grandes comme petites.
1) Les OKRs semblent simples, mais sont trompeusement difficiles à réussir !
La plupart des équipes commencent judicieusement par réfléchir aux objectifs qui soutiennent les résultats stratégiques à long terme et aux critères de mesure qui constitueraient le succès (jusque-là, tout va bien). Cependant, le plus souvent, les résultats clés (Key Results) ne sont pas mesurables, les données ne sont pas disponibles ou la métrique arrive tardivement et on ne s’attend pas à ce qu’elle change pendant des mois, quel que soit le nombre d’initiatives mises en œuvre. De plus, il est trop facile d’essayer d’intégrer trop d’indicateurs clés de performance dans les OKRs.
Pour essayer de décrire la différence : Imaginez que vous êtes allé chez le médecin pour un bilan de santé et que votre tension artérielle est bonne. Vous pourriez garder un œil dessus, mais vous ne prendrez aucune mesure pour la changer. Cependant, si votre tension artérielle est élevée, vous prendrez des mesures pour l’améliorer (par exemple, commencer à faire de l’exercice, changer de régime alimentaire, etc.), auquel cas la pression artérielle passera d’un indicateur clé de performance à un résultat clé. Étant donné qu’il est difficile de trouver des KRs (Key Results) qui sont mesurables, qui ne sont pas trop en retard, qui ne sont pas des KPIs (Key Performance Indicators) et qui se rapportent réellement à l’objectif, il n’est pas étonnant que…
2) quand les OKRs sont prêts à être diffusés, c’est la déjà fin du trimestre !
J’ai vu cela à plusieurs reprises, allant de pair avec le piège d’avoir tellement d’OKRs par équipe qu’ils ont à peine le temps de commencer à faire bouger l’aiguille du cadran pour le prochain trimestre avant qu’il ne soit temps de recommencer à planifier. En fait, la nécessité de limiter les équipes à un petit nombre de priorités, afin de maintenir la faisabilité de leurs plans, est exactement le principe intégré à « Just3Things » depuis le départ.
3) Il est difficile d’obtenir le bon alignement.
Beaucoup de choses ont été écrites sur la question de savoir si les équipes devraient posséder un KR (Key Result) de l’objectif d’une autre équipe ; Si les équipes doivent partager les OKRs ; Si l’alignement doit être horizontal ou vertical ?
Ayant vécu cela avec de nombreuses organisations, la seule conclusion que je peux en tirer est qu’il n’y a pas de « taille unique » qui conviennent à toutes les organisations. Cependant, il est essentiel d’avoir une combinaison d’alignement descendant (où la direction définit les objectifs stratégiques et les OKRs annuels) et d’alignement ascendant (où les équipes définissent les OKR ssur lesquels elles savent qu’elles travaillent).
4) La prise de conscience que tout doit changer !
Lorsque j’ai commencé à travailler avec les OKRs, j’ai pensé qu’ils constitueraient un complément intéressant à la gouvernance et aux pratiques organisationnelles existantes. La réalité a commencé à s’immiscer lors de la première réunion de l’équipe de direction, lorsque le PDG a demandé à chaque département sa mise à jour mensuelle (le tour de table habituel des indicateurs clés de performance et du BAU « Business As Usual »). Il m’est venu à l’esprit que rien de ce qui avait été dit au cours de la dernière heure ne concernait les OKRs dont, quelques semaines auparavant, nous avions tous identifiés comme étant les choses les plus importantes que l’entreprise devait réaliser. Nous n’étions pas les seuls.
Lefebvre Dalloz Compétences est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
Beaucoup de mes clients ne réalisent pas la nécessité de changer :
La façon dont les progrès sont suivis ;
La façon dont les mises à jour sont présentées ;
La manière dont les équipes relaient leurs progrès ;
La façon dont les réunions sont présidées et managées.
Et ceci est nécessaire avant de commencer à réfléchir à la façon dont les OKRs s’intègrent aux évaluations de performance (alerte spoiler : ce n’est pas le cas). Cependant, si vous faites les choses correctement, vous pourrez vraiment commencer à vous concentrer sur ce qui compte, jusqu’à ce que…
5) L’équipe de direction demande « qu’en est-il de mon projet favori ? »
Même si le rose est la couleur préférée du dirigeant, tout ne peut être peint en rose.
J’ai vu de nombreux déploiements d’OKRs dérailler au moment où un cadre exécutif se rende compte que : Si nous encourageons une culture responsabilisée d’équipes qui expérimentent des initiatives et leur donnons accès aux données client sous-jacentes pour voir si leurs livrables fonctionnent réellement… alors les backlogs ne peuvent plus contenir de fonctionnalités que moi et le reste de l’équipe de direction « avons vu l’entreprise X faire et elles doivent donc être géniales » !
6) Ne pas rendre les OKRs transparents, avec des progrès facilement traçables et des résultats faciles à apprendre.
Je suis le pire des vendeurs et je ne suis pas là pour blâmer les logiciels (honnêtement), mais avoir un moyen de partager l’alignement des OKRs, de suivre régulièrement les progrès et d’examiner ce qui fonctionne est essentiel à leur succès.
Il n’est pas nécessaire qu’il s’agisse d’une plate-forme logicielle – un disque partagé, un tableau blanc de bureau physique pré-COVID ou tout autre moyen de partage qui fonctionne est génial – mais les progrès doivent être suivis sinon les OKRs vont dans le sens de l’objectif annuel Powerpoint et ne seront dépoussiérés que lorsqu’il est temps de faire le bilan de l’année.
Alors pourquoi s’embêter ? Quelques points clés à retenir.
Il est indéniable que les OKRs sont difficiles à mettre en place et que trop d’entre nous peuvent être pris dans les « règles ». Cependant, comme tant de méthodologies, il existe des principes sous-jacents fantastiques.
Les choses que je retiendrais si je voulais créer une organisation responsabilisée habilitée seraient les suivantes :
Définissez une direction claire
En définissant les objectifs stratégiques et les objectifs organisationnels, les équipes peuvent aligner leurs objectifs et le travail qu’elles accomplissent pour les atteindre.
Concentrez-vous sur ce qui compte vraiment
Faites la distinction entre les résultats business et les projets/initiatives/fonctionnalités car c’est déjà une énorme victoire. Concentrez-vous sur moins de priorités et travaillez en équipe pour les atteindre pour une réelle valeur ajoutée pour l’organisation et ses employés.
Suivez les progrès, apprenez et adaptez-vous
Assurez-vous que tous les objectifs et initiatives sont transparents. Encouragez les équipes à vérifier régulièrement les progrès et à noter pourquoi une initiative a fonctionné ou pas pour référence future afin de partager les apprentissages au sein de l’organisation.
Le NIST des États-Unis a publié, après de longues discussions et des ébauches revues, son cadre de management des risques (Risk Management Framework / RMF) pour l’IA.
Le RMF de l’IA fait référence à un système d’IA comme un système conçu ou basé sur une machine qui peut, pour un ensemble donné d’objectifs, générer des résultats tels que des prédictions, des recommandations ou des décisions influençant des environnements réels ou virtuels. Les systèmes d’IA sont conçus pour fonctionner avec différents niveaux d’autonomie (Adapté de : Recommandation de l’OCDE sur l’IA: 2019 ; ISO/CEI 22989: 2022).
Tout n’est pas nouveau
Beaucoup d’éléments sont tirés des normes ISO de management des risques, ainsi que d’autres guides de gestion des risques de l’Agence.
Il n’est pas surprenant que Gary Marcus voit un grand risque dans l’acceptation des résultats des modèles de réseaux neuronaux qui interrogent de très grands ensembles de données, car, comme il le dit, sans connectivité contextuelle aux modèles d’IA symboliques (le genre que vous obtenez avec les algorithmes de symboles, comme celui de l’algèbre), il y a peu de moyens (pour l’instant) de valider la « vérité ».
Selon lui, le risque de systèmes comme ceux récemment introduits par OpenAI et autres est qu’avec ces outils, le coût de production d’absurdités sera ramené à presque zéro, ce qui facilitera l’inondation d’Internet et des réseaux sociaux de mensonges à des fins économiques et politiques.
Les détails comptent. Ils sont importants dans tous les domaines de notre vie. Les détails font souvent la différence entre un résultat positif et un résultat infructueux.
Quand j’étais beaucoup plus jeune, j’ai sauté d’un avion qui fonctionnait parfaitement. Ce n’était pas exactement par choix, je suis allé dans une école militaire et cela faisait partie du contrat. Quand ils vous disaient de sauter, vous sautiez. Mais j’ai appris ce fait peu connu : Vous n’avez pas besoin d’un parachute pour sauter d’un avion. Vous pouvez simplement ouvrir la porte et sauter. En fait, il est plus rapide d’atteindre le sol sans parachute.
Il y a cependant un petit détail à garder à l’esprit. Si vous avez l’intention de sauter d’un avion une deuxième fois, un parachute est fortement recommandé. Si vous manquez ce petit détail, le résultat de votre premier saut sera loin d’être idéal. Mais encore une fois, le saut lui-même est tout à fait faisable sans parachute.
Les détails comptent. Ils sont importants dans tous les domaines de notre vie. Les détails font souvent la différence entre un résultat positif et un résultat infructueux.
Voici quelques-unes des raisons pour lesquelles les petits détails peuvent être si importants.
Précision : Prêter attention aux détails garantit l’exactitude de l’information, de la communication et de l’exécution. Cela permet d’éviter les erreurs et les malentendus, ce qui permet d’obtenir de meilleurs résultats dans presque toutes les situations.
Clarté : Les détails apportent de la clarté et du contexte à n’importe quelle situation. Ils aident à comprendre les subtilités et les nuances d’un sujet, ce qui permet aux autres de comprendre plus facilement votre message ou vos actions.
Résolution de problèmes : Dans la résolution de problèmes, l’attention portée aux détails est cruciale. Elle vous permet d’identifier les causes profondes des problèmes et de les traiter efficacement. Ignorer les détails peut entraîner des solutions superficielles qui ne résolvent pas les problèmes sous-jacents.
Prise de décision : Dans les processus de prise de décision, les détails aident à évaluer les options et à prédire les résultats potentiels. Prendre des décisions éclairées nécessite une compréhension approfondie des détails entourant une situation.
Professionnalisme : Le souci du détail est souvent associé au professionnalisme. Que ce soit sur le lieu de travail, à l’université ou dans la vie personnelle, être méticuleux dans votre travail démontre un engagement envers la qualité et l’excellence.
Prévention des erreurs : De petits détails peuvent parfois avoir un impact significatif. En prêtant attention aux détails, vous pouvez détecter les erreurs potentielles avant qu’elles ne dégénèrent en problèmes plus importants.
Efficacité : Avoir une bonne compréhension des détails permet un travail plus efficace et plus effectif. Cela minimise le besoin de refaire ou de corriger, ce qui permet d’économiser du temps et des ressources.
Communication : Une communication claire et détaillée est essentielle pour transmettre des idées avec précision. Les détails permettent d’éviter les erreurs d’interprétation et de s’assurer que le message est compris comme prévu.
Établir la confiance : Prêter constamment attention aux détails permet d’établir une relation de confiance avec les autres. Que ce soit dans les relations personnelles ou les collaborations professionnelles, les gens ont tendance à faire confiance aux personnes qui font preuve d’un engagement envers la précision.
Les détails font toujours la différence. Parfois, la différence est petite, parfois elle est énorme. Prêter attention aux petites choses donne aux gens l’assurance que vous ferez également attention aux plus grandes choses. Sauter des détails a un impact négatif sur votre crédibilité. Tant dans votre vie personnelle que dans votre carrière. Lorsque les détails passent à travers les mailles du filet, il est très probable que votre réussite globale dans la vie passe également à travers les mailles du filet.
Faites attention aux petites choses et de grandes choses se présenteront probablement à vous.
partagez ce billet avec vos amis, collègues et relations professionnelles
Un nouveau standard ou une nouvelle édition d’un standard existant sont toujours de grandes nouvelles pour les professionnel(le)s du Management de projets, programmes et portefeuilles. Voici l’annonce du The Standard for Program Management, Fifth Edition (2024).
Les programmes sont essentiels pour les organisations qui cherchent à atteindre leurs objectifs stratégiques. De l’initiation à la réalisation des bénéfices, les directeurs, directrices et managers de programme et leurs équipes unissent leurs efforts dans plusieurs projets interconnectés pour créer plus de bénéfices que la somme de leurs composantes.
Visitez la page du site PMI.ORG
The Standard for Program Management – 5ème édition fournit un cadre et des conseils aux personnes et organisations qui cherchent à améliorer leurs pratiques de management de programme. Cette édition identifie 8 principes qui guident le comportement au sein du management de programme, faisant de cette publication un standard fondé sur des principes.
Un nouveau domaine de performance de management de programme, la collaboration, est introduit et incorporé à un contenu réorganisé pour une approche simplifiée de la lecture, de la compréhension et de l’utilisation du standard. Ce domaine favorise l’interaction entre les cinq autres domaines afin de manager le programme dans son ensemble en s’appuyant sur les capacités spécifiques de l’être humain telles que l’intégration, la création de synergies et l’optimisation des ressources.
Offert par le Project Management Institute® (PMI), il s’agit d’un outil puissant pour toutes les organisations, quelles que soient leurs méthodes de réalisation de projets. Il s’agit d’une ressource inestimable pour les managers et directeurs/directrices de portefeuilles, de programmes et de projets, ainsi que pour les cadres supérieurs et les parties prenantes.
Ce standard s’aligne bien sûr étroitement sur les connaissances décrites dans A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – septième édition et sur les autres standards du PMI.
“PMI”, the PMI logo, “PMP”, “PMBOK” and “Project Management Institute” are registered marks of Project Management Institute, Inc.
partagez ce billet avec vos amis, collègues et relations professionnelles
Dans ce nouveau numéro du Journal du Contract Management, les actualités de la profession ainsi que des thèmes variés sont abordés, notamment celui de la stratégie contractuelle – vaste sujet ! Jean-Charles Savornin
Téléchargez la dernière édition.
En tant que manager de projet, vous aurez probablement entre les mains des contrats qui vous lient à vos parties prenantes, clients, fournisseurs…
Certaines clauses peuvent paraître obscures ou bien inintéressantes pour vous.
Et cependant, elles pourraient faire ou défaire le succès de votre projet.
Voici 3 clauses contractuelles à ne pas ignorer car elles sont étroitement liées et chacune joue un rôle déterminant dans la protection des parties.
Assurances
Pénalités
Responsabilité
Apprenez-en davantage sur ces clauses pour mieux négocier vos contrats de projet. Certaines peuvent limiter votre exposition au risque ou minimiser son impact s’il venait à se matérialiser.
Si vous vous retrouvez souvent à devoir repousser des histoires utilisateur d’un sprint au suivant, peut-être n’utilisez-vous pas les bonnes métriques ?
Flow Metrics and Why They Matter to Teams and Managers par Johanna Rothman
Je continue à travailler avec des gens qui ont du mal avec leur approche agile. Ils me disent que leur estimation relative ne fonctionne pas pour eux. Ils continuent de repousser des items, d’un sprint à l’autre. Ils ont repoussé certains items pendant six mois ou plus. Les gens se sentent démoralisés. Et les Scrum Masters ou les managers de projet agiles n’ont aucune idée de la façon de remédier à la situation.
C’est alors que je leur recommande d’utiliser les métriques de flux au lieu d’une de leurs mesures plus traditionnelles. Parce que leurs mesures actuelles n’aident pas.
Les métriques de flux sont l’unique « secret » qui peut améliorer l’agilité dans n’importe quelle approche. Ces métriques exposent les principes qui sous-tendent l’agilité. Lorsque les équipes mesurent ces 4 métriques, elles peuvent voir leur réalité et décider quoi faire pour créer un meilleur environnement. Et, comme pour la plupart des principes, il y a une petite différence dans la façon dont ils sont importants pour les équipes et les managers.
Tout d’abord, voyons quelles sont les métriques de flux.
4 Métriques de flux
WIP / Work In Progress, Travail en cours : Tout le travail qui est en cours : commencé et pas encore terminé.
Throughput, Débit : Nombre d’items de travail qu’une équipe/responsable peut effectuer par unité de temps.
Cycle Time, Temps de cycle : Le temps nécessaire pour libérer de la valeur, en tant que tendance.
Aging, Vieillissement : Depuis combien de temps un travail est en cours.
Bien que les métriques de flux soient indépendantes, elles créent des interactions et des dynamiques qui affectent le fonctionnement d’une équipe ou d’un manager. Commençons par une équipe.
Interaction entre les métriques de flux
Imaginez une équipe qui termine régulièrement un item de travail chaque semaine. C’est leur débit régulier. Maintenant, quelqu’un pense qu’il a besoin d’en faire « plus ». Peut-être que quelque chose a changé sur le marché ou que la direction n’est pas satisfaite du rendement de l’équipe. Ou peut-être qu’un concurrent gagne du terrain. Quoi qu’il en soit, l’organisation en veut « plus ».
Une personne bien intentionnée demande à l’équipe de commencer un item de plus cette semaine et de le terminer. Cela augmente le WIP de l’équipe. Cependant, à moins que l’équipe ne change quelque chose dans sa façon de travailler, elle n’augmente pas son débit juste parce qu’elle a commencé un item supplémentaire.
En fait, leur débit a diminué parce qu’ils travaillent sur deux éléments en même temps et qu’ils n’ont terminé aucun d’entre eux. Pire, leur temps de cycle augmente. Et maintenant, ils ont deux items de travail plus anciens, ce qui augmente le vieillissement de tous les items.
La demande de travail augmente, tout cela parce que l’équipe n’en a pas terminé « assez ».
C’est une boucle de rétroaction qui se renforce. Au fur et à mesure que l’encours augmente, le temps de cycle augmente. L’équipe a un débit plus faible, ce qui conduit à des items plus anciens. Tout cela augmente leurs travaux en cours.
Nous tournons en rond, créant un environnement de pire en pire pour l’équipe.
Si vous avez déjà vu une équipe « repousser » des histoires utilisateur d’un sprint à l’autre, vous avez vu cette dynamique. C’est pourquoi l’estimation relative et la vitesse ne sont pas utiles, mais la mesure du temps de cycle fonctionne.
La bonne nouvelle, c’est que l’équipe peut intervenir n’importe où dans ce cycle et apporter des améliorations.
Interventions d’équipe
Voici les questions que l’équipe peut poser :
Quelle est la seule et unique chose sur laquelle nous devrions travailler et terminer ? (Commencez par les travaux en cours.)
Quel âge a notre item le plus ancien ? Est-ce qu’il a encore de la valeur ? (Commencez par considérer le vieillissement.)
Que devrions-nous changer dans notre travail pour réduire notre temps de cycle ? (Concentrez-vous sur le temps de cycle.)
Comment pouvons-nous augmenter notre débit ? (Concentrez-vous sur le débit.)
J‘ai tendance à commencer par l’une ou l’autre des deux premières questions, car elles se concentrent sur une chose que l’équipe peut terminer. Lorsque l’équipe réduit son travail en cours à un seul élément, elle doit modifier sa façon de travailler.
Ensuite, plus le WIP est faible, plus le débit est élevé, plus le temps de cycle est faible et plus le nombre d’anciens éléments est réduit.
C’est la même boucle de rétroaction, mais d’une manière qui soutient l’équipe.
Est-ce que « un » item est toujours le bon nombre pour les travaux en cours ? Non, je recommande à l’équipe de commencer par diviser par deux le nombre de personnes dans l’équipe (pour déterminer le WIP optimal de l’équipe). Si vous avez un nombre impair de personnes, arrondissez en dessous. Donc, si vous avez cinq personnes, utilisez « deux » comme travail en cours maximal.
Mais votre équipe peut commencer par des changements au sein de l’équipe pour réduire le temps de cycle et augmenter le rendement. Vous pouvez commencer n’importe où car c’est une boucle de rétroaction.
Interventions du management
Les managers travaillent différemment. Les métriques ne changent pas, mais les interventions du management sont différentes.
Les métriques de flux interagissent de la même manière pour les managers que pour les équipes. Cependant, les managers ne produisent pas de fonctionnalités. Au lieu de cela, ils prennent des décisions. C’est pourquoi les idées de « Pourquoi minimiser le temps de décision de la direction/ Why Minimize Management Decision Time” sont si importantes.
Plus les managers ont de décisions non finalisées (vieillissement des décisions), plus ils ont de décisions en cours (leur WIP). Plus l’encours WIP d’un responsable est élevé, plus le temps de cycle est long et plus le débit est faible. Cela signifie que les gens ne savent pas quoi faire et décident par eux-mêmes. Les gens ne peuvent plus attendre une décision du management.
Les managers peuvent poser des questions légèrement différentes :
Dois-je prendre cette décision ou puis-je la déléguer à quelqu’un ou à une autre équipe ? (Cela réduit le WIP.)
Cette décision a-t-elle encore de la valeur ? (Réduire le vieillissement.)
Quelles décisions puis-je prendre aujourd’hui pour m’en débarrasser ? (Réduire le temps de cycle.)
De qui d’autre ai-je besoin pour prendre cette décision et comment pouvons-nous décider aujourd’hui ? (Augmenter le débit.)
Bien que les questions soient un peu différentes, les managers peuvent utiliser la boucle de rétroaction pour créer une boucle qui fonctionne pour eux, et non contre eux.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
Les métriques de flux peuvent guider de meilleures décisions
Lorsque les équipes et les responsables voient clairement leurs travaux en cours/WIP, leur temps de cycle, leur débit et leur vieillissement, ils peuvent décider de ce qu’ils souhaitent modifier.
Est-il temps de renforcer la collaboration ?
Commencez peut-être par la question de la valeur, comme dans « Quelle est la chose la plus précieuse que nous puissions terminer aujourd’hui ? »
Les métriques de flux sont importantes car elles permettent aux équipes et aux responsables de voir et de gérer leur façon de travailler.
Utilisez-les pour avoir un aperçu de l’endroit où vous pourriez choisir de modifier votre travail.
Cette lettre d’information aborde les sujets abordés dans les livres :
Bonjour, je vous ai bien sûr déjà parlé du célèbre Plan-Do-Check-Act* mais comment créer et suivre un indicateur pratique PDCA dans le suivi des actions de votre projet ?
Dans cet épisode de sa série « Tutoriel », Christian Hohmann précise l’utilité et l’utilisation de l’indicateur PDCA de le modèle de plan d’actions, basé sur le tableur Excel, qu’il avait présenté ici.
Après avoir revu cet épisode, voici le nouveau tutoriel sur la mise en place d’un indicateur PDCA dans votre fichier de suivi.
L’affichage automatique des symboles PDCA
L’indicateur PDCA
Filtrage sur le PDCA
Très simple, visuel et efficace ! Essayez-le et partagez vos retours.
Rappel de ce qu’est le « Plan Do Check Act », Cycle PDCA pour l’amélioration continue.
Relisez aussi l’article de Jean-Baptiste Jourdant : cultivez vos talents – Projet et qualité, de nombreux points communs !
Le Plan Do Check Act – Cycle PDCA est une méthode à 4 étapes fréquemment utilisée dans le processus d’amélioration continue. Chacun des quatre composants joue un rôle spécifique dans ce processus d’amélioration continue.
Plan – Préparer, Planifier
Do – Développer, réaliser, mettre en œuvre
Check – Contrôler, vérifier
Act (ou Adjust) – Agir, ajuster, réagir
partagez ce billet avec vos amis, collègues et relations professionnelles
Voici 7 des tendances les plus en vogue dans le domaine en pleine évolution du management de projet.
L’IA et l’automatisation dans le management de projet. L’intelligence artificielle (IA) et les technologies d’automatisation sont intégrées dans les outils de management de projet. Ceux-ci permettent de rationaliser les tâches de routine, d’améliorer la précision des prévisions de projet et d’améliorer l’efficacité globale.
Agilité dans les environnements non informatiques. Les principes de l’agilité, tels que le développement itératif et le retour d’information continu, vont au-delà du développement logiciel et sont adoptés dans des domaines tels que le marketing, les ressources humaines et la fabrication.
Management de projet hybride. De nombreuses organisations adoptent des approches de management de projet hybrides, qui combinent les pratiques traditionnelles en cascade et agiles. L’avantage est d’utiliser des approches appropriées pour différentes parties d’un projet afin d’obtenir les meilleurs résultats du projet.
Management de projet à distance. Avec l’essor du travail à distance, les managers de projet doivent adapter leurs stratégies pour gérer des équipes à distance dans différents endroits. Cela nécessite des outils de collaboration, des plateformes de communication virtuelles et des approches efficaces pour développer le travail d’équipe.
L’accent est mis sur l’intelligence émotionnelle. L’intelligence émotionnelle est aujourd’hui reconnue comme une compétence cruciale pour les managers de projet. Avec les parties prenantes, la capacité de comprendre et de gérer les émotions améliorera la communication, la collaboration et la réussite du projet.
Prise de décision basée sur les données. Les managers de projet tirent parti de l’analyse des données ainsi que des outils de management de projet pour prendre des décisions éclairées. En collectant et en analysant des données pertinentes, les équipes peuvent identifier les tendances, anticiper les problèmes potentiels et optimiser les processus pour de meilleurs résultats de projet.
Concentrez-vous sur le management du changement organisationnel. Les managers de projet qui réussissent utilisent les principes de management du changement organisationnel pour aider les équipes et les parties prenantes à s’adapter aux changements liés au projet. Cela comprend les stratégies de communication, l’engagement des parties prenantes et la lutte contre la résistance au changement.
Postez dans la section des commentaires pour voter pour votre tendance préférée !
L’UAT continuera-t-elle à être une pratique pertinente pour les équipes agiles et leurs parties prenantes qui cherchent à créer de meilleurs produits plus rapidement ?
Impact of User Acceptance Testing (UAT) phase on Organisation Agility par Sam Adesoga
Le test d’acceptation par l’utilisateur (User Acceptance Testing / UAT) est une pratique de développement de produits très populaire dans les méthodes traditionnelles de développement de produits. Ces méthodologies traditionnelles sont caractérisées par de longues phases de développement et de déploiement du produit dans un environnement UAT, suivies d’une longue période de test dans l’environnement UAT.
La question est de savoir si l’UAT continuera d’être une pratique pertinente pour les équipes agiles et leurs parties prenantes, en partant du principe que les organisations adoptent des méthodes de travail agiles pour être en mesure de créer de meilleurs produits plus rapidement. La phase d’UAT est une pratique qui est souvent mandatée par les cadres supérieurs au sein de l’organisation et parce que la phase d’UAT ne peut pas s’intégrer dans le Sprint (dans le cas des équipes Scrum), ces équipes contournent l’« obstacle » en modifiant la définition de Done pour leur produit afin d’exclure l’UAT. En d’autres termes, l’équipe Scrum a tendance à modifier son livrable de Sprint pour en faire un produit dont le développement est terminé mais qui n’a pas encore été testé par les utilisateurs et/ou les parties prenantes.
Pour le scénario décrit ci-dessus, quelle que soit la vitesse à laquelle l’équipe Scrum travaille pour amener ses éléments de travail à l’état de développement terminé, l’équipe Scrum crée effectivement un lot de travail qui n’est pas délivré en production avant un certain temps. La phase UAT peut durer de 4 semaines à 3 mois ; et nous pensons que la phase UAT ne rend pas service à tous les efforts visant à renforcer les capacités d’agilité de l’organisation.
Les approches agiles tels que Scrum aident les organisations et les équipes produit à gérer la complexité, et les implémentations de ces approches ne doivent pas introduire de complexité supplémentaire.
Voici quelques exemples de complexité supplémentaire introduite par une pratique distincte de l’UAT et question à se poser :
Comment les équipes corrigeront-elles les défauts détectés pendant la phase d’UAT ?
Cela affectera-t-il la capacité de l’équipe à se concentrer sur le travail de sprint ?
Les défauts seront-ils corrigés par une sous-équipe de développeurs ?
Comment les équipes fusionneront-elles l’incrément de la phase UAT et l’incrément des sprints ?
Chez Valuehut, nous aidons nos clients à intégrer toutes les formes de tests au sein du Sprint (y compris les tests d’acceptation par les utilisateurs) ; La promesse de Scrum est d’aider les équipes à fournir des produits utilisables et précieux à leurs utilisateurs le plus rapidement possible et en renforçant les capacités au sein de l’équipe pour effectuer des tests d’acceptation par les utilisateurs dans le cadre du Sprint. L’équipe a alors plus de chances de fournir un produit précieux et disponible à ses utilisateurs / parties prenantes dans chaque sprint.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
Il existe 3 modèles et approches associées que nous avons suivis pour aider les équipes Scrum à éliminer la phase d’UAT de leur méthodologie de livraison de produits.
#1 – Environnements de test qui ne représentent pas l’environnement de production.
Les équipes Scrum qui n’ont pas accès à un environnement de test qui est une représentation de l’environnement de production disposent généralement d’un environnement UAT, qui est partagé par de nombreuses équipes. La non-représentativité peut faire référence à la taille et à la capacité de l’environnement ou à un environnement qui n’est pas configuré correctement avec toutes les applications en amont et en aval.
Pour résoudre ces problèmes, l’équipe doit argumenter en permanence pour avoir un environnement qui représente l’environnement de production. Rendre transparentes pour la direction les implications en termes de coûts qui pourraient être des opportunités perdues en raison de délais de livraison allongés.
#2 – Cas de test et scénarios utilisateurs inconnus.
Souvent, les utilisateurs professionnels qui sont censés exécuter le test d’acceptation utilisateur ont créé un ensemble de scénarios et de cas de test qui n’ont pas été partagés avec les développeurs.
Dans ce cas, l’équipe Scrum devrait plaider pour que ces scénarios utilisateur soient partagés avec l’équipe Scrum en s’associant aux utilisateurs professionnels et en utilisant le coût de la reprise pour répondre à ces scénarios.
#3 – Indisponibilité des données de test dans l’environnement de test.
Dans cette situation, l’entreprise n’est généralement pas confortable avec l’idée de charger des données de test représentatives dans les environnements de test pour un certain nombre de raisons, telles qu’un environnement de test inadapté ou un problème de confidentialité des données.
Les développeurs doivent s’efforcer d’anonymiser les données et de créer des jeux de test qui permettent à l’équipe Scrum d’accéder de manière cohérente à des données de test représentatives.
Élimination de phase d’UAT ?
Il convient de noter que l’élimination de la phase d’UAT prend du temps et nécessite que les équipes Produit s’associent aux leaders de l’entreprise sur une longue période de temps, en effectuant de petites expériences à chaque fois jusqu’à ce que la phase d’UAT soit rendue redondante. La seule façon de rendre la phase d’UAT redondante est de rassembler suffisamment de preuves empiriques qu’aucun défaut n’est trouvé dans cette phase d’UAT ; Cela permet d’établir la confiance avec les parties prenantes au fil du temps, et l’équipe Scrum doit fournir aux parties prenantes la preuve des tests exécutés dans chaque sprint.
La capacité d’agilité organisationnelle aide les organisations à être efficaces (en créant les bons produits, par exemple un produit que les clients aiment utiliser) et efficientes (en construisant les bons produits, par exemple en réduisant les délais de mise sur le marché) ; Par conséquent :
Les organisations qui veulent être compétitives dans un monde complexe doivent repenser des pratiques telles que la phase d’acceptation par les utilisateurs, qui ralentissent le temps total nécessaire pour mettre de nouveaux produits ou fonctionnalités entre les mains de leurs clients.
Sam Adesoga, Principal Coach and Lead Trainer
Praticien agile et agnostique ainsi qu’un formateur professionnel Scrum avec Scrum.org
L’expérience professionnelle de Sam comprend Développeur, Développeur de logiciels, Test and Release Manager, Scrum Master et récemment coach Agile d’entreprise
Sam utilise des approches agiles comme fondation, et s’intéresse à aider les individus, les équipes et l’ensemble des organisations à développer l’état d’esprit et la culture nécessaires pour réussir dans un monde VUCA.
Nombre total d’années d’expérience dans le développement et la livraison de produits à l’aide de cadres de travail agiles – 17 ans.
partagez ce billet avec vos amis, collègues et relations professionnelles
Le rôle des projets et du management de projet dans la directive de l’Union Européenne sur les rapports d’entreprise en matière de développement durable #CSRD et la directive sur le devoir de diligence des entreprises en matière de développement durable, #CSDDD : un Livre blanc.
Green Project Management a annoncé la publication de son dernier livre blanc :
Découvrez les différences : Gagnez une compréhension claire de la CSRD et de la CSDDD, et de leur impact sur vos projets et votre entreprise.
Découvrez le rôle essentiel du management de projet : Comprenez comment les managers de projet jouent un rôle essentiel dans le paysage complexe de la conformité en matière de développement durable.
Perspectives pratiques : Bénéficiez d’exemples concrets et d’une cartographie complète de la norme GPM P5 avec les exigences CSRD et CSDDD.
Outils d’amélioration : Découvrez comment les projets peuvent être utilisés comme instruments de divulgation et agents de responsabilisation pour l’amélioration continue.
Agissez en faveur du développement durable
Ce livre blanc est une ressource indispensable pour les professionnels qui cherchent à aligner leurs projets sur les dernières directives de l’UE et à apporter des changements significatifs.
Que vous soyez managers de projet, responsables du développement durable ou cadre sup, les informations contenues dans ce document vous aideront à orienter vos projets vers un avenir plus durable et responsable.
Nous sommes au pic du cycle de battage médiatique sur IA (Intelligence Artificielle) /LLM* (Large language models)/Chatbot/IA générative comme ChatGPT.
Toutes les publications du monde du business en délirent. Les histoires vont de « 20 façons d’utiliser ChatGPT pour faciliter votre travail » à « voici comment l’IA mettra fin à la civilisation telle que nous la connaissons ». Un quart des articles parus dans la section économique du New York Times du 7 novembre étaient liés à l’IA. Chaque conférence client et marketing commence par des questions sur l’IA. Les valorisations exorbitantes des entreprises d’IA sont la brillante exception à un marché baissier du capital-risque.
Cela créée une extrême urgence à intégrer des produits ou des fonctionnalités d’Intelligence Artificielle dans vos feuilles de route, qu’ils aient ou non une grande valeur pour nos utilisateurs finaux. Au cours des 6 derniers mois, bon nombre de discussions avec les chefs de produit ont porté sur la façon d’appliquer les principes fondamentaux d’un bon produit à l’IA alors qu’une grande partie de la conversation sur ce sujet au sens large est superficielle ou techniquement suspecte ou réduit tout à des applications d’IA génératives.
Pour mettre les choses en perspective, l’IA est en incubation depuis longtemps, ce qui est typique des histoires technologiques en vogue actuellement. En 1980, j’ai eu une mission de CompSci pour construire un chatbot de style ELIZA qui imiterait un peu un psychiatre, en s’inspirant de l’ELIZA des années 1960 que certains utilisateurs jugeaient intelligent. Et nous avons vu d’autres cycles de battage médiatique aller et venir : la blockchain, la télévision 3D, les modèles commerciaux viables pour les espaces de coworking, les jeux mobiles de style Pokemon-Go, MoviePass, l’économie du partage, les voitures autonomes qui tuent parfois les piétons qui marchent à vélo.
À chaque fois, enthousiastes et opposants se sont accumulés. Au fil du temps, nous avons trié ceux qui avaient une valeur durable et ceux qui n’étaient que de la pensée magique ou des présentations pour les investisseurs. Après tout, toute technologie suffisamment avancée est indiscernable de la magie.
Donc, en partant des principes de base, je dirais que vous avez besoin de quelques approches différentes en fonction de ce que vous essayez réellement d’accomplir en ajoutant l’IA. Être explicite sur votre objectif vous aide à définir le succès et à estimer l’effort.
#1 – “AI-Washing” / « Lavage par l’IA »
Le lavage par l’IA (voir la définition de l’écoblanchiment), c’est si vous annoncez et expédiez rapidement quelque chose (n’importe quoi !) qui peut être étiqueté IA ou apprentissage automatique ou LLM-ish ou génératif. Livrer quelque chose montre que vous n’êtes pas endormi ; donne à vos dirigeants quelque chose d’IA à discuter avec les clients ; et satisfait les investisseurs moins avisés qui craignent que vous ne manquiez des valorisations exorbitantes. L’espoir est que vous aurez une couverture médiatique positive, mais peu d’utilisateurs finaux sérieux.
Un danger : Vous vous heurtez au problème du MVP. Peu importe à quel point vous [produit/ingénierie] expliquez clairement qu’il s’agit d’une fonctionnalité générique légère, peu fonctionnelle, non rentable, à peine testée, rapide et non finie, à ne pas prendre trop au sérieux, destinée aux messages marketing plutôt qu’aux cas d’utilisation sensibles… Votre public le traitera comme une production complète et finie dès qu’elle sera livrée. Toutes les limitations et avertissements seront oubliés. (« Regardez l’attention que nous avons reçue de l’industrie ! 8000 téléchargements, 2000 utilisateurs d’essai ! Présentons-le dans chaque communication avec les prospects et plaçons le tout en haut de notre site Web ! Pouvons-nous le monnayer ?)
Ensuite, lorsqu’un grand groupe d’utilisateurs réels essaie avec enthousiasme votre « assistant IA pour aider à rédiger de meilleurs appels d’offres » et découvre qu’il ne fait que 2 mm de profondeur, vous êtes inondé de plaintes et de demandes d’amélioration. Votre chatbot de support client alimenté par l’IA est plus rapide à recommander la mauvaise solution que votre version non IA. Et les publics soucieux de la technique et de la protection de la vie privée exigent des explications atrocement détaillées sur la façon dont cela fonctionne exactement et sur ce qu’il y a dans le corps. (RGPD ? Renseignements personnels ? D’où proviennent vos données de tests…) Cela peut rapidement passer d’une victoire en matière de relations publiques à un échec très visible de produit public.
#2 – Appliquer des outils d’IA généraux (génériques) pour réduire les coûts internes
Nos imaginations se déchaînent avec les façons dont l’IA pourrait simplifier notre travail ou réduire l’ennui. Les employés nous inondent de suggestions d’augmentation automatisée du personnel, d’auto-configuration de l’IA ou d’informations automatisées sur le taux de désabonnement des clients.
L’enthousiasme pour l’IA finira par s’estomper, de sorte que ces projets devront faire leurs preuves sur le plan économique auprès de vrais utilisateurs finaux. L’outil X réduit-il réellement la charge de travail, accélère-t-il les livraisons ou améliore-t-il suffisamment les métriques opérationnelles pour justifier le coût continu de la maintenance, de l’amélioration, du nettoyage des données, des scientifiques des données et du processeur ?
Étant donné que les LLM sont construits sur les statistiques et fourniront toujours de mauvaises réponses, prenons-nous en compte l’effort humain pour détecter les hallucinations et examiner chaque recommandation ?
À un moment donné, le retour sur investissement réel déterminera le financement continu.
Il est important de faire la différence ici entre essayer des projets d’IA internes pour apprendre les outils et ajuster nos attentes, et « le conseil d’administration a reçu la promesse que nous réduirons de plus de 20% les coûts de la logistique grâce à une sélection d’itinéraires d’expédition IA 5 fois meilleure d’ici le 2T24, et nous devons donc faire en sorte que cela fonctionne. »
À mon humble avis, la plupart des projets internes seront instructifs mais ne seront pas rentables.
#3 – Ajout de fonctionnalités d’IA à faible risque à nos produits commerciaux apportant une valeur réelle pour l’utilisateur final
Une fois que le bruit aura disparu, nos utilisateurs payants continueront à utiliser les fonctionnalités qui comptent pour eux. Donc, si nous voulons ajouter de la valeur au produit basé sur l’ IA (par opposition AI-Washing au niveau unitaire), nous devons valider que les nouvelles fonctionnalités résoudront mieux les problèmes réels des clients que le code traditionnel. Et qu’elles sont techniquement faisables. Et que l’investissement est approprié. L’intuition ne suffit pas.
Cela suggère de commencer par les problèmes et les métriques de l’utilisateur :
« Combien cela vaudrait-il pour vous si nous pouvions traiter automatiquement 70 % des transactions financières et signaler le reste pour un traitement manuel ? Ou bien 90% ? ou encore 99.95% ? »
« Quelle est la part des interactions de chat des consommateurs qui permet aux utilisateurs d’obtenir le bon résultat aujourd’hui ? En combien d’étapes ? Quel est le coût en termes de réputation de marque et de frustration des utilisateurs en cas de mauvaises réponses ou de mauvaises recommandations ? Comment repérez-vous les erreurs et comment améliorez-vous le système ? À quel point notre produit devrait-il être meilleur pour justifier un investissement annuel de 70 000 $ ? »
Remarquez que ceci est très différent d’hypothèses ou de projections de l’esprit pleines d’espoir. Nous avons besoin d’une découverte honnête et approfondie et d’une science des données robuste. Supposons que le cycle du battage médiatique s’effondre et que nous devions expliquer notre investissement aux personnes qui s’intéressent encore à FTX. (Mauvaise alternative : « ChatGPT, s’il vous plaît, dites-moi ce que mes utilisateurs veulent vraiment et avec quelle facilité l’IA générative peut résoudre ces problèmes. »)
#4 – Créer un avantage stratégique majeur pour nos produits ou notre entreprise grâce à des modèles uniques, des ensembles de données propriétaires et une science approfondie de l’IA
Nous « savons » que l’IA nous permettra de devancer la concurrence, et nous « savons » que notre ensemble de données est suffisamment grand/assez propre/légitimement acquis/suffisamment cohérent dans le temps pour que nous puissions l’utiliser pour prédire l’avenir. Mais nos intuitions sont probablement fausses.
Quelques questions de qualification :
Possédons-nous d’un énorme ensemble de données exclusives spécifiques à ce problème (par exemple, des millions de demandes de prêt hypothécaire pour un accélérateur d’approbation de prêt hypothécaire ; 100 millions de scans de sécurité pour un détecteur d’intrusion ; des milliards de visages pour une application de reconnaissance faciale) ? Sinon, nos concurrents peuvent utiliser le même ensemble de données publiques pour saper notre avantage. Ou avons-nous un avantage de premier implémenteur avec des données publiques qui créent des enjeux essentiels pour les concurrents ?
Sommes-nous propriétaires des données ou avons-nous l’autorisation de les utiliser ? « Je l’ai trouvé sur Google » ne suffit plus comme réponse.
Avons-nous effectué des tests de prédictibilité statistique, de sorte que nous pensons qu’un modèle serait (pourrait être) plus précis que les humains ou les applications codées de manière conventionnelle ? Avons-nous conservé la moitié de notre ensemble de données à l’écart de notre modèle à des fins de validation et de test ?
Quel est l’inconvénient ou la responsabilité si (quand) notre application se trompe, fait des déductions erronées, blesse des gens ou leur cause des ennuis juridiques ? Comment le saurons-nous ? Y aura-t-il suffisamment d’inspections humaines permanentes pour repérer les problèmes ?
Au fur et à mesure que les flux de données et les contenus changent, allons-nous le remarquer ? À quelle fréquence allons-nous reconstruire et revalider nos modèles ? Que va-t-il se passer au fil du temps, une fois que nous serons en production ?
Indice : il s’agit probablement d’une initiative importante, coûteuse et sans fin. Si votre entreprise n’a pas l’intention de dépenser des millions pour continuer à alimenter et à tester à perpétuité une application d’IA stratégique, elle dépérira et échouera. Le financement ponctuel de projet a encore moins de sens pour l’IA que pour le développement d’applications conventionnelles.
Qu’en retenir ?
Nous ne pouvons pas ignorer l’IA ni la considérer comme un pur battage médiatique. Mais comme pour toute technologie, nous devons garder à l’esprit nos objectifs et nos résultats avant de décider qu’un outil spécifique est la réponse. Le lavage par l’IA ou AI-Washing est acceptable si nous sommes clairs à 150 % que nous le faisons (et pourquoi).
* C’est quoi un LLM en IA ?
Un Large Language Model (LLM) est un algorithme de Deep Learning qui peut exécuter un éventail de tâches de traitement du langage naturel (NLP). Les grands modèles de langage utilisent des modèles de transformateur et sont entraînés sur des ensembles de données volumineux.
Deep Learning: L’apprentissage profond est un procédé d’apprentissage automatique utilisant des réseaux de neurones possédants plusieurs couches de neurones cachées. Ces algorithmes possédant de très nombreux paramètres, ils demandent un nombre très important de données afin d’être entraînés.
partagez ce billet avec vos amis, collègues et relations professionnelles
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 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
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
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.
The Spotify Model of Scaling – Spotify Doesn’t Use It, Neither Should You par Mark Levison
Le « modèle Spotify » n’est probablement pas un modèle et n’est absolument pas ce qui est actuellement pratiqué chez Spotify aujourd’hui. (Certains suggèrent que cela n’a jamais été le cas.)
L’image ci-dessous a été rendue célèbre dans des vidéos d’Henrik Kniberg, où il explique comment le travail était organisé en escouades, tribus et guildes (Squads, Tribes, and Guilds).
Spotify Engineering Culture – Part 1&2 (aka the « Spotify Model »)
Beaucoup de gens voient la structure et essaient de l’imiter dans leur organisation. Pire encore, beaucoup tentent d’obtenir le bénéfice supposé en renommant les structures organisationnelles existantes avec ces nouvelles étiquettes.
La structure n’est pas le plus important. La culture dévorera n’importe quelle structure. (Indice : c’est pourquoi le fait de renommer vos équipes en « Escouades » et d’appeler les responsables de service « Chefs de chapitre » n’a jamais aidé.)
Cela dit, si je ne résume pas ici ces étiquettes, vous irez les chercher ailleurs de toute façon, alors c’est parti…
Squad : En fait une équipe Scrum avec un nouveau nom. Lorsque l’article original a été publié, chaque escouade possédait une petite partie de l’interface utilisateur ou du comportement du système. Ils possèdent cette partie du produit et peuvent mener des expériences sans dépendre d’autres équipes. Les personnes qui sont familières avec LeSS remarqueront que les escouades sont des équipes fonctionnelles.
Tribu : Un ensemble d’escouades qui travaillent dans un domaine connexe. Elle est conçue pour avoir une collaboration optimale entre les escouades avec peu de dépendances avec d’autres tribus. Les tribus sont limitées à 100 personnes afin de minimiser « les règles restrictives, la bureaucratie, la politique, les couches supplémentaires de management et autres gaspillages ».
Chapitre : Personnes d’un même domaine de compétence au sein d’une tribu, par exemple les testeurs ou les développeurs qui travaillent avec une certaine technologie. Les chapitres se réunissent régulièrement pour discuter des problèmes et partager les apprentissages dans leur domaine.
Guilde : une communauté d’intérêts plus large. Les guildes incluent généralement les chapitres, mais toute personne intéressée par un sujet peut rejoindre une guilde. Lorsque l’article original a été écrit, ils avaient des guildes pour la technologie Web et la guilde des coachs agiles.
Structurellement, il s’agit d’une façon parfaitement saine d’organiser les équipes. L’obstacle est si vous changez les étiquettes sans les changements culturel et de mentalité qui vont avec. Et la formation seule ne réalisera pas ce changement.
S’agit-il simplement d’un autre modèle matriciel, le genre de chose que les coachs agiles déconstruisent depuis des années ?
Oui, c’est le cas, mais c’est un autre type de matrice. Dans d’autres modèles matriciels, la relation horizontale est la relation principale. Par exemple, un développeur relève d’un responsable de développement ; un testeur à un manager des tests, etc. L’affiliation avec l’équipe ou les équipes avec lesquelles ils travaillent est plus lâche.
Spotify a inversé cette tendance. La relation principale est celle de membre d’une équipe stable et interfonctionnelle.
Le responsable du chapitre (ce n’est pas un bon choix de nom) est un coach, qui se concentre sur les compétences et l’excellence technique. En théorie, c’est génial. Dans la pratique, c’est le premier endroit où de nombreuses organisations commettent une erreur. Les responsables de votre chapitre ne devraient pas être d’anciens managers qui ont obtenu un nouveau titre de poste.
Il y a une myriade d’autres erreurs que les gens commettent en lisant un livre blanc et en regardant une vidéo. La liste serait plus longue que l’article original. Ce problème est si populaire qu’il a même son propre mème :
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. De plus, toutes les tentatives de documentation d’une culture sont des simplifications qui manquent des détails importants.
Au lieu de copier le modèle Spotify ou le modèle d’une autre entreprise au hasard (par exemple, FitBit, John Deere), développez votre propre modèle Agile. C’est la seule voie à long terme vers le succès.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
Concentrez-vous sur les choses que Spotify avait dans son moteur
Apporter de la valeur. Toutes les améliorations apportées au système doivent être testées en se posant les questions suivantes : Cette amélioration ou cette expérience nous aide-t-elle à créer de la valeur ?
Amener de la valeur au produit. Ceci nécessite de mener des expériences et de voir ce qui fonctionne pour les utilisateurs finaux réels.
Autonomie plutôt qu’ordres et contrôle. Sans autonomie, il n’y a pas d’apprentissage, d’amélioration, d’innovation ni de capacité à s’adapter à des circonstances changeantes.
Alignement. Au lieu de dire aux gens ce qu’ils doivent faire pour les fonctionnalités et l’architecture du produit, concentrez-vous sur le fait d’amener les équipes à s’aligner sur un objectif produit commun. Envisagez d’avoir plusieurs équipes travaillant à partir d’un objectif produit commun.
Équipes interfonctionnelles orientées produit (alias Feature Teams). Plutôt que de constituer des équipes en fonction de leur souche fonctionnelle (par exemple, base de données, logique métier, interface utilisateur).
Une culture d’ingénierie qui met l’accent sur la qualité et la simplicité. Créez un pipeline de livraison continue qui permet aux équipes de créer de la valeur indépendamment les unes des autres. Au lieu d’un pipeline qui nécessite d’attendre que l’ équipe DevOps le déploie pour eux. Astuce : Dans de nombreuses organisations, DevOps est une équipe en aval de l’équipe de développement de fonctionnalité, qui déploie l’application. Il s’agit d’un anti-modèle bien connu.
Sécurité psychologique. L’article original l’appelait « expérimentation conviviale ». (experiment friendly). L’élément clé de l’expérimentation conviviale est la création d’un environnement où nous pouvons reconnaître la valeur de la prise de risques et l’apprentissage du processus. Le nom à la mode pour cela est « sécurité psychologique ».
L’amélioration continue en tant que caractéristique du système. Les équipes n’ont jamais fini de s’améliorer. Nous devons créer des cultures qui favorisent cet état d’esprit.
Le moral. Appelé à l’origine bonheur, il s’agit de la volonté et de la persévérance des membres de l’équipe à travailler pour le bien commun.
Voici 6 choses critiques à inclure dans votre charte.
DantotsuPM.com 