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.
La réussite de tout projet nécessite une création de valeur pour les parties prenantes et un retour positif réel sur les ressources investies dans la réalisation du projet. N’oubliez pas que les conditions macroéconomiques peuvent impacter fortement votre projet, et parfois en empêcher le démarrage…
La réussite de tout projet nécessite une création de valeur pour les parties prenantes et un retour positif réel sur les ressources investies dans la réalisation du projet. Cependant, souvent, les managers de projet doivent naviguer dans les subtilités de l’analyse financière pour prévoir les flux de trésorerie futurs et prédire la valeur intangible créée par le projet, oubliant parfois d’évaluer comment les conditions macroéconomiques peuvent influencer ces variables financières, et comment cela se traduit par des variations dans la valeur ajoutée du projet.
Indicateurs clés
Une première mesure clé pour évaluer s’il est judicieux d’entreprendre un projet est de savoir si les coûts des ressources investies sont inférieurs au coût d’opportunité de l’investissement de ces ressources ailleurs. Dans le jargon économique, le coût d’opportunité est l’utilisation alternative des ressources la plus valorisée à laquelle le chef de projet doit renoncer pour diriger ces ressources vers le projet. Par exemple, supposons que le chef de projet ait l’intention de développer un projet immobilier dans le centre de Paris, en France, et que le coût total du projet s’élève à près de 700 millions d’euros. Le coût d’opportunité de cet investissement sera la perte d’intérêts ou de rendement si ces ressources auraient été investies dans un certificat de dépôt, une obligation, les marchés boursiers ou d’autres instruments financiers. En supposant un rendement boursier nominal normalisé de 10 % (le rendement moyen à long terme du S&P 500 au cours du siècle dernier), si le projet ne génère pas une valeur intangible ou un rendement des flux de trésorerie supérieur à 10 %, alors cela ne vaut pas la peine d’entreprendre le projet, mais plutôt d’investir ces ressources sur le marché boursier qui peut en fait être un autre « projet » financier.
L’inflation est un deuxième indicateur d’évaluation qui est souvent négligé dans l’évaluation macrofinancière. Une définition intéressante est qu’elle mesure le taux auquel la monnaie perd du pouvoir d’achat sur une période donnée, généralement une année. Par exemple, considérez que les parties prenantes demandent au chef de projet de reculer la date de début de notre projet immobilier de 6 mois en raison de grèves des employés, de tensions politiques et d’autres risques incontrôlables. Cette décision, bien qu’elle paraisse prudente, entraîne un coût monétaire non réalisé, la perte de pouvoir d’achat pour avoir l’argent qui dort sur un compte bancaire en attendant le démarrage du projet. Dans ce cas, en supposant l’objectif d’inflation annuelle de 2 % de la Banque centrale européenne (BCE) pour la zone euro, cela coûtera (pour le projet précédemment cité) à l’entreprise près de 7 millions d’euros (ce qui équivaut à 2 %/12 * 6 * 700 millions d’euros) de pouvoir d’achat perdu au cours de ces mois.
Une troisième variable macroéconomique assez volatile à évaluer et à prévoir est le taux de change. Celui-ci est particulièrement pertinent lorsqu’il s’agit de projets internationaux impliquant différentes juridictions et différentes devises d’un pays à l’autre. Bien que l’exposition soit limitée au montant des ressources investies dans le projet, plus l’investissement est élevé, plus l’exposition au risque de fluctuation du taux de change du projet est élevée. En particulier, si le projet est entrepris dans une économie de marché en développement ou émergente. Alors que les fluctuations des taux de change entre le dollar et l’euro peuvent être relativement stables sur une période donnée, une différence de taux de change minime dans les projets d’investissement à grande échelle peut être très dommageable pour ses finances. Considérons à nouveau notre projet immobilier de 700 millions d’euros à Paris, au moment de la rédaction de cet article, le taux de change du dollar américain par rapport à l’euro était de 0,932 USD/EUR alors qu’il y a un an il était de 1,027, ce qui indique une variation du taux de change de -9,16%, ceci signifie que nous avons besoin de moins de dollars pour acheter un euro et que l’euro s’est déprécié. Si nous avions vendu certaines unités de notre projet immobilier en dollars américains, nous aurions directement gagné avec l’appréciation du dollar à hauteur de près de 9% sans tenir compte des coûts de transaction.
Les taux d’intérêt constituent un quatrième indicateur indispensable. Celui-ci peut avoir et a souvent des effets néfastes sur les finances du projet via le risque de taux d’intérêt. Au moment de la rédaction de cet article, les hausses des taux directeurs de la BCE pour juguler l’inflation de l’euro ont influencé la hausse des taux hypothécaires à près de 5,0 % en France, des niveaux jamais vus depuis 2012. Tout ménage ou toute entreprise qui envisage de contracter un prêt hypothécaire à taux fixe dans les conditions financières actuelles peut être exposé à de graves difficultés financières pour s’acquitter de ses obligations financières, surtout s’il s’agit d’une dette immobilisée à taux d’intérêt élevé. Dans le même ordre d’idée, le développement du projet nécessitera un rendement réel ou une valeur intangible plus élevée pour que les parties prenantes entreprennent l’investissement. C’est l’une des raisons pour lesquelles la hausse des taux d’intérêt est corrélée à une baisse de l’activité économique réelle à moyen terme, ce qui nous amène à notre cinquième facteur.
La croissance économique , c’est-à-dire la variation réelle du produit intérieur brut, est notre cinquième mesure la plus importante. Si l’on s’attend à ce que l’économie se contracte et que les entreprises et les ménages réduisent leur consommation et leurs investissements, les difficultés à mener à bien tout projet pourraient augmenter de façon exponentielle. Prenons par exemple les récentes projections du Fonds monétaire international dans les Perspectives de l’économie mondiale pour la zone euro en octobre, qui prévoient une croissance de 3,3 % en 2022 à 0,66 % et 1,23 % en 2023 et 2024, respectivement. Dans ces conditions moroses, il n’est pas rare que de nombreux projets soient arrêtés et que les investissements soient mis en pause, car les perspectives économiques ne sont pas favorables, malgré la lumière au bout du tunnel avec une trajectoire de reprise l’année prochaine. C’est l’une des raisons pour lesquelles le seuil de rentabilité (break-even point) de certains projets pour les petites entreprises est de 2 à 3 ans pour percevoir certains avantages.
Mesures visant à atténuer les incertitudes
Bien que l’évaluation de ces variables semble une tâche ardue pour les professionnels non économistes et non financiers, il existe de nombreuses stratégies simples pour atténuer les risques et l’incertitude. Une première approche pour traiter le coût d’opportunité consiste à se demander si les ressources seraient mieux investies dans un instrument financier tel qu’un certificat de dépôt, une obligation ou le marché boursier. Peut-être dans une entreprise particulière plutôt que d’entreprendre un nouveau projet à partir de zéro. Les managers de projet devraient également envisager d’obtenir un rendement nominal d’au moins 10 % sur le produit ou la valeur intangible créée par le projet comme ligne directrice pour justifier les ressources investies.
Pour atténuer l’inflation, les liquidités inutilisées sur les comptes bancaires devraient être investies dans des certificats de dépôts ou des titres d’État protégés contre l’inflation, ce qui peut réduire le risque de défaut et protéger contre la hausse des prix. Assurer la protection des taux d’intérêt contre les mouvements défavorables peut être compliqué et nécessite souvent l’embauche de conseillers financiers et de consultants. Cependant, une règle empirique simple pour les projets nécessitant une dette est d’obtenir un prêt à taux fixe et de prolonger l’horizon de remboursement à long terme afin d’obtenir une mise de fonds moins élevée et des mensualités moins élevées.
L’obtention d’un taux de change particulier peut être moins difficile, car ce type de couverture est normalement offert par les banques traditionnelles et peut être résolu en utilisant un taux à terme prédéterminé pour échanger des devises. Cette variable semble moins susceptible d’affecter la plupart des projets réalisés en monnaie nationale, à moins que le projet ne nécessite des biens, des services et des marchandises de l’étranger, auquel cas les chefs de projet devront tenir compte de la façon dont les fluctuations des taux de change peuvent conditionner la réussite du projet à chaque fois.
Les taux d’intérêt varient au fil du temps, mais ces variations peuvent être prédites en surveillant les décisions de politique monétaire de la plupart des banques centrales. Pour se prémunir contre les fluctuations des taux d’intérêt, les conseillers financiers et les chefs de projet peuvent obtenir des lignes de crédit auprès d’intermédiaires financiers et se verrouiller dans un instrument financier à taux fixe afin d’éviter les mauvaises surprises dans les mouvements des taux d’intérêt.
En termes de croissance économique, il est pratiquement très difficile de se prémunir contre un ralentissement du PIB ou une baisse des perspectives économiques, mais une voie à suivre consiste à s’engager dans des projets qui sont entrepris dans des secteurs clés, avec un avantage concurrentiel durable, faisant face à une concurrence plus faible et généralement couverts par la réglementation gouvernementale et à l’abri d’impôts plus élevés. Le taux d’imposition est un facteur qu’en raison de la restriction de temps, nous n’abordons pas en détail dans cet article, mais il vaut la peine de l’examiner brièvement. Éviter les projets et les activités commerciales fortement taxés est une pratique de bon sens que nous devons toujours garder à l’esprit.
N’oubliez pas les perspectives
Les prévisions sont d’une importance cruciale dans l’achèvement de tout projet, il existe de nombreuses variables macrofinancières disponibles gratuitement auprès d’organisations internationales et d’agences gouvernementales nationales, telles que le Fonds monétaire international, la Banque centrale européenne, la Banque mondiale, l’Organisation de coopération et de développement économiques (OCDE), entre autres. Bien que le sujet de cet article ne soit pas de prédire l’avenir, mais d’esquisser une carte pour vous permettre de savoir si certains événements imprévisibles lors de la gestion d’un projet, certaines prévisions pour 2024 sont les suivantes pour la zone euro : la croissance du PIB devrait être de 1,2 %, l’inflation de près de 3 %, le taux d’intérêt de près de 5 % et le taux de change du dollar américain à l’euro peut varier entre 0,90 $ et 1,0 $.
L’évaluation de l’opportunité d’entreprendre ou non un projet peut dépendre de l’évolution de ces paramètres clés dans un avenir proche, mais quelle que soit la décision que vous prenez, ne négligez pas d’atteindre un rendement nominal d’au moins 10 % sur la valeur monétaire ou la valeur incorporelle équivalente à ce montant.
Osvaldo Lagares
Osvaldo Lagares est professeur d’économie à la Pontificia Universidad Católica Madre y Maestra et consultant économique à la Banque centrale de la République Dominicaine. Il est titulaire d’un doctorat en économie de l’Université de York et est le rédacteur en chef du Rapport sur la stabilité financière de la République Dominicaine.
Bibliographie
Carpenter (2023). Mortgage rates rise in France to levels not seen for more than a decade [online]. Monacolife.
ECB (2023). Monetary Policy Decisions [online]. European Central Bank.
International Monetary Fund. 2023. World Economic Outlook: Navigating Global Divergences. Washington, DC. October.
Satista (2023. Monthly average interest rate on new mortgage loans in France from April 2012 to May 2023, by mortgage term [online]. Statista.
partagez ce billet avec vos amis, collègues et relations professionnelles
Il n’y a pas de limite à l’utilisation que vous pouvez faire des jalons dans vos projets. Ne vous limitez donc pas aux livrables techniques et incluez des jalons pour tous les événements qui sont significatifs pour l’entreprise : Finalisation de processus, tests utilisateurs, pilotes…
Les managers de projet montrent généralement les progrès avec des jalons qui représentent l’achèvement de livrables importants. Mais cela ne fait qu’effleurer la surface de ce que les jalons peuvent visualiser en matière de progression de votre projet.
Voici 5 autres façons de mettre en évidence les progrès réalisés à l’aide de jalons.
#1 – Points de progression sur la chronologie.
Quels sont les jalons auxquels vous allez livrer et nourrir une attente positive ?
En particulier pour les projets plus longs, vous pouvez créer des jalons pour indiquer qu’un quart, la moitié et les trois quarts des tâches de votre échéancier sont terminés.
C’est un excellent moyen de visualiser les progrès à haut niveau de votre échéancier.
#2 – Risques traités.
Un risque majeur appartient-il dorénavant au passé ?
Les risques rendent les parties prenantes nerveuses. Les risques traités sont des éventualités à haut risque qui ont été résolues, soit grâce à des mesures d’atténuation réussies, soit parce que le risque ne s’est pas concrétisé. Créez des jalons pour identifier ces événements positifs dans votre échéancier. En plus d’ajouter ces risques traités à votre suivi des jalons, assurez-vous aussi de mettre à jour le niveau de risque global du projet.
#3 – Réponses positives des parties prenantes aux sondages de satisfaction.
Une façon de mesurer le succès de votre projet est de sonder les parties prenantes sur leur satisfaction à son égard. En fonction des événements entourant le projet, la satisfaction des parties prenantes peut diminuer, en particulier au début du projet avant qu’elles ne voient des résultats. Sondez périodiquement vos parties prenantes. Ensuite, créez un jalon lorsque vous atteignez un niveau prédéterminé de satisfaction des parties prenantes.
#4 – Éléments importants sur le chemin critique qui ne sont pas des livrables.
Tous les éléments du chemin critique ne font pas référence à des livrables. Les éléments importants du chemin critique peuvent inclure des points de rencontre où plusieurs chemins dans l’échéancier du projet se rejoignent comme l’adjonction de membres critiques au projet ou une décision notable d’un organisme de réglementation. Ajoutez des jalons pour afficher ces éléments dans votre planning.
#5 – Dépendances externes.
L’obtention d’autorisations et de certifications mérite d’être notée. La conclusion de négociations contractuelles et autres tâches impliquant des entités externes peuvent être des indices de progrès.
Utilisez les jalons du projet pour les identifier et les suivre.
Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes
De nombreux projets techniques utilisent des jalons uniquement pour indiquer l’achèvement des tâches techniques. Pour vous assurer que vos rapports d’avancement sont utiles, incluez des jalons pour tous les événements qui sont significatifs pour l’entreprise, tels que les finalisations de processus ou les résultats positifs des tests des utilisateurs.
Il n’y a vraiment pas de limite à l’utilisation que vous pouvez faire des jalons. Quels autres événements et réalisations soulignez-vous avec des jalons ?
« Préparez le succès de votre projet numérique » par Michaël Tartar
Michaël Tartar
En tant que chef de projet informatique, vous disposez d’un arsenal de méthodologies et d’outils.
Votre objectif est de livrer un composant logiciel répondant aux attentes de votre client (interne comme externe) avec
un coût maîtrisé,
un délai convenu et
des ressources définies
et de qualité !
En vous concentrant sur ces 3 aspects, vous avez le sentiment de bien faire votre travail.
Vous avez raison… …partiellement, car votre projet est en réalité le préambule d’une nouvelle étape : L’expérience utilisateur de ce que vous avez créé.
Avant de vous lancer, posez-vous les questions qui surgiront lorsque les utilisateurs s’empareront enfin des livrables du projet logiciel.
Vont-ils adopter ce nouvel outil et les changements de processus qu’il introduit ?
Les modifications qu’ils ne manqueront pas de demander seront-ils réalisés aussi rapidement que nécessaire ?
Les données collectées et créées seront-elles faciles à contrôler pour respecter l’évolution du cadre réglementaire ?
L’infrastructure technologique retenue sera-t-elle facile à adapter pour répondre aux enjeux de performance et de sécurité ?
Pour optimiser le succès de votre projet numérique, toutes ces questions et bien d’autres doivent être anticipées.
De nombreux aspects ne dépendent pas strictement de l’informatique.
Au sein de l’entreprise, plusieurs acteurs en dehors de la direction des systèmes d’information (DSI)et des directions métiers sont impliquées : Marketing, communication, ressources humaines, finance, juridique, stratégie, etc.
Il vous faut comprendre les enjeux de chacun et leur rôle dans la vie opérationnelle du nouvel outil.
Une analyse de la maturité digitale à 360 degrés vous aidera.
Qu’est-ce que la maturité digitale d’une entreprise à l’instant « T » ?
Le livre
La maturité digitale de votre entreprise permet d’apprécier sa capacité, à un instant « T », d’opérer dans le monde numérique dans lequel nous vivons toutes et tous.
Elle se traduit par une note de 1 à 5, facile à appréhender par toutes les parties prenantes et par votre management.
Chaque indicateur est construit de la même manière, en 5 niveaux d’exigence.
Meilleure est la pratique courante dans votre entreprise sur cet indicateur, meilleure est la note.
Les 6 leviers de digitalisation selon Michaël Tartar
Quelle que soit la taille de votre entreprise.
Toutes les tailles d’entreprises sont considérées.
Alors que la totalité des indicateurs est applicable aux grandes entreprises, pour répondre aux contraintes propres aux petites entreprises (TPE/PME) ou aux administrations, le livre précise les indicateurs applicables à chaque type de structure.
Des spécificités sectorielles sont également prises en compte pour coller aux particularités propres à votre industrie ou secteur d’activités, et surtout aux différences de niveaux de maturité digitale de ceux-ci.
Pour réussir votre projet numérique, vérifiez que votre entreprise est bien prête !
En amont d’un projet informatique, il vous faudrait toujours vérifier la maturité digitale de votre entreprise à utiliser le nouveau logiciel.
Cette revue permet d’identifier les faiblesses que le nouvel outil rencontrera dans sa vie réelle, une fois livré.
Ainsi, en tant que manager de projet, vous pouvez conseiller en amont votre sponsor et comité de projet en les invitant à régler certains points qui doivent l’être pour garantir le succès de leurs investissements dans ce développement logiciel.
Comprenez chaque indicateur présenté dans le livre, évaluez ceux qui s’appliquent ou pas à votre entreprise et utilisez la méthode de calcul pour obtenir une note entre 1 et 5.Puis présentez et discutez ce résultats avec vos parties prenantes les plus importantes.
Visitez le site pour davantage de détails.
Michaël Tartar a développé une plateforme dimmup.com, à la fois pour aller plus vite dans la phase initiale puis pour mettre en place un cadre vertueux de pilotage de la transformation digitale, par la mesure régulière et répétée des indicateurs.
Cela vous permet de prendre en compte les évolutions du numérique dans votre société et environnement (nouveaux standards, nouveaux usages, nouvelles réglementations, etc.).
En faisant cet exercice d’évaluation de la maturité digitale de votre entreprise, vous percevez beaucoup plus vite les facteurs de succès de votre projet informatique, au-delà des approches classiques de management de développement logiciel en mode Agile/évolutif comme Cascade/prédictif.
De plus vous pouvez identifier ainsi d’autres besoins de développement pour répondre aux attentes des utilisateurs métier.
C’est la raison la raison d’être de DIMM.UP et de la plateforme dimmup.com.
partagez ce billet avec vos amis, collègues et relations professionnelles
Le plan de management des risques n’est pas une liste des risques et de la façon dont vous prévoyez d’y réagir : Ceci est appelé le « registre des risques ».
Le plan de management des risques décrit votre approche pour votre projet spécifique du management des risques.
4 Tips for Developing a Risk Management Plan par Harry Hall
Stephen Covey a introduit le concept d’activités du quadrant II, qui consiste à travailler sur des choses qui sont importantes mais qui ne sont pas urgentes.
La planification est une activité puissante qui peut vous faire gagner du temps et de l’énergie.
Pensez à l’avenir afin de pouvoir prendre de meilleures décisions dans le présent.
Parlons de la façon de planifier votre management des risques.
Commençons par le début
Certaines personnes pensent que les plans de management des risques ne sont pas la bonne manière de faire.
Les plans de management des risques ne sont pas une liste des risques et de la façon dont vous prévoyez d’y réagir. Ceci est le registre des risques de votre projet.
Votre plan de management des risques* est plutôt d’une approche du management des risques.
Comment comptez-vous identifier et évaluer les risques ?
Comment allez-vous élaborer des plans d’intervention en cas de risque ?
Quand allez-vous passer en revue les risques et vos processus de management des risques ?
Quels sont vos seuils de risque ?
Comment allez-vous faire remonter les problèmes ?
La différence entre un plan de management des risques et un registre des risques
* Qu’est-ce qu’un plan de management des risques de projet ?
Le plan de management des risques est « une composante du plan de management du projet, du programme ou du portefeuille qui décrit la façon dont les activités de management des risques seront structurées et exécutées » (Guide PMBOK®, septième édition).
Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes
Conseils pour l’élaboration de votre plan
#1 – Examinez les leçons apprises, la charte de projet et le plan de management de projet
Je l’ai déjà dit et je vais le dire à nouveau. Les managers de projet avisés apprennent d’autres projets, en particulier de projets similaires. Prenez le temps de revoir les leçons tirées des projets précédents. Que pouvez-vous découvrir des approches précédentes en matière de management des risques ? Et, si les leçons apprises n’ont pas été documentées, interrogez les managers de projet pour obtenir leurs points de vue.
Ensuite, passez en revue la charte du projet. Quels sont les principaux livrables du projet ? Quels sont les principaux risques ? Quelles sont les principales parties prenantes ?
Passez en revue le plan de management de projet. Y a-t-il une date butoir pour le projet ? Le budget a-t-il été fixé ? Des ressources seront-elles nécessaires ? Que savons-nous de la portée du projet ?
Calendrier des activités de management des risques
Catégories de risque
Attitude à l’égard du risque, appétit et tolérance
Format de rapport
Glossaire
#3 – Déterminez qui participera à l’élaboration du plan
Il y a des experts de chaque sujet à l’intérieur et à l’extérieur de votre organisation qui peuvent vous aider à élaborer votre plan. Les managers de projet ne peuvent pas tout savoir. Par exemple, vous pourriez avoir besoin d’une expertise dans les domaines suivants :
Finances et comptabilité
Technologie de l’information
Design
Test
Analyse d’affaires
Opérations
Ressources humaines
Audit
#4 – Élaborez le plan
Vous avez donc passé en revue les leçons apprises, déterminé ce qu’il fallait inclure dans votre plan et déterminé qui engager dans l’élaboration du plan.
Ensuite, vous élaborez le plan.
Ce processus peut inclure :
Entrevues
Réunions
Analyse des données
J’ai souvent une réunion au début de mes projets pour élaborer le plan de management des risques. Les participants à la réunion sont les membres de l’équipe de projet, les principales parties prenantes et d’autres personnes extérieures à l’organisation qui peuvent être touchées par le projet.
Et vous ?
Vous n’êtes pas certain de la valeur de l’élaboration d’un plan de management des risques ?
Essayez-le et voyez par vous-même : Élaborez un plan de management des risques pour l’un de vos nouveaux projets. Il n’est pas nécessaire qu’il soit long et bon nombre de mes plans de management des risques ne font que quelques pages. Cliquez ici pour voir un exemple.
Concentrez-vous sur la valeur ajoutée.
“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
Avec le passage à DevOps, les systèmes que nous construisons ont acquis deux nouvelles qualités importantes : Ils ne finissent jamais et ils fournissent de continuelles rétroactions et opportunités d’apprendre.
Il m’est apparu récemment qu’il y a une transformation radicale dans notre conversation sur le développement de produits numériques en raison du changement (certes lent) mais inévitable vers le management des résultats. Pendant des décennies, la composante « fixe » de nos conversations sur les produits était le produit lui-même. Bien sûr, nous nous sommes peut-être déportés vers les délais, la portée et/ou les choix de conception, mais la question de « allons-nous le livrer ? » n’a jamais été mise en doute. Le produit allait certainement arriver.
Le déploiement du produit n’est plus certain
Avec le passage aux systèmes de déploiement continu, de test et d’intégration continus (alias DevOps), les systèmes que nous construisons ont acquis deux nouvelles qualités importantes :
Ils ne sont jamais finis – Nous travaillons sur nos produits, aujourd’hui, « pour toujours ». Il n’y a pas de date de fin fixe pour les fonctionnalités que nous construisons. Cela semble étrange ? Demandez-vous : « Quand Netflix sera-t-elle terminée ? » Remplacez « Netflix » par n’importe quelle autre entreprise moderne et il devient clair que nos produits et services vivent pour toujours. Il n’y a pas de date de fin explicite. À un moment donné, nous décidons qu’ils ne fournissent plus assez de valeur ou que l’investissement nécessaire pour en extraire plus de valeur n’en vaut pas la peine et nous passons à autre chose. D’ici là, nous devons maintenir et optimiser ces systèmes en permanence.
Ils fournissent une rétroaction continue et une opportunité d’apprentissage – Parce que ces systèmes sont toujours en vol, offrant de la valeur (ou non) et fournissant un service aux clients, nous apprenons continuellement à quel point ils fonctionnent. Nous avons maintenant une opportunité incroyable de déterminer où concentrer au mieux nos efforts pour améliorer continuellement ces systèmes pour nos clients.
Apporter la plus grande valeur aux clients, aussi rapidement que possible.
Ces qualités nous obligent à considérer une mesure de la valeur différente de celle du passé. Nous n’avons plus besoin de nous concentrer sur le fait de savoir si nous avons livré ou non une fonctionnalité spécifique. Au lieu de cela, nous nous concentrons sur ce que nos clients font dans le système. Réussissent-ils ? L’utilisent-ils d’une manière qui leur profite ? Font-ils ce à quoi nous nous attendions ? Autre chose ? Notre obsession n’est plus de savoir si une capacité spécifique a été déployée ou non, mais plutôt de savoir si le système offre de la valeur. Une volonté de « simplement diffuser des fonctionnalités » n’a plus de sens dans ce nouveau contexte.
Le produit est la variable
La nature moderne des logiciels se concentre sur le déploiement de la plus petite quantité de code qui offre la plus grande quantité de valeur. Pourquoi ? Parce que nous devons vivre avec ce code pour toujours. Notre nouvelle mesure du succès est le comportement des clients (ou les résultats). Les comportements et les changements dans ces comportements que nous voulons voir chez nos clients sont nos nouvelles mesures du succès. La façon dont nous réalisons ces changements de comportement devient la variable. Le produit est la variable.
Il existe une combinaison infinie de code, de conception, de proposition de valeur et de modèle commercial qui peut apporter les changements de comportement souhaités. Nous mélangeons, associons et expérimentons différentes façons de rendre notre offre plus précieuse pour nos clients. L’objectif fixé est un changement dans le comportement de nos clients. Nous continuons à ajuster et (espérons-le) à améliorer le produit jusqu’à ce que nous atteignions le niveau souhaité de changement de comportement.
Cela nécessite un nouvel état d’esprit pour le développement de produits
Accepter ce changement dans la façon dont nous manageons nos équipes et nos organisations ne sera pas facile. C’est un profond changement de mentalité. Il est facile de considérer le produit comme l’objectif. Nous pouvons clairement écrire ce que nous croyons qu’il devrait faire, le concevoir pour le faire et le livrer. Malheureusement, cela ne garantit pas notre succès. Cela ne garantit que le déploiement du code (et la dette technique subséquente). La variabilité des produits peut effrayer les parties prenantes. « Qu’est-ce qu’on construit ? », demanderont-ils. En fin de compte, nous devons changer cette question en : « Comment tendons-nous vers les changements de comportement souhaités ? » Cela prendra du temps, mais c’est inévitable. Nos socles technologiques modernes l’exigent.
partagez ce billet avec vos amis, collègues et relations professionnelles
Paralysie de l’analyse : Nous nous y sommes tous englués à un moment ou à un autre, cette sur-analyse ou cette réflexion excessive sur les alternatives qui empêche un individu ou un groupe de prendre une décision. Comment les chefs de produit peuvent-ils s’empêcher de le faire et comment les leaders peuvent-ils favoriser une culture où cela ne se produit pas ?
Comment la reconnaître
La paralysie de l’analyse a un impact sur nos performances et notre créativité, mais nous ne reconnaissons pas toujours quand nous y sommes embourbés. Randy Silver, coach produit et animateur de notre podcast Product Experience, déclare :
« Parfois, les arbres cachent la forêt… Habituellement, il faut que quelqu’un d’autre dise quelque chose avant de vous en rendre compte. »
Cela peut arriver aux meilleurs d’entre nous. Randy raconte une époque où il travaillait dans une entreprise de services financiers B2B et développait un nouveau produit soumis à tous les problèmes de réglementation financière et de conformité qui peuvent rendre difficile le travail itératif dans cet espace. « Nous faisions quelque chose d’assez ‘big bang’ avec un groupe de composants. Tout composant individuel était inutile en isolation. »
La construction du produit a pris plus d’un an. Randy et son équipe ont passé des mois dans la paralysie de l’analyse, tournant en rond en se demandant s’ils construisaient le produit de la bonne façon. Il dit qu’une communication régulière contribue grandement à prévenir la paralysie de l’analyse. Fournir des mises à jour régulières à votre supérieur et à vos parties prenantes « est une bonne secousse » pour l’éviter. « Un autre indicateur est l’équipe. Ont-ils l’impression d’être inspirés, de progresser, de savoir quoi faire ? », ajoute-t-il.
4 moyens d’éviter la paralysie de l’analyse
#1 – Fixez des objectifs réalisables en interne
Les choses auraient été différentes pour le produit fintech de Randy s’il y avait eu des objectifs internes. Avec le recul, ils auraient dû se fixer des objectifs individuels, afin de pouvoir prouver qu’un composant fonctionnait à leur satisfaction afin qu’ils puissent construire le suivant.
Il déclare : « J’aurais dû fixer un certain nombre d’objectifs internes réalisables spécifiques pour certaines de ces composantes ». J’aurais dû dire : « Mettons en place l’infrastructure de base. Oubliez l’expérience utilisateur pour l’instant, assurons-nous que le moteur est satisfaisant. Nous pourrons itérer ensuite sur l’expérience utilisateur ».
#2 – Utilisez un cadre décisionnel
Jeff Bezos d’Amazon est le représentant le plus célèbre des décisions type 1 contre type 2, dont il a discuté dans sa lettre aux actionnaires de 2016. Aujourd’hui, ceci est largement utilisé pour éviter la paralysie de l’analyse et constitue un cadre simple mais efficace pour la prise de décision.
Toutes les décisions se répartissent en deux catégories, en fonction de leur impact. Les décisions de type 1 sont également appelées « portes à sens unique » et les décisions de type 2 sont également appelées « portes à double sens ».
Voici comment cela fonctionne :
Prenez une décision de type 1 et vous pouvez ouvrir une porte pour la franchir, mais pas revenir en arrière.
Prenez une décision de type 2 et, si cela ne fonctionne pas, vous pouvez toujours revenir en arrière.
Les décisions de type 1 sont peu fréquentes, la plupart sont de type 2, mais il est facile de confondre les deux types.
Plus vous prenez de décisions, mieux vous déterminez le type à utiliser.
Les décisions de type 1 exigent que vous preniez le temps de recueillir des données et de découvrir vos options : Élaborez sur les éléments non négociables et séparez-les des éléments agréables à connaitre. Soupesez les preuves et choisissez la décision offrant la meilleure solution. Agissez puis examinez et surveillez l’impact.
La plupart des décisions sont de type 2 et réversibles, mais elles nécessitent tout de même un bon jugement. Vous devriez les prendre rapidement, mais sans précipitationni analyse excessive. Vous devez vous préparer à vous tromper et ne pas vous soucier d’être parfait. Vous pourrez analyser plus tard et y revenir si nécessaire.
#3 – Gardez une communication régulière
Fournir des mises à jour régulières à votre patron et à vos parties prenantes « est une bonne secousse » pour éviter la paralysie de l’analyse, dit Randy. « Un autre est l’équipe. Ont-ils l’impression d’être inspirés, de progresser, comme s’ils savaient quoi faire ? », ajoute-t-il.
#4 – Favorisez la sécurité psychologique
Cela a été dit à maintes reprises, mais la sécurité psychologique est la clé pour éviter la paralysie de l’analyse.
Une équipe doit comprendre qu’elle ne sera pas punie si elle essaie quelque chose qui ne fonctionne pas.
Une culture de sécurité psychologique incite les gens à apprendre et à apporter des idées.
Mais vous serez toujours coincé à un moment donné
Rappelez-vous que même les équipes qui réussissent s’embourbent parfois. Même avec tous les cadres et processus à votre disposition, même avec une culture de sécurité psychologique, vous serez probablement parfois tout de même englués dans la paralysie de l’analyse.
Les équipes de Pendo ont commencé à travailler sur la stratégie d’IA de l’entreprise il y a environ deux ans. Ses ingénieurs en machine learning ont recherché des tendances dans les données et ont créé un modèle de rétention. Trisha Price, chef de produit chez Pendo, explique : « Ils ont créé un modèle incroyable, qui nous indiquait quelles étaient les caractéristiques collantes, de sorte que si nous faisions en sorte que les clients les adoptent, ils ne partiraient jamais. »
Ensuite, ils sont restés bloqués – pendant environ six mois – parce qu’ils ne pouvaient pas déterminer ce que l’expérience utilisateur devrait être et où la mettre dans le produit. Trisha explique :
« Nous avions des partenaires de conception, nous avons fait différents designs, nous avions cette fonctionnalité incroyable, mais tout est tombé à plat. »
Ce qu’ils avaient fait, dit Trisha, était d’essayer de manager le produit de l’intérieur vers l’extérieur plutôt que de l’extérieur vers l’intérieur. Ils cherchaient une solution à un problème, plutôt que le problème qu’ils devaient résoudre. Elle conclut :
« Nous devions oublier le modèle, oublier les données et revenir aux bases du management des produits, qui est toujours à l’extérieur, toujours quel est le problème que vous essayez de résoudre. Une fois que nous avons pris du recul, nous nous sommes débloqués. »
J’ajoute cette vidéo qui explique de manière simple la paralysie par l’analyse et surtout comment en sortir.
partagez ce billet avec vos amis, collègues et relations professionnelles
Votre entreprise est-elle prête pour ce nouveau projet que l’on vous charge de mener à bon port ?
Préparez le succès de votre projet numérique.
En tant que chef de projet informatique, vous disposez d’un arsenal de méthodologies et d’outils. Votre objectif est de livrer un composant logiciel répondant aux attentes de votre client (interne comme externe), dans un coût maîtrisé, de la meilleure qualité possible, dans un délai convenu avec les ressources dont vous disposez. En vous concentrant sur ces aspects, vous avez le sentiment de bien faire votre travail. Vous avez raison… partiellement. Car votre projet est en réalité le préambule d’une nouvelle étape : la vie de ce que vous avez créé.
C’est alors que les utilisateurs se saisissent (ou pas) de votre travail.
Vont-ils adopter ce nouvel outil ?
Les changements qu’ils ne manqueront pas de demander seront-ils réalisés aussi rapidement que nécessaire ?
Les données collectées et créées seront-elles faciles à contrôler pour respecter l’évolution du cadre réglementaire ?
L’infrastructure technologique retenue sera-t-elle facile à adapter pour répondre aux enjeux de performance et de sécurité ?
Pour optimiser le succès de votre projet numérique, toutes ces questions et bien d’autres doivent être anticipées. Vous vous apercevez alors que de nombreux aspects ne dépendent pas strictement de l’informatique. Au sein de l’entreprise, plusieurs acteurs en dehors de la DSI et des directions métiers sont impliquées : Marketing, communication, RH, finance, juridique, stratégie, etc. Il vous faut comprendre les enjeux de chacun et leur maîtrise de leur rôle dans la vie opérationnelle du nouvel outil. Une analyse de la maturité digitale à 360 degrés vous aidera.
Qu’est-ce que la maturité digitale d’une entreprise ?
Le livre
La maturité digitale d’une entreprise permet d’apprécier sa capacité, à un instant « t », d’opérer dans le monde numérique dans lequel nous vivons désormais.
Elle se traduit par une note sur 5, facile à appréhender par le management.
Chaque indicateur est construit de la même manière, en 5 niveaux d’exigence. Meilleure est la pratique courante dans l’entreprise sur cet indicateur, meilleure est la note.
Pour répondre aux contraintes propres aux petites entreprises (TPE/PME) ou aux administrations, le livre précise les indicateurs applicables à ce type de structure. La totalité des indicateurs est applicable aux grandes entreprises. Les spécificités sectorielles sont également prises en compte pour coller aux particularités propres à chaque secteur, et surtout à leurs différences de niveaux de maturité digitale.
Le livre complète la description du modèle par une explication détaillée des concepts qui le sous-tendent et par de nombreuses illustrations par des praticiens du digital, dans tous les corps de métier concernés.
Vérifiez que votre entreprise est prête pour votre projet
En amont d’un projet informatique, il est ainsi vivement conseillé de vérifier la maturité digitale de l’entreprise qui sera amenée à utiliser le nouveau logiciel. Cette vérification permet d’identifier les faiblesses que le nouvel outil rencontrera dans sa vie courante. Ainsi le chef de projet peut conseiller son donneur d’ordre en l’invitant à régler certains points qui doivent l’être pour garantir le succès de son investissement.
Vous pouvez suivre chaque indicateur présenté dans le livre, évaluer ceux qui s’appliquent à votre entreprise et appliquer la méthode de calcul qui vous donnera une note sur 5. Pour aller plus vite, vous pouvez utiliser la plateforme dimmup.com. Au-delà de cette première mesure de maturité digitale, la plateforme crée aussi un cadre vertueux de pilotage de la transformation digitale, par la mesure régulière des indicateurs, et la prise en compte des évolutions du numérique dans nos sociétés (nouveaux standards, nouveaux usages, nouvelles réglementations, etc.).
Ainsi, en faisant cet exercice d’évaluation de la maturité digitale de votre entreprise, vous percevez beaucoup plus vite les facteurs de succès de votre projet informatique, au-delà des approches classiques de gestion de développement logiciel. De plus vous pouvez identifier ainsi d’autres besoins de développement pour répondre aux attentes des utilisateurs métier.
Enfin vous créez les conditions du succès à long terme de vos travaux, en dépassant les aspects techniques.
Qui est Michaël Tartar ?
Michaël Tartar
Fondateur & CEO de DIMM.UP, Michaël accompagne la transformation digitale des entreprises depuis bientôt trois décennies. Issu de l’ingénierie logicielle, son parcours professionnel l’a amené à réaliser de nombreux projets numériques, dans des entreprises privées comme publiques, de petites tailles comme internationales. Il a normalisé son approche à 360 degrés de la transformation digitale en créant un modèle de maturité digitale. Publié pour la première fois en 2014, mis à jour en 2019, la version 2022 (La transformation digitale pour tous !, co-écrit avec David Fayon) est best-seller chez l’éditeur, Pearson. Au-delà du modèle, le marché attendait aussi des méthodologies et des outils pour le mettre en œuvre.
C’est la raison la raison d’être de DIMM.UP et de la plateforme dimmup.com.
partagez ce billet avec vos amis, collègues et relations professionnelles
Je vous concède volontiers que la position est exagérée, mais elle contient cependant beaucoup de véracité.
Comme ce blog est centré sur le management de projets, j’y ai bien sûr publié bon nombre de billets sur le planning. En voici quelques-uns que vous voudrez peut-être relire ou découvrir.
L’impact de l’Intelligence Artificielle (IA) sur la gestion de projet.
Depuis des milliers d’années, l’homme réalise des projets, comme nos ancêtres qui fabriquaient des outils et allaient chasser le gibier, construisaient les pyramides d’Égypte, bâtissaient la muraille de Chine, etc.
Ces projets ont été réalisés avec le savoir-faire et les moyens existants dans ces époques lointaines.
la triple Contrainte
Au fil du temps, les connaissances en gestion de projet s’accumulent, les outils et les moyens se perfectionnent et la gestion de projet s’améliore en optimisant de mieux en mieux les principaux composants d’un projet à savoir son périmètre (scope), son coût et les délais de sa réalisation.
A partir de 1950, le domaine de la gestion de projet a connu une évolution rapide et a commencé à se structurer et à se standardiser avec notamment :
La généralisation de l’’utilisation du diagramme de GANTT créé en 1910 pour notamment planifier, suivre et coordonner les différentes tâches d’un projet,
L’invention du réseau PERT en 1958 (Program Evaluation Review Technique, « technique d’évaluation et d’examen de programmes ») pour l’ordonnancement et la planification du projet,
La création du PMI® (Project Management Institute) en 1969 pour développer des compétences et expertises en gestion de projet,
La création de logiciels comme MS Project et Primavera pour automatiser les calculs avec une meilleure maîtrise de la gestion et du suivi des projets,
La généralisation de l’utilisation des méthodes agiles à partir de 2001 pour tout type de projets imprévisibles, notamment les projets technologiques, d’exploration, innovants et créatifs. Ces méthodes s’avèrent très efficaces pour la bonne réussite de ce type de projets.
En gestion de projet et les chefs de projet sont constamment à la recherche d’outils et de techniques innovants pour améliorer les processus de planification, d’exécution et de suivi.
Ce souci a poussé les acteurs des projets à s’intéresser également à l’intelligence artificielle (IA) avec en tête la solution ChatGPT d’OpenAI ou son concurrent Bard de Google.
Pour rappel l’objectif d’un projet de l’IA est d’imiter le cerveau humain. ChatGPT ou Bard utilisent des réseaux de neurones artificiels pour traiter des données fournies et générer de nouvelles données. Grâce à l’apprentissage continu, ces chatbots s’améliorent et se perfectionnent en continu. Entre autre, ils comprennent le langage écrit et parlé, et ils peuvent fournir des réponses cohérentes et pertinentes en temps réel.
Le cabinet Gartner estime que d’ici 2030, 80% des tâches actuelles de la gestion de projet, pourraient être automatisées grâce à l’Intelligence Artificielle.
Voyons comment ChatGPT, considéré comme un outil révolutionnaire aujourd’hui va impacter le domaine de la gestion de projet.
Il peut être chargé de :
Répondre aux questions: Répondre automatiquement à tout type de questions de clarification, de conseil, de rédaction, de définition et fournir des commentaires précis.
Planifier : Créer des plannings de projet. Par exemple la génération automatique des tâches, des relations entre tâches, les échéanciers.
Faciliter la communication: Faciliter la communication entre toutes les parties prenantes. Créer des contenus, de la documentation, collecter des données, les résumer et les diffuser. Exemple : Rédiger des E-mails, les envoyer à des destinataires précis et répondre à des E-mails.
Générer des plans: Générer des plans de documents, de réunions, de présentations…exemple le plan d’une présentation de projet, de la réunion Kick-Off.
Transcrire et diffuser de l’information : La transcription des réunions pour convertir la vidéo en texte, l’analyse des données, la préparation de résumés et leur diffusion.
Générer des idées : La génération d’idées et de suggestions à partir des données historiques lors des brainstormings.
Gérer les risques: Identifier et évaluer les risques potentiels et suggérer des stratégies de prévention.
Suivre le projet : Suivre l’avancement du projet avec des indicateurs de performance et alerter en cas de dérives.
S’interfacer avec MS Project: ChatGPT peut être incorporé à ce logiciel de gestion de projet pour affecter des tâches à des personnes, suivre l’évolution du projet, fournir des mesures de performances, réaliser des reportings et les diffuser aux parties prenantes.
A noter que ChatGPT a été entrainé avec des données allant jusqu’à septembre 2021, ses analyses et réponses sont donc limitées à cette date.
ChatGPT et d’autres solutions basées sur l’IA aident les chefs de projets à mieux planifier, mieux exécuter et mieux suivre les projets, ce qui permettra d’augmenter grandement le taux de succès des projets.
ChatGPT est là pour soutenir le chef de projet, et va réduire grandement sa charge du travail. Le chef de projet va se consacrer à la gestion des relations humaines, aux jugements et à la prise des décisions.
Zidane Zait
Zidane Zait
Zidane Zait, coach Agile et formateur Scrum, enseigne aux équipes l’agilité, l’Agile Framework Scrum et Agile MS Project. Son objectif est de faciliter le développement d’un esprit agile, la réalisation de solutions de valeur, la collaboration, l’auto-gestion des équipes, l’amélioration continue ainsi que l’engagement, la passion et l’enthousiasme envers ces approches.
partagez ce billet avec vos amis, collègues et relations professionnelles
DantotsuPM.com 