Travailler à Reculons pour Aller de l’Avant (Avec Jeff Gothelf de Gothelf.co)

Lisez la transcription :

Nous testons la retranscription de nos podcasts avec un logiciel. Merci de nous excuser pour les éventuelles fautes, le robot n'est pas fiable à 100 %.

Ben Aston :

Pour être honnête. Est-ce que vos projets atteignent vraiment ce que vous espériez ? Pourraient-ils ou devraient-ils ? Pourquoi ? Est-ce peut-être parce que vous n’avez pas planifié ? Ou alors que vous n’avez pas bien géré votre équipe. Ou peut-être parce que vous avez eu du mal à gérer vos parties prenantes. Peut-être l’ensemble de ces raisons. Peut-être parce que vous n’étiez pas tous parfaitement alignés sur le but ultime et la vision du projet. Alors restez avec nous pour écouter le podcast d’aujourd’hui. Si vous souhaitez apprendre comment travailler à rebours pour avancer avec plus de confiance sur de bons projets, réduire la probabilité d’échec, et augmenter vos chances de réussite.

Merci d’écouter. Je suis Ben Aston, fondateur du Digital Project Manager. Bienvenue sur le podcast DPM. Notre mission est d’aider les chefs de projet à réussir et d’aider les personnes qui gèrent des projets à mieux les livrer. Nous sommes là pour vous aider à passer au niveau supérieur dans la gestion de vos projets.

Visitez thedigitalprojectmanager.com pour découvrir nos formations et ressources proposées via l’adhésion. Ce podcast est sponsorisé par Clarizen, le leader du logiciel de gestion de projets et portefeuilles d’entreprise. Rendez-vous sur Clarizen.com pour en savoir plus.

Aujourd’hui, je suis accompagné de Jeff Gothelf. Jeff enseigne aux cadres et équipes, via des conseils à distance, des ateliers de coaching, des interventions et des livres, comment se concentrer sur le client, apprendre de ses erreurs et créer une culture agile qui améliore en continu produits, services, et la façon dont on travaille.

Il est co-auteur de plusieurs livres que vous avez lus ou du moins dont vous avez entendu parler : Sense and Respond, Lean UX, Lean versus agile vs. design thinking. Il a récemment cofondé Sense and Respond Press, une maison d’édition dédiée aux ouvrages modernes sur les transformations d’entreprise. Bonjour Jeff, merci beaucoup d’être avec nous aujourd’hui.

Jeff Gothelf :

Bonjour Ben, merci de m’accueillir.

Ben Aston :

J’aimerais commencer par parler des projets. Je sais que tu es plutôt orienté produit, mais pour nous, les chefs de projet, gérer des projets peut faire partie d’un programme global ou d’une feuille de route produit.

Je me demande ce que tu en penses. En tant que chefs de projet, comment pouvons-nous, nous et nos équipes, nous orienter vers une démarche plus itérative ? Je sais que tu as écrit un article sur les 10 principales répliques du type « l’Agile c’est bien, mais ça ne marchera pas ici ». Donc j’aimerais parler de certains défis que nous rencontrons en tant que chefs de projet digitaux et pourquoi.

Fondamentalement, je pense que les clients avec lesquels nous travaillons, toutes les parties prenantes, aiment l’idée de travailler en agile. On peut débattre de ce que signifie « agile », que ce soit en termes de mode de livraison ou plus largement d’un état d’esprit. Parlons plutôt de cet état d’esprit qui accompagne l’agilité.

Je pense qu’il y a trois principaux défis. D’abord, la défiance des clients, puis des exigences trop rigides, et enfin le manque de budget et de temps. Les clients veulent être agiles, mais n’ont pas toujours le budget ou le temps de l’être.

Les clients imposent des exigences trop détaillées, et puis la confiance fait défaut – ils ne font pas totalement confiance à l’équipe ou à l’agence pour lâcher prise et s’en remettre au processus. Voilà trois grands défis. Par lequel veux-tu commencer ?

Jeff Gothelf :

Parlons d’abord du changement de mentalité. C’est le point le plus crucial, en particulier pour les chefs de projet digitaux qui doivent vraiment comprendre cela. Si on veut réussir à construire de bonnes équipes, de bons produits, de bons services, de bonnes entreprises et de bons clients/utilisateurs, il faut comprendre la différence fondamentale dans le développement de produit digital aujourd’hui.

La différence essentielle aujourd’hui par rapport à il y a 10 ou 15 ans, c’est que les logiciels aujourd’hui sont en amélioration continue. On n’achète plus un logiciel en boîte au magasin : on le télécharge ou on s’abonne, on l’installe, et il se met à jour en permanence.

Il s’améliore en continu. On ne va pas acheter la prochaine version de Facebook en magasin, ou la nouvelle version de Pinterest ou d’Amazon. Non, les logiciels évoluent, s’améliorent, changent au fil du temps. C’est donc la différence fondamentale entre la logique « projet » et la logique « produit ». Les projets sont finis, les produits évoluent en permanence.

Et aujourd’hui, on construit ces systèmes continus – à chaque cycle (appelle-le un sprint, une itération, peu importe), on a le choix : ajouter de nouvelles choses, optimiser ce qui existe déjà, ou retirer ce qui ne sert plus.

Il y a toutes sortes d’actions possibles, mais c’est à peu près dans ces trois catégories. Cette idée que les projets s’arrêtent quand ils sont livrés, c’est fini, non : le lancement n’est que le début de la conversation avec votre audience cible, ce n’est jamais la fin du produit.

Ben Aston :

Exactement. L’un des problèmes que rencontrent les chefs de projet digitaux, c’est d’expliquer à leurs clients comment s’impliquer dans une démarche plus agile, une manière de collaborer différente, où on leur dit : « Payez pour une équipe dédiée pendant un certain temps et collaborons ensemble. » On lance votre site, puis on va l’itérer, comme tu le dis pour les logiciels.

Mais tout cela repose sur la confiance, n’est-ce pas ? La personne qui paie doit être certaine d’obtenir de la valeur à la fin du processus. Comment, en tant que chefs de projet, peut-on accompagner le client à travers cette défiance, lorsqu’il préfère dire « je vous donne 100 000 dollars, mais je veux être sûr que j’aurai tout ce que je veux à la fin du processus. Mais je veux aussi que vous soyez agiles. » Ils ont leur liste d’exigences, et on leur explique qu’on ne peut garantir chaque livrable à l’avance, car on va chercher ce qui génère le plus de valeur, qu’on va prioriser, livrer, tester, apprendre. Cela demande de la confiance. Quels conseils donnerais-tu pour établir cette confiance alors que les livrables sont imprécis ?

Jeff Gothelf :

Oui. Il y a beaucoup à développer ici. Commençons par la pièce fondatrice. Il faut vous demander, en tant que prestataire ou partenaire, dans quel métier vous êtes. Êtes-vous dans le métier d’aider vos clients à atteindre des résultats, ou dans celui de livrer un cahier des charges à la lettre ? Car, comme tu l’as dit, il y a un décalage fondamental entre « voici le cahier des charges » et « soyez agiles ». Ça n’a aucun sens.

Il y a un spectre, que m’a transmis mon ami et collègue Jeff Patton, qui aide bien à clarifier ce sujet : à une extrémité, il y a le « médecin », à l’autre, le « serveur ».

En tant que prestataire, demandez-vous où vous vous situez sur ce spectre. Si vous êtes serveur, votre boulot est d’apporter exactement ce qu’on commande. Que le client aime ou pas, mange ou pas, ce n’est pas votre problème. Il a demandé un steak, une salade et un coca, vous les livrez. Beaucoup d’organisations font cela. Donnez-moi 100 000€, je vous fais une arche.

À l’inverse, le médecin : on ne va pas voir le médecin pour lui dicter médicaments, vaccins, traitement, et qu’il exécute. Il conseille pour améliorer vos indicateurs de santé, vos résultats. Ainsi, où vous situez-vous ?

Il est bien plus facile d’être agile du côté « médecin » que du côté « serveur », car les critères de réussite sont fondamentalement différents. Côté serveur, on mesure le livrable : ai-je eu ce que j’ai commandé, à l’heure et au prix prévu ? Oui, alors c’est réussi – aucune agilité là-dedans. Côté médecin, ce sont les résultats, le changement de comportement des clients, la variation de leurs comportements. A-t-on augmenté leur panier moyen, leur fidélité, etc. ? C’est là que l’agilité excelle, quand il y a de l’incertitude sur ce qui va vraiment livrer la valeur espérée.

Agilité et agile ne peuvent entrer en jeu que si on déplace ce qu’on livre et la manière de le livrer du serveur vers le médecin.

Ben Aston :

Donc il s’agit, pour moi, de passer du « client / partie prenante tout-puissant » à une relation basée sur la confiance et le contrôle partagé. Quand tu accompagnes des organisations dans ce changement, comment les encourages-tu à oser l’inconnu, à dépasser le cahier des charges tout fait ?

Et souvent, on s’en tient à des solutions évidentes, ce qui entraîne des réponses faciles : c’est le prochain projet ou itération. Mais comment fais-tu pour faire comprendre la valeur d’une mentalité plus agile et pour ouvrir leur appétit au modèle du « médecin consultant » plutôt que « serveur » ?

Jeff Gothelf :

Pour cela, il faut savoir poser la question du pourquoi, de façon respectueuse et sans risquer de perdre le contrat. Quand un client vient et dit : « Je veux ces 10 fonctionnalités pour vendredi, combien ça coûte ? », il faut pouvoir lui demander pourquoi il veut ces fonctionnalités.

On travaille alors avec le client pour transformer ces exigences en une problématique. On doit formuler le problème que l’organisation ou l’équipe tente de résoudre. Par exemple : « J’ai besoin d’une appli mobile pour vendredi, combien ça côte ? » Vous demandez « pourquoi ? » et la réponse est « car le chiffre d’affaires mobile est en baisse, on doit l’augmenter ». Ok, donc le vrai problème est : « On veut augmenter de 15 % le CA mobile ». Voilà, vous passez de « construire une appli mobile » à « augmenter de 15 % le chiffre d’affaires mobile ».

Ce changement retire l’exigence technique du débat et oblige l’équipe à être agile : tester, expérimenter, apprendre, itérer, améliorer, jusqu’à obtenir la hausse des 15%. C’est ça, le critère de succès, pas la livraison de l’application elle-même. Il y a un risque immense à supposer qu’une liste de fonctionnalités va produire le résultat espéré – souvent, on se trompe.

En fait, des produits managers expérimentés te diront : un bon product manager a raison 30 % du temps. Ça vaut aussi pour les parties prenantes et les clients.

Donc, si on se trompe 70 % du temps, n’est-il pas logique de préférer une approche qui permet de découvrir vite la réponse plutôt que de commander à l’aveugle une app toute bleue avec cinq fonctionnalités pour jeudi ? C’est tout l’intérêt ici.

Ben Aston :

Oui, je trouve ça très pertinent. Reformuler la demande client en problème à résoudre, explorer le « pourquoi » : ça déplace la conversation du cahier des charges figé vers la découverte de solutions qui créent de la valeur, testé, itérées, apprises. Et ça répond au challenge des exigences rigides. Je voudrais aborder un troisième point : le manque de budget et de temps – penses-tu que ce soit une raison valable pour que l’agile ne marche pas ?

Jeff Gothelf :

Pour moi, il y a une incompréhension fondamentale de ce que les processus agiles apportent. Ce n’est pas une question de budget ou de temps, mais de gestion des risques. Il s’agit de dire : au lieu de passer trois mois sur l’idée supposée du succès, on va vérifier rapidement si on est sur la bonne voie et ajuster le tir si besoin.

Le principe, c’est que si l’équipe ajuste son cap grâce à la réalité du marché, alors elle est agile. Et ça n’a rien à voir avec le budget ou le temps. L’alternative, c’est quoi ? Payer 75 000 euros pour une appli en un mois – mais si ça ne fonctionne pas, tant pis. C’est ça, le risque d’une démarche projet en mode ‘waterfall’, top-down, prescriptive.

On pense savoir ce qu’il faut, quand et comment, et c’est un raisonnement extrêmement risqué. Même un excellent chef de produit, client, ou sponsor a raison une fois sur trois.

Ben Aston :

Oui, mais cela dépend aussi de qui fait la demande. Dans ton exemple, le steak, la salade, le coca pour 30 $, peut-être, c’est ce que je veux, même si ce n’est pas ce qu’il me faut. Je veux seulement qu’on m’apporte mon steak, salade, et coca.

Jeff Gothelf :

Exactement ! Et dans ce cas, tu t’adresses à un serveur. Mais si tu vas voir ton médecin et lui demandes la même chose, il ne va pas te servir cela. Parce que son objectif, ce n’est pas de te satisfaire à court terme, mais d’améliorer ta santé.

C’est là la différence fondamentale. Un serveur se fiche de ta santé : il exécute ta commande. La plupart des prestataires traditionnels ne saisissent pas ce que veut dire être agile – ce n’est pas seulement une méthode mais un changement total de business model. Et c’est difficile pour eux de l’accepter et de s’y adapter.

Ben Aston :

Oui, et puis pour l’équipe qui exécute, il faut aussi de la maturité.

Jeff Gothelf :

Exactement.

Ben Aston :

C’est vraiment, je pense, une question de maturité. Pour ceux qui travaillent en agence, avec des clients qui réclament seulement un steak, une salade et un coca pour jeudi, c’est un défi de taille. C’est donc un vrai exercice de reformulation, d’enlever la posture de serveur, et de mettre la casquette du médecin.

Jeff a publié un excellent article sur la centration client et la planification de projets centrés client, avec une version actualisée de la technique du communiqué de presse du futur, inspirée de la méthode Amazon Working Backward, focalisée comme on l’a dit sur les résultats.

C’est une affaire de gestion des risques. C’est une affaire de collaboration. Je ne vais pas révéler l’article ici, lisez-le sur thedigitalprojectmanager.com. Mais je voudrais savoir, d'après ton expérience, en quoi cette approche aide-t-elle ? On a l’impression que c’est un exercice sympa, mais concrètement, qu’est-ce que ça donne d’utiliser cet outil du communiqué de presse du futur ?

Jeff Gothelf :

La première chose, c’est que ça oblige à imaginer le futur en situation de réussite, et ça force à réfléchir à ce qui a permis ce succès. La variante présentée dans l’article met le client au cœur : il ne s’agit plus seulement de livrer un super système ou de gagner beaucoup d’argent, mais d’analyser le changement de comportement et les résultats obtenus côté client.

Pour y parvenir, il faut songer à la valeur qu’on va délivrer au client, organisation comprise, surmonter des défis de collaboration, puis voir comment cela bénéficie au business.

Ce type d’exercice, en mode prémortem, vise à imaginer le lancement réussi : comment saurez-vous que c’est un succès ? Qu’avez-vous dû surmonter ? Rares sont les équipes qui abordent ce sujet dès le départ. En général, on lance le projet, on le livre : succès = livré à temps et dans le budget. Là, on cherche à bâtir un processus qui améliore durablement la vie du client, et, grâce à ça, le business aussi.

Si on a cette discussion préalable, elle influence tout le déroulé du projet. Ce communiqué de presse du futur devient un filtre pour choisir : « Cela va-t-il contribuer à notre objectif ? », « Est-ce en phase avec nos valeurs et idéaux ? », sinon, on peut choisir de ne pas le faire. C’est puissant.

Ben Aston :

Donc, pour ceux qui n’ont pas lu l’article, on projette dans le futur – état cible, boule de cristal. On évalue l’adéquation « produit-marché », la désirabilité : est-ce que cela répond vraiment à un vrai besoin ? Est-ce viable (business model) ? Est-ce faisable ? Bref, c’est un prisme pour voir s’il faut foncer, avec empathie en se mettant à la place des utilisateurs.

Mais ce que je me demande, c’est une démarche imaginative : comment valider, dans la vraie vie, ce communiqué de presse ? Tu dis qu’on a raison que 30 % du temps, quid des 70 % restants ? Quelle place pour l’erreur ou l’imprécision de l’outil ?

Jeff Gothelf :

C’est un objectif, c’est une aspiration de groupe. On essaie de prédire le succès, les obstacles : on raconte l’histoire. Il faut ensuite agir en cohérence avec cette histoire tout le long. Évidemment, certains éléments ne se réaliseront pas et c’est normal : tant que le changement est basé sur une justification claire et objective, aucun problème. L’important, c’est de tenir l’histoire comme cap tant qu’on n’a pas de preuve contraire du marché.

Ben Aston :

On va alors changer de cap en fonction des leçons tirées ?

Jeff Gothelf :

Oui, on ajuste ce qui n’est plus valable ou pertinent – ce n’est pas de déplacer la ligne d’arrivée, c’est adapter le but à la réalité, une réalité qu’on ne connaissait pas au départ.

Ben Aston :

Y a-t-il des travers à éviter dans cette approche ? Cela peut-il limiter la créativité ou être un frein ? Pourquoi avoir modifié la technique Amazon, et quels risques y vois-tu ?

Jeff Gothelf :

Le plus gros défi : les équipes ne sont souvent pas assez ambitieuses. Elles produisent un document prudent, « sandbagging » (fixer la barre pour assurer la réussite facile). Ainsi, elles n’anticipent pas les vrais obstacles, ni ne se fixent de seuil d’aspiration élevé. Amazon a connu du succès avec ce process, il y a plein d’articles à ce sujet. Ma version insiste sur deux points : la prise en compte des résultats (changements mesurables dans le comportement client) plutôt que seuls des avantages business ; et l’identification des défis de collaboration, indispensables dans une grande organisation (juridique, finances, marketing, ops, conformité…), car rien ne sort sans action inter-départements. Il est essentiel d’y penser d’avance car personne ne travaille en solo.

Ben Aston :

Je trouve cela très puissant. Il ne s’agit pas que d’objectifs et de metrics, mais bien de la mise en œuvre concrète, souvent la source des échecs (communication, collaboration). Lisez l’article de Jeff sur la démarche « Travailler à rebours pour avancer », vous y trouverez de précieux conseils !

Je voudrais maintenant parler un peu méthode, un sujet qui te passionne. Tu as travaillé en conseil, en startup, en agence, et maintenant à ton compte, ce qui t’a permis de voir ce qui fonctionne… ou non.

Comment as-tu vu évoluer les méthodes ? Comment perçois-tu la maturation de l’agilité, l’apparition de frameworks idéation/livraison ? Quel futur perçois-tu pour eux ?

Jeff Gothelf :

À terme, l’agilité, minuscule, deviendra la norme dans les organisations partout sur la planète. Et je pense que la pandémie qu’on vit accélérera ce phénomène. Les entreprises déjà en chemin, capables de sentir et réagir, survivront. Les autres auront du mal, voire disparaîtront. Vu le rythme du changement et la volatilité des marchés et du monde, l’agilité devient incontournable. Une organisation monolithique risque de couler comme un roc, alors qu’une organisation constituée d’équipes semi-autonomes, capables d’apprendre, partager et s’ajuster, peut traverser la tempête.

Dans 20 ans parlera-t-on encore de sprints, burn-down charts, backlog ? Peut-être, peut-être pas – le vocabulaire changera, mais pas l’approche. Je ne vois pas un avenir où la centration client, l’amélioration continue, l’apprentissage permanent ne seraient pas la norme.

Ce sont les philosophies de fond de l’agilité. C’est là que va l’avenir, selon moi – la crise va même accélérer tout ça.

Ben Aston :

Justement, sur les frameworks et leurs noms. Tu es passionné par Lean, tu en as beaucoup parlé et écrit. Il existe maintenant des techniques précises : design thinking, service design, parfois très dirigistes. Chacun défend son process de livraison. Quel recul as-tu, sur leur utilité et leur articulation ? Faut-il tout garder ? Pas évident de généraliser, c’est vrai. Mais quelle est ta philosophie sur agile vs design thinking ?

Jeff Gothelf :

J’ai écrit un livre court « Lean vs Agile vs Design Thinking ». Le propos central : ce sont des noms différents pour des philosophies très similaires. Les activités et leur appellation changent, le fond est commun. Vous devez en choisir une ou composer la vôtre, mais le but n’est pas d’appliquer bêtement une recette. L’objectif, c’est d’augmenter l’agilité de l’organisation. Au fond, il s’agit d’apprendre à devenir un « chef ».

Autre métaphore culinaire : le débutant suit une recette à la lettre – c’est normal pour les équipes débutantes. Puis, à force, on enrichit la recette, on la personnalise pour des résultats meilleurs, ou une équipe plus efficace. Finalement, on devient pro : plus besoin de recettes, on sait improviser en connaissant le résultat à viser. Voilà la maturité ultime.

Quiconque s’attache à une recette risque de rater sa cible, car on souhaite juste cocher les étapes, alors que la destination c’est l’agilité, pas la recette.

Ben Aston :

Oui, et je pense que c’est pour ça qu’il faut se méfier des remarques du type « mais ce n’est pas comme ça qu’il faut faire ». Le vrai intérêt, c’est de pouvoir adapter le process lui-même : il doit être itérable. Le respect aveugle de la procédure, c’est risqué. D’ailleurs, tu as écrit « Sense and Respond », sur l’écoute client et la création de nouveaux produits – on a évoqué ces thèmes aujourd’hui. Tu parles de techniques : y en a-t-il qu’on n’a pas abordées et qui, selon toi, feront la différence dans ce monde COVID ?

Jeff Gothelf :

Pour moi, le point que les organisations négligent le plus longtemps, mais qui est clé, c’est la structure d’incitation et les critères de performance. On peut appliquer toutes les méthodologies, mais si je suis payé pour « livrer une fonctionnalité » alors je ne viserai que cela ! Le modèle de récompense doit encourager la curiosité, l’apprentissage, l’amélioration.

Le cœur du sujet, c’est : comment mesurer la réussite ? Comment transformer la mesure pour encourager le bon comportement, l’amélioration, la réussite du produit et du service ? Si on ne l’incentive pas, rien ne changera. Sans cela, l’agilité disparaît dans la nature. Les entreprises modèles l’ont compris – c’est difficile et risqué, mais cela en vaut la chandelle : mieux pour les produits, les clients et les collaborateurs.

Ben Aston :

Tu parles d’OKR, ou de manière plus large ?

Jeff Gothelf :

Je parle de lier les incitations aux OKR. Les OKR deviennent la mesure du succès de l’équipe, voire entrent dans l’évaluation et la rémunération.

Ben Aston :

Oui, récemment j’ai vu l’utilisation de job scorecards au lieu de fiches de poste, très utile pour descendre la mesure au niveau individuel et motiver le changement, si les bons metrics sont choisis. Il est difficile parfois de définir le bon metric – on se rend compte à l’usage si on s’est trompé. Mais la concentration sur les résultats via ce focus, c’est très précieux ! Pour conclure, parlons de ton cours sur Scrum et des frameworks.

Scrum, framework agile, ton cours sur l’UX avec Scrum répond à la question « comment fait-on design/UX/recherche dans Scrum » – problématique fréquente en agence. Scrum semble très adapté au développement, mais c’est plus complexe pour la phase de recherche/conception UX. Faut-il être dans le même sprint ? Être en avance ? Pour ceux qui veulent intégrer Scrum mais hésitent sur la phase amont UX/recherche, comment articuler tout cela au niveau macro ?

Jeff Gothelf :

C’est toute la question à laquelle le cours « professional scrum with UX » (PSU) répond. On prend un regard pragmatique sur Scrum et on observe comment l’ajuster aux pratiques nécessaires mais non prévues initialement. On traite du backlog, des user stories, de qui fait quoi, de comment s’organise la part d’apprentissage face à la livraison, etc. En bref, c’est une question de collaboration interdisciplinaire.

Le designer doit être membre à plein temps de l’équipe, et la découverte (design/recherche) doit avoir autant d’importance que la livraison. Il y a un va-et-vient entre découverte et livraison, et parfois la recherche est menée par d’autres que les designers – il faut l’accepter. Voilà, globalement, ce que couvre le cours.

Ben Aston :

Intéressant. Mon reproche habituel envers Scrum, c’est sa prescription excessive. On a vu qu’il faut voir le framework comme un point de départ, à faire évoluer. Mais Scrum reste directif, et il est difficile pour toi d’arbitrer entre « on suit une procédure » et « il doit y avoir adaptation » – comment as-tu conçu ta méthode ?

Jeff Gothelf :

L’avantage de collaborer avec scrum.org, c’est qu’ils étaient prêts à réviser leur position. Ailleurs, c’était « voici Scrum, il est figé, adaptez-vous ». Là, ils l’ont accepté et c’est déjà un progrès. Ensuite, ce n’est qu’une recette, soyons clairs. Si vous ne savez pas comment faire pour l’instant, démarrez avec cette recette. Vous l’adapterez ensuite selon vos besoins et spécificités. Mais commencez par là, puis améliorez-la. C’est ce qui a fonctionné pour nous.

Ben Aston :

Oui, c’est très utile. Pour quiconque veut mettre en place une démarche plus agile, il faut voir ces frameworks comme des recettes et comprendre qu’on n’est pas évalué sur la stricte conformité, mais sur l’atteinte des résultats recherchés. Ce qui est le fil conducteur de cette discussion. Merci beaucoup Jeff d’avoir été avec nous !

Jeff Gothelf :

Avec plaisir Ben, c’était un plaisir. Merci pour l’invitation.

Ben Aston :

Super. Et vous, qu’en pensez-vous ? Quels sont vos hacks, conseils et astuces pour bien livrer ? Avez-vous testé la technique du communiqué de presse ? Partagez dans les commentaires vos échecs et vos succès !

Pour aller plus loin et progresser dans votre métier, rejoignez la communauté DPM Membership sur thedigitalprojectmanager.com/membership : accès à notre Slack, templates, ateliers, sessions AMA, heures de bureau, e-books, etc. Et si ce podcast vous a plu, abonnez-vous ! Retrouvez toutes nos ressources sur thedigitalprojectmanager.com. D’ici là, merci pour votre écoute.