Les ‘OKR’ (Objectives and Key Results) : C’est si simple ! Alors pourquoi tout le monde ne les utilise-t-il pas ?

Les ‘OKR’ (Objectives and Key Results), comme la plupart des méthodologies, supportent des principes sous-jacents qui, s’ils sont bien mis en œuvre, peuvent fondamentalement changer l’état d’esprit et la conversation au sein de votre organisation.

OKRs: So simple! So then why isn’t everyone using them? par Kim Atherton

https ://www.mindtheproduct.com/okrs-so-simple-so-then-why-isn’t-everyone-using-them/

Livre sur Amazon

Beaucoup d’entre vous connaissent l’histoire des Objectives and Key Results (OKR). Lorsque j’ai découvert la méthodologie pour la première fois en 2013, j’ai été impressionnée par les histoires d’alignement et de concentration organisationnelles de Google, Twitter et LinkedIn. Je me suis précipitée pour acheter l’ancien livre de John Doerr : Mesurez ce qui compte: Comment Google, Bono et la fondation Gates ont révolutionné le monde grâce à la méthode OKR.

Après 7 ans de mise en œuvre d’OKRs à la fois depuis l’intérieur et l’extérieur des organisations, j’ai appris qu’ils ne sont pas la solution miracle que je pensais qu’ils étaient. Cependant, comme la plupart des méthodologies, il existe des principes sous-jacents qui, s’ils sont bien mis en œuvre, peuvent fondamentalement changer l’état d’esprit organisationnel et la conversation.

Dans cet article, je vais vous donner quelques conseils pour vous remettre sur les rails avec les OKRs.

  • Soyez clair sur votre direction pour aider les équipes à aligner leurs objectifs et leurs résultats
  • Concentrez-vous sur ce qui compte vraiment lors de l’utilisation des OKRs. Limitez vos priorités et cherchez toujours à ajouter de la valeur à vos tâches.
  • Faites un suivi et apprenez tout en encourageant un état d’esprit expérimental. L’utilisation de données peut être utile pour assurer la transparence et le sens de tout ce que vous faites. Soyez toujours à la recherche de choses qui fonctionnent et qui ne fonctionnent pas pour créer une culture d’apprentissage au sein de votre équipe et de l’organisation au sens large.

L’utilisation d’OKRs promet des avantages alléchants pour l’organisation.

1) Alignez les équipes et apportez de la clarté

La cascade des OKRs, depuis la stratégie de l’entreprise jusqu’au niveau de l’équipe, signifie que les efforts de chacun sont liés. Plutôt que de travailler en solos indépendants, tous les efforts sont ciblés et coordonnés, ce qui donne un sentiment de clarté qui pourrait autrement manquer. Apprenez-en davantage sur la constitution d’équipes extraordinaires.

2) Mettez l’accent sur les résultats axés sur la valeur

résultatsLes résultats clés (Key Results) doivent être des mesures quantifiables de la réussite de l’entreprise plutôt que des projets ou des jalons indéfinis. Cela permet à tout le monde de se concentrer sur ce qui compte vraiment plutôt que sur une liste de projets de prédilection des équipes de direction et éviter le risque de devenir une usine à fonctionnalités. Tout le monde s’efforce de créer de la valeur pour l’entreprise.

3) Encouragez un état d’esprit expérimental

Le fait de relier les initiatives (qui sont des expérimentations ou des projets) à des résultats clés (Key Results) quantifiables (résultats business) signifie que l’impact qu’elles ont peut être suivi. Cela permet à l’ensemble de l’organisation d’adopter une approche plus entrepreneuriale et contribue à intégrer les principes Agile que beaucoup d’entre vous cherchent à adopter. De plus, la cadence des OKRs est généralement annuelle au niveau de l’organisation, mais trimestrielle au niveau de l’équipe, ce qui conduit à une approche plus dynamique et adaptable.

CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

4) Donnez de la transparence et une raison d’être

Alors qu’auparavant, les objectifs stratégiques plus larges d’une entreprise n’étaient peut-être connus que de la direction, les OKRs devraient être visibles par tout le monde à tous les niveaux d’une organisation. Cela permet de favoriser la collaboration et le sentiment d’utilité en donnant aux équipes une compréhension de ce sur quoi tout le monde travaille et des opportunités de collaborer ensemble sur des objectifs communs. Dans une récente enquête MTP sur les OKRs, 48 % des personnes interrogées ont déclaré que le principal avantage de l’utilisation des OKRs est une transparence accrue dans l’ensemble de l’organisation.

Ça a l’air génial, mais attention à certains pièges fréquemment rencontrés.

Jusque-là, c’est simple mais hélas, comme toujours, le diable est dans les détails. Lorsque j’ai mis en œuvre les OKRs pour la première fois avec OVO Energy, nous étions une entreprise en pleine expansion qui allait bientôt devenir une licorne et j’ai pensé que bon nombre des pièges dans lesquels nous sommes tombés pouvaient être attribués à cela. Cependant, depuis que  j’ai lancé Just3Things il y a deux ans, en travaillant avec des clients de 200 à 20 000 employés, j’ai constaté qu’il existe des pièges communs aux organisations, grandes comme petites.

1) Les OKRs semblent simples, mais sont trompeusement difficiles à réussir !

La plupart des équipes commencent judicieusement par réfléchir aux objectifs qui soutiennent les résultats stratégiques à long terme et aux critères de mesure qui constitueraient le succès (jusque-là, tout va bien). Cependant, le plus souvent, les résultats clés (Key Results) ne sont pas mesurables, les données ne sont pas disponibles ou la métrique arrive tardivement et on ne s’attend pas à ce qu’elle change pendant des mois, quel que soit le nombre d’initiatives mises en œuvre. De plus, il est trop facile d’essayer d’intégrer trop d’indicateurs clés de performance dans les OKRs.

Pour essayer de décrire la différence : Imaginez que vous êtes allé chez le médecin pour un bilan de santé et que votre tension artérielle est bonne. Vous pourriez garder un œil dessus, mais vous ne prendrez aucune mesure pour la changer. Cependant, si votre tension artérielle est élevée, vous prendrez des mesures pour l’améliorer (par exemple, commencer à faire de l’exercice, changer de régime alimentaire, etc.), auquel cas la pression artérielle passera d’un indicateur clé de performance à un résultat clé. Étant donné qu’il est difficile de trouver des KRs (Key Results) qui sont mesurables, qui ne sont pas trop en retard, qui ne sont pas des KPIs (Key Performance Indicators)  et qui se rapportent réellement à l’objectif, il n’est pas étonnant que…

2) quand les OKRs sont prêts à être diffusés, c’est la déjà fin du trimestre !

J’ai vu cela à plusieurs reprises, allant de pair avec le piège d’avoir tellement d’OKRs par équipe qu’ils ont à peine le temps de commencer à faire bouger l’aiguille du cadran pour le prochain trimestre avant qu’il ne soit temps de recommencer à planifier. En fait, la nécessité de limiter les équipes à un petit nombre de priorités, afin de maintenir la faisabilité de leurs plans, est exactement le principe intégré à « Just3Things » depuis le départ.

3) Il est difficile d’obtenir le bon alignement.

Beaucoup de choses ont été écrites sur la question de savoir si les équipes devraient posséder un KR (Key Result) de l’objectif d’une autre équipe ; Si les équipes doivent partager les OKRs ; Si l’alignement doit être horizontal ou vertical ?

Ayant vécu cela avec de nombreuses organisations, la seule conclusion que je peux en tirer est qu’il n’y a pas de « taille unique » qui conviennent à toutes les organisations. Cependant, il est essentiel d’avoir une combinaison d’alignement descendant (où la direction définit les objectifs stratégiques et les OKRs annuels) et d’alignement ascendant (où les équipes définissent les OKR ssur lesquels elles savent qu’elles travaillent).

4) La prise de conscience que tout doit changer !

Lorsque j’ai commencé à travailler avec les OKRs, j’ai pensé qu’ils constitueraient un complément intéressant à la gouvernance et aux pratiques organisationnelles existantes. La réalité a commencé à s’immiscer lors de la première réunion de l’équipe de direction, lorsque le PDG a demandé à chaque département sa mise à jour mensuelle (le tour de table habituel des indicateurs clés de performance et du BAU « Business As Usual »). Il m’est venu à l’esprit que rien de ce qui avait été dit au cours de la dernière heure ne concernait les OKRs dont, quelques semaines auparavant, nous avions tous identifiés comme étant les choses les plus importantes que l’entreprise devait réaliser. Nous n’étions pas les seuls.

Lefebvre Dalloz Compétences est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.

Beaucoup de mes clients ne réalisent pas la nécessité de changer :

  • La façon dont les progrès sont suivis ;
  • La façon dont les mises à jour sont présentées ;
  • La manière dont les équipes relaient leurs progrès ;
  • La façon dont les réunions sont présidées et managées.

Et ceci est nécessaire avant de commencer à réfléchir à la façon dont les OKRs s’intègrent aux évaluations de performance (alerte spoiler : ce n’est pas le cas). Cependant, si vous faites les choses correctement, vous pourrez vraiment commencer à vous concentrer sur ce qui compte, jusqu’à ce que…

5) L’équipe de direction demande « qu’en est-il de mon projet favori ? »

Même si le rose est la couleur préférée du dirigeant, tout ne peut être peint en rose.

J’ai vu de nombreux déploiements d’OKRs dérailler au moment où un cadre exécutif se rende compte que : Si nous encourageons une culture responsabilisée d’équipes qui expérimentent des initiatives et leur donnons accès aux données client sous-jacentes pour voir si leurs livrables fonctionnent réellement… alors les backlogs ne peuvent plus contenir de fonctionnalités que moi et le reste de l’équipe de direction « avons vu l’entreprise X faire et elles doivent donc être géniales » !

6) Ne pas rendre les OKRs transparents, avec des progrès facilement traçables et des résultats faciles à apprendre.

Je suis le pire des vendeurs et je ne suis pas là pour blâmer les logiciels (honnêtement), mais avoir un moyen de partager l’alignement des OKRs, de suivre régulièrement les progrès et d’examiner ce qui fonctionne est essentiel à leur succès.

Il n’est pas nécessaire qu’il s’agisse d’une plate-forme logicielle – un disque partagé, un tableau blanc de bureau physique pré-COVID ou tout autre moyen de partage qui fonctionne est génial – mais les progrès doivent être suivis sinon les OKRs vont dans le sens de l’objectif annuel Powerpoint et ne seront dépoussiérés que lorsqu’il est temps de faire le bilan de l’année.

Alors pourquoi s’embêter ? Quelques points clés à retenir.

Il est indéniable que les OKRs sont difficiles à mettre en place et que trop d’entre nous peuvent être pris dans les « règles ». Cependant, comme tant de méthodologies, il existe des principes sous-jacents fantastiques.

Les choses que je retiendrais si je voulais créer une organisation responsabilisée habilitée seraient les suivantes :

Définissez une direction claire

En définissant les objectifs stratégiques et les objectifs organisationnels, les équipes peuvent aligner leurs objectifs et le travail qu’elles accomplissent pour les atteindre.

Concentrez-vous sur ce qui compte vraiment

Faites la distinction entre les résultats business et les projets/initiatives/fonctionnalités car c’est déjà une énorme victoire. Concentrez-vous sur moins de priorités et travaillez en équipe pour les atteindre pour une réelle valeur ajoutée pour l’organisation et ses employés.

Suivez les progrès, apprenez et adaptez-vous

Assurez-vous que tous les objectifs et initiatives sont transparents. Encouragez les équipes à vérifier régulièrement les progrès et à noter pourquoi une initiative a fonctionné ou pas pour référence future afin de partager les apprentissages au sein de l’organisation.

Découvrez plus d’informations sur les OKRs.

 

Management des risques et IA

PDF téléchargeable gratuitement.

Le NIST des États-Unis a publié, après de longues discussions et des ébauches revues, son cadre de management des risques (Risk Management Framework / RMF) pour l’IA.

Vous pouvez le télécharger en version anglaise.

Le RMF de l’IA fait référence à un système d’IA comme un système conçu ou basé sur une machine qui peut, pour un ensemble donné d’objectifs, générer des résultats tels que des prédictions, des recommandations ou des décisions influençant des environnements réels ou virtuels. Les systèmes d’IA sont conçus pour fonctionner avec différents niveaux d’autonomie (Adapté de : Recommandation de l’OCDE sur l’IA: 2019 ; ISO/CEI 22989: 2022).

Tout n’est pas nouveau

Beaucoup d’éléments sont tirés des normes ISO de management des risques, ainsi que d’autres guides de gestion des risques de l’Agence.

Livre sur Amazon

Autre avis : Si vous voulez avoir un bon aperçu des risques liés à l’IA vus par un expert pseudo-sceptique, lisez Gary Marcus. Avec ses co-auteurs, il a écrit de nombreux articles et un livre très respecté intitulé : « Rebooting AI: Building Artificial Intelligence We Can Trust »

Il n’est pas surprenant que Gary Marcus voit un grand risque dans l’acceptation des résultats des modèles de réseaux neuronaux qui interrogent de très grands ensembles de données, car, comme il le dit, sans connectivité contextuelle aux modèles d’IA symboliques (le genre que vous obtenez avec les algorithmes de symboles, comme celui de l’algèbre), il y a peu de moyens (pour l’instant) de valider la « vérité ».

Selon lui, le risque de systèmes comme ceux récemment introduits par OpenAI et autres est qu’avec ces outils, le coût de production d’absurdités sera ramené à presque zéro, ce qui facilitera l’inondation d’Internet et des réseaux sociaux de mensonges à des fins économiques et politiques.

 Vous pouvez également commencer par un podcast ou une transcription de l’interview de Gary Marcus avec Ezra Klein.

Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes

 

Pourquoi les détails sont-ils importants ?

Les détails comptent. Ils sont importants dans tous les domaines de notre vie. Les détails font souvent la différence entre un résultat positif et un résultat infructueux.

Why Details Matter par Steve Keating

https://stevekeating.me/2024/01/22/why-details-matter/

Quand j’étais beaucoup plus jeune, j’ai sauté d’un avion qui fonctionnait parfaitement. Ce n’était pas exactement par choix, je suis allé dans une école militaire et cela faisait partie du contrat. Quand ils vous disaient de sauter, vous sautiez. Mais j’ai appris ce fait peu connu : Vous n’avez pas besoin d’un parachute pour sauter d’un avion. Vous pouvez simplement ouvrir la porte et sauter. En fait, il est plus rapide d’atteindre le sol sans parachute.

Il y a cependant un petit détail à garder à l’esprit. Si vous avez l’intention de sauter d’un avion une deuxième fois, un parachute est fortement recommandé. Si vous manquez ce petit détail, le résultat de votre premier saut sera loin d’être idéal. Mais encore une fois, le saut lui-même est tout à fait faisable sans parachute.

Les détails comptent. Ils sont importants dans tous les domaines de notre vie. Les détails font souvent la différence entre un résultat positif et un résultat infructueux.

Voici quelques-unes des raisons pour lesquelles les petits détails peuvent être si importants.

  • Précision : Prêter attention aux détails garantit l’exactitude de l’information, de la communication et de l’exécution. Cela permet d’éviter les erreurs et les malentendus, ce qui permet d’obtenir de meilleurs résultats dans presque toutes les situations.
  • Clarté : Les détails apportent de la clarté et du contexte à n’importe quelle situation. Ils aident à comprendre les subtilités et les nuances d’un sujet, ce qui permet aux autres de comprendre plus facilement votre message ou vos actions.
  • Résolution de problèmes : Dans la résolution de problèmes, l’attention portée aux détails est cruciale. Elle vous permet d’identifier les causes profondes des problèmes et de les traiter efficacement. Ignorer les détails peut entraîner des solutions superficielles qui ne résolvent pas les problèmes sous-jacents.
  • Prise de décision : Dans les processus de prise de décision, les détails aident à évaluer les options et à prédire les résultats potentiels. Prendre des décisions éclairées nécessite une compréhension approfondie des détails entourant une situation.
  • Professionnalisme : Le souci du détail est souvent associé au professionnalisme. Que ce soit sur le lieu de travail, à l’université ou dans la vie personnelle, être méticuleux dans votre travail démontre un engagement envers la qualité et l’excellence.
  • Prévention des erreurs : De petits détails peuvent parfois avoir un impact significatif. En prêtant attention aux détails, vous pouvez détecter les erreurs potentielles avant qu’elles ne dégénèrent en problèmes plus importants.
  • Efficacité : Avoir une bonne compréhension des détails permet un travail plus efficace et plus effectif. Cela minimise le besoin de refaire ou de corriger, ce qui permet d’économiser du temps et des ressources.
  • Communication : Une communication claire et détaillée est essentielle pour transmettre des idées avec précision. Les détails permettent d’éviter les erreurs d’interprétation et de s’assurer que le message est compris comme prévu.
  • Établir la confiance : Prêter constamment attention aux détails permet d’établir une relation de confiance avec les autres. Que ce soit dans les relations personnelles ou les collaborations professionnelles, les gens ont tendance à faire confiance aux personnes qui font preuve d’un engagement envers la précision.

Les détails font toujours la différence. Parfois, la différence est petite, parfois elle est énorme. Prêter attention aux petites choses donne aux gens l’assurance que vous ferez également attention aux plus grandes choses. Sauter des détails a un impact négatif sur votre crédibilité. Tant dans votre vie personnelle que dans votre carrière. Lorsque les détails passent à travers les mailles du filet, il est très probable que votre réussite globale dans la vie passe également à travers les mailles du filet.

Faites attention aux petites choses et de grandes choses se présenteront probablement à vous.

The Standard for Program Management, Fifth Edition (2024) : Quoi de neuf ?

Un nouveau standard ou une nouvelle édition d’un standard existant sont toujours de grandes nouvelles pour les professionnel(le)s du Management de projets, programmes et portefeuilles. Voici l’annonce du The Standard for Program Management, Fifth Edition (2024).

https://www.pmi.org/pmbok-guide-standards/foundational/program-management-5th-edition

Les programmes sont essentiels pour les organisations qui cherchent à atteindre leurs objectifs stratégiques. De l’initiation à la réalisation des bénéfices, les directeurs, directrices et managers de programme et leurs équipes unissent leurs efforts dans plusieurs projets interconnectés pour créer plus de bénéfices que la somme de leurs composantes.

Visitez la page du site PMI.ORG

The Standard for Program Management – 5ème édition fournit un cadre et des conseils aux personnes et organisations qui cherchent à améliorer leurs pratiques de management de programme. Cette édition identifie 8 principes qui guident le comportement au sein du management de programme, faisant de cette publication un standard fondé sur des principes.

Un nouveau domaine de performance de management de programme, la collaboration, est introduit et incorporé à un contenu réorganisé pour une approche simplifiée de la lecture, de la compréhension et de l’utilisation du standard. Ce domaine favorise l’interaction entre les cinq autres domaines afin de manager le programme dans son ensemble en s’appuyant sur les capacités spécifiques de l’être humain telles que l’intégration, la création de synergies et l’optimisation des ressources.

Offert par le Project Management Institute® (PMI), il s’agit d’un outil puissant pour toutes les organisations, quelles que soient leurs méthodes de réalisation de projets. Il s’agit d’une ressource inestimable pour les managers et directeurs/directrices de portefeuilles, de programmes et de projets, ainsi que pour les cadres supérieurs et les parties prenantes.

Ce standard s’aligne bien sûr étroitement sur les connaissances décrites dans A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – septième édition et sur les autres standards du PMI.

“PMI”, the PMI logo, “PMP”, “PMBOK” and “Project Management Institute” are registered marks of Project Management Institute, Inc.

Apprenez à déchiffrez certaines clauses de vos contrats avant de les signer !

Le Journal du Contract Management n°13

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.

  1. Assurances
  2. Pénalités
  3. 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.

Téléchargez gratuitement le Jounal du Contract Management

Les métriques de flux et leur importance pour les équipes et les managers

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

https://www.jrothman.com/newsletter/2024/01/flow-metrics-and-why-they-matter-to-teams-and-managers/   

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

  1. WIP / Work In Progress, Travail en cours : Tout le travail qui est en cours : commencé et pas encore terminé.
  2. Throughput, Débit : Nombre d’items de travail qu’une équipe/responsable peut effectuer par unité de temps.
  3. Cycle Time, Temps de cycle : Le temps nécessaire pour libérer de la valeur, en tant que tendance.
  4. 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 Timesont 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 :

Livre sur Amazon
Livre sur Amazon

 

Outil Pratique pour Manager de projet : Le PDCA dans votre plan d’action excel selon Christian Hohmann

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.

  1. L’affichage automatique des symboles PDCA
  2. L’indicateur PDCA 
  3. 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.

plan do check act
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

7 tendances en matière de management de projets

Voici 7 des tendances les plus en vogue dans le domaine en pleine évolution du management de projet.

Trends in Project Management par Bonnie Biafore

https://www.bonniebiafore.com/trends-in-project-management/

Voici 7 des tendances les plus en vogue dans le domaine en pleine évolution du management de projet.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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 !

Cet article fait partie de Bonnie’s Project Pointers newsletter series.

CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

 

Impact de la phase de test d’acceptation par les utilisateurs (User Acceptance Testing / UAT) sur l’agilité de l’organisation par Sam Adesoga

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

https://www.valuehut.co/blog/impact-of-user-acceptance-testing-phase-on-organisation-agility

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.

 

Que savez-vous de la CSRD et de la CSDDD ? Peut-être comme moi pas grand chose avant de découvrir ce livre blanc…

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.

Lisez le livre blanc: https://greenprojectmanagement.org/gpm-standards/white-papers

Partenaire de DantotsuPM, visitez le site pour toutes les formations certifiantes proposées. En particuliers celles sur Prince2.

Après le « green-washing », le « AI-Washing » (ou Intelligence Artificielle à toutes les sauces) !

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.

AI-Washing de Richard Mironov

https://www.mironov.com/ai-washing/

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 ?
  • Notre ensemble de données est-il biaisé ou faussé ?  Les préjugés raciaux dans la reconnaissance faciale, les données hypothécaires incorporant des décennies de pratiques illégales, etc. suggèrent que nous supposons souvent aveuglément que les données sont propres et éthiquement neutres.
  • 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.

 

𝐑𝐞́𝐯𝐨𝐥𝐮𝐭𝐢𝐨𝐧𝐧𝐞𝐳 𝐯𝐨𝐭𝐫𝐞 𝐠𝐞𝐬𝐭𝐢𝐨𝐧 𝐝𝐞 𝐩𝐫𝐨𝐣𝐞𝐭 𝐚𝐯𝐞𝐜 c𝐞 𝐠𝐮𝐢𝐝𝐞 𝐂𝐡𝐚𝐭𝐆𝐏𝐓 de Anne Emmanuelle Kouadio

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

  1. Des 𝐞𝐱𝐩𝐥𝐢𝐜𝐚𝐭𝐢𝐨𝐧𝐬 𝐝𝐞́𝐭𝐚𝐢𝐥𝐥𝐞́𝐞𝐬 sur ChatGPT et comment il révolutionne la gestion de projet.
  2. Plus de 𝟒𝟎 𝐩𝐫𝐨𝐦𝐩𝐭𝐬 𝐩𝐞𝐫𝐬𝐨𝐧𝐧𝐚𝐥𝐢𝐬𝐞́𝐬 pour simplifier et optimiser vos tâches quotidiennes.
  3. 4 𝐞́𝐭𝐮𝐝𝐞𝐬 𝐝𝐞 𝐜𝐚𝐬 illustrant l’impact réel de ChatGPT dans des situations concrètes.
  4. Une « 𝐜𝐡𝐞𝐚𝐭𝐬𝐡𝐞𝐞𝐭 » pour une mise en pratique immédiate et efficace.
  5. 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.

Découvrez le guide ici

𝐋𝐞 𝐠𝐮𝐢𝐝𝐞 𝐞𝐬𝐭 𝐠𝐫𝐚𝐭𝐮𝐢𝐭 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.

ChatGPT pour les gestionnaires de projet

Anne Emmanuelle Kouadio

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.

email: anne@ispeak.digital

Cycle en V : Ni ange ni démon !

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.

Jean-Charles SAVORNIN, MGP, PMP

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

« Quelle est la meilleure méthodologie pour gérer un projet au sein des DSI ? » par Ophélie Gomes

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

Précédent billet d’Ophélie: Êtes-vous fait pour le rôle de manager / chef de projet ? Comment présenter votre rôle différemment ?

Le modèle de mise à l’échelle de Spotify : Spotify ne l’utilise pas, vous ne devriez pas non plus !

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

https ://agilepainrelief.com/blog/the-spotify-model-of-scaling-spotify-doesn’t-use-it-neither-should-you.html (en anglais seulement)

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.

En conséquence, la plupart des tentatives  du modèle Spotify sont en fait du Cargo Cult.

Figure 1 – La célèbre image de Henrik Kniberg & Anders Ivarsson dans https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

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.
  • Améliorer le flux du travail dans le système. Les outils comprennent la limitation  du travail en cours (ou WIP),  le développement des compétences croisées et l’élimination des goulots d’étranglement. Vous pouvez mesurer le succès de cette opération à l’aide  du temps de cycle et du délai d’exécution.

Comment évaluer les facteurs macro-financiers dans la gestion de projet ? par Osvaldo Lagares

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.

Boostez la puissance des jalons

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…

Boost the Power of Milestones  par Bonnie Biafore

https://www.bonniebiafore.com/boost-the-power-of-milestones/

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 ?

Pour en savoir plus sur les jalons, consultez le cours de Bonnie Project Management Foundations: Schedules course.

Précédent billet de Bonnie Biafore sur ce thème :

Comment bien utiliser des jalons pour suivre la progression du projet ?

Avez-vous suffisamment de maturité digitale pour réussir votre projet numérique ?

Votre entreprise est-elle prête pour ce nouveau projet numérique/digital que l’on vous charge de réussir ?

« 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

  1. un coût maîtrisé,
  2. un délai convenu et
  3. 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.

Sur un plan plus opérationnel, pour la mesurer, le livre La transformation digitale pour tous ! (Michaël Tartar – David Fayon, éditions Pearson, 2022) propose une décomposition en 115 indicateurs de maturité digitale organisés en 6 leviers de digitalisation

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.

4 conseils pour l’élaboration d’un plan de management des risques.

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

https://projectriskcoach.com/risk-management-plan-for-project/

Livre sur Amazon

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

https://www.youtube.com/watch?v=-R6cYj8tb9A

* 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 ?

#2 – Déterminez ce qu’il faut inclure

Un autre dicton de Stephen Covey est :

« Commencez avec la fin à l’esprit. »

Que comprendra votre plan de management des risques  ?

Voici quelques composants usuels :

  1. Contexte des risques liés au projet
  2. Méthodologie
  3. Rôles et responsabilités
  4. Calendrier des activités de management des risques
  5. Catégories de risque
  6. Attitude à l’égard du risque, appétit et tolérance
  7. Format de rapport
  8. 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 :

  1. Finances et comptabilité
  2. Technologie de l’information
  3. Design
  4. Test
  5. Analyse d’affaires
  6. Opérations
  7. Ressources humaines
  8. 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 :

  1. Entrevues
  2. Réunions
  3. 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.

Dans le développement de produit : Le produit est la variable.

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.

The Product is the Variable par Jeff Gothelf

https://jeffgothelf.com/blog/the-product-is-the-variable/

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 :

  1. 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.
  2. 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.