Démarrez vos projets du bon pied (avec Suze Haworth)

Lisez la transcription :

Nous testons la transcription automatique de nos podcasts avec un programme informatique. Veuillez excuser d'éventuelles fautes, le robot n'étant pas fiable à 100%.

Ben Aston :

Bienvenue sur le podcast DPM où nous allons au-delà de la théorie pour vous offrir des conseils d’expert en gestion de projets digitaux. Merci de nous écouter. Je suis Ben Aston, le fondateur de The Digital Project Manager.

Nous savons tous que le démarrage d’un projet est fondamental pour sa réussite, mais c’est aussi une phase délicate. Il y a beaucoup d’ambiguïté, beaucoup de confusion, pas mal de désaccords et énormément d’incertitudes. En tant que chefs de projet, c’est à nous de lancer le projet et de maintenir l’élan — bonus si on parvient vraiment à le diriger dans la bonne direction. Mais que pouvons-nous faire concrètement pour nous assurer que l’on part sur de bonnes bases ? C’est exactement le sujet du podcast d’aujourd’hui. Continuez à écouter pour découvrir comment bien démarrer vos projets.

Aujourd’hui, je suis accompagné de Suze Haworth. Bonjour Suze.

Suze Haworth :

Bonjour.

Ben Aston :

Suze fait partie de nos expertes DPM chez The Digital Project Manager. Elle travaille comme cheffe de projet digital senior freelance à Londres. Suze, peux-tu nous dire quelques mots sur certains des projets sur lesquels tu as travaillé récemment ?

Suze Haworth :

Oui. Donc je suis actuellement freelance PM. Il y a quelques semaines, j’ai terminé une mission, plutôt longue d’ailleurs, en agence. J’y avais deux rôles principaux. L’un ressemblait davantage à une direction de programme sur un compte client. C’était pour Specsavers, une grande marque de lunettes de détail au Royaume-Uni, présente aussi dans les pays nordiques et en Australie. Il s’agissait de gérer un.e chef.fe de projet sur tout le volet créatif et expérience utilisateur, sur le digital Specsavers. C’est donc un programme assez important. J’ai aussi travaillé sur un projet pour Ikea. Il s’agissait d’un projet de conception et de développement d’un prototype pour un système de design pour la marque.

Ben Aston :

Super. Donc Specsavers, c’est plutôt un projet e-commerce et d’optimisation de conversion ?

Suze Haworth :

Oui. Cela dépendait du marché, mais en général, ils ne vendent pas de lunettes en ligne à cause de certaines réglementations. L’objectif principal était donc de pousser les gens à prendre rendez-vous et à se rendre en boutique. Mais oui, il s’agissait essentiellement d’optimisation de la conversion.

Ben Aston :

Quels sont les aspects difficiles sur ces projets ? Quels ont été les défis auxquels tu as été confrontée, avec le projet en lui-même, le client ou l’équipe ? Je pense que c’est intéressant que chacun se rende compte que ses problèmes ne sont pas uniques. Alors, qu’est-ce qui t’a semblé difficile ?

Suze Haworth :

Oui. Pour le programme Specsavers, c’était une période très intéressante car j’ai commencé en mars, au début de la nouvelle année, en même temps que nous avons mis en place une toute nouvelle façon de travailler. Avant, nous fonctionnions comme agence de design en collaboration avec leur agence de développement. Nous étions intégrés dans leurs équipes scrum, avec un binôme designer/UX dans chacune des équipes, sur l’ensemble des flux de travail. On a finalement décidé d’extraire nos designers et UX de ces équipes scrum et de constituer notre propre équipe côté agence. Nous avons donc mis en place une approche à double filière : une « discovery track » en amont du « delivery track », ce dernier restant organisé en équipe de développement scrum.

Cela nous a permis de prendre le temps de faire de l’expérimentation utilisateur, de l’exploration, d’émettre des hypothèses, de tester auprès des utilisateurs, et d’analyser davantage les données pour orienter la création de solutions vraiment adaptées. Ça a été un vrai défi, mais très excitant, de mettre cette nouvelle façon de fonctionner en route et de la faire adopter.

Ben Aston :

Alors ton rôle, c’était… tu avais la casquette « product owner » du coup ? Car tu as deux flux parallèles : stratégie, UX, design d’un côté, et je suppose que c’est là que les tests utilisateurs ont lieu pour identifier les besoins, et de là partent les priorités, qui sont ensuite transmises au pôle design/UX, puis basculées en développement. C’est bien ça ?

Suze Haworth :

Oui. Ce qu’on constatait, c’est que lorsque les binômes design/UX étaient dans le scrum, devoir livrer en deux semaines était vraiment limitant, et une grosse partie du temps était consacrée à des aspects techniques (planification de sprint, résolution de bugs, etc.) au détriment du centrage client. Retirer nos équipes de ce schéma et constituer un flux dédié a permis d’avoir plus de temps pour l’analyse de données existantes, la recherche, la formulation et la validation d’hypothèses, avec des prototypes ou tests UX rapides selon les besoins. Résultat : le processus devient plus fluide, on ne crée plus ce que les clients ne veulent pas, et on anticipe les décisions UX/design avant la mise en production. On impliquait bien sûr de la technique côté discovery, mais surtout pour valider la faisabilité après validation utilisateur. Bref, c’était une manière d’optimiser la chaîne, tout en restant focalisé sur le besoin utilisateur.

Ben Aston :

Je crois que beaucoup d’agences qui font du scrum se reconnaîtront dans ce défi : scrum n’est pas le seul mode de gestion agile mais ça reste l’approche majoritaire, et la grande difficulté, c’est qu’on se demande ce que doivent faire les profils UX/design en sprint. Il y a des modèles où ces gens-là travaillent avec quelques sprints d’avance, mais alors rien n’est « terminé » à chaque sprint. Or, le but d’un sprint, c’est d’obtenir à la fin un résultat à livrer qui respecte les critères d’acceptation… ce qui est très dur à faire en passant de la stratégie au design UX et au développement en deux semaines.

Donc j’aime cette idée de mener deux flux parallèles : une fois les solutions validées, le PO les fait descendre dans le backlog de dev. On a deux backlogs différents, un côté stratégique (« est-ce la bonne chose à faire ? ») et l’autre « nous savons que c’est la bonne voie, donc on construit ». Cela permet de surmonter certains défis structurels.

Suze Haworth :

Exactement, ça garantit que ce qu’on livre a été validé côté utilisateur, ce qui limite le gaspillage et structure l’approche en mode « lean ». C’est forcément positif à mon sens.

Ben Aston :

Très bien. Parlons maintenant de l’amorçage de projet. Concernant Ikea ou Specsavers, étais-tu présente dès le tout début ?

Suze Haworth :

Pour Specsavers, cette nouvelle méthode a été définie avant mon arrivée et la mission était prévue sur l’année. Je suis arrivée peu après la définition de l’approche et du cadrage, mais il fallait ajuster à la réalité en avançant. Le process a pas mal évolué après la mise en œuvre. Concernant Ikea, j’ai rejoint le projet en cours, à la 2e étape, donc après le lancement initial.

Ben Aston :

C’est courant pour les PMs de récupérer un projet en cours, ce qui accentue la confusion. Le projet passe de la main du business, du commercial ou du management de compte au PM, qui hérite souvent d’un cadrage inabouti. En initiation, il faut souvent faire le point dès la transmission, pas toujours dès le tout début.

Tu abordes dans ton article la gestion des personnes, des processus et des livrables — donc qui, comment, quoi. En tant que PM qui démarre ou reprend, que fais-tu pour bien orchestrer la dimension « personnes », et « prendre la température » en amont pour bien lancer le projet ?

Suze Haworth :

Il y a plusieurs groupes à prendre en compte. Le premier, c’est l’équipe : qui va travailler sur le projet ? Au lancement, il faut identifier et planifier les ressources, mais aussi penser à qui est le plus pertinent, selon son expérience et ses méthodes de travail. Même si on n’a pas toujours le choix, anticiper permet de désamorcer d’éventuels soucis. Impliquer très tôt les personnes dans le projet est clé : ce que j’ai remarqué en travaillant avec des designers, développeurs, QA, etc., c’est que ce qu’ils détestent souvent, c’est d’être mis sur un projet déjà cadré sans avoir eu voix au chapitre, juste pour exécuter. Retirer leur autonomie ne fonctionne jamais.

Donc, si le temps et le budget le permettent, même une implication légère au tout début change tout. Après le kickoff interne, il faut leur demander leurs vues, leurs attentes, leurs idées sur le projet.

Ben Aston :

Oui. Impliquer dès que possible et planifier l’équipe en amont, c’est essentiel pour obtenir leur adhésion. Sinon, chacun réagit comme nous en tant que PM quand un projet atterrit sur notre bureau, fruit d’une réflexion incomplète d’autrui. On se dit : « Pourquoi cette approche ? Je ne l’aurais pas fait comme ça. » Donner ce sentiment de propriété collective produit de bien meilleurs résultats.

Suze Haworth :

Exactement.

Ben Aston :

Parlons du processus ensuite. Une fois l’équipe identifiée, comment exploiter au mieux ses qualités pour délivrer le projet ? Tu évoquais le cas Specsavers, mais quel est ton secret pour aligner tout le monde sur le process, la méthodologie, les outils, etc. malgré les inévitables désaccords ?

Suze Haworth :

Il est rare de trouver une méthode qui convienne à tout le monde parfaitement. Il y aura toujours des tensions. Parfois, le schéma est imposé par l’agence, l’organisation ou le client ; d’autres fois, on peut choisir et alors il faut rechercher le bon fit. Lors du kickoff interne, il convient d’expliquer les grandes lignes du process — s’il est imposé — et de chercher à obtenir l’adhésion de l’équipe dès le départ.

Mais il me semble fondamental de faire évoluer le processus en avançant. Il ne faut pas s’entêter dans une méthode inefficace. L’équipe doit savoir qu’on s’ajuste si nécessaire, signaler ce qui coince (outils, communication, etc.) afin qu’on puisse s’adapter collectivement.

Ben Aston :

Là-dessus, la flexibilité me paraît essentielle — trop souvent, on entend « Non, ce n’est pas du scrum », « Ce n’est pas agile », ou encore « C’est trop en cascade »… Peu importe. L’important, c’est ce qui marche pour l’équipe, le projet, le client. Il ne faut pas être dogmatique. Avec nos moyens humains et le contexte, quelle est la meilleure approche délivrable ? Chaque projet est différent, impossible d’appliquer une méthode unique — sauf pour du run ou des petites évolutions où standardiser a du sens. Sinon, c’est à remettre à plat à chaque fois.

Donc… on a parlé des personnes et de la structuration de l’équipe/parties prenantes, du processus et de la flexibilité nécessaire. Mais le plus difficile au lancement reste souvent de clarifier ce qu’on va livrer : on hérite d’un scope flou ou de besoins clients mal définis. Comment lever l’ambiguïté sur les livrables/les objectifs et passer de la zone grise à une vision plus nette ?

Suze Haworth :

Cela dépend du type de projet. Idéalement, il ne faut pas un cadre trop rigide d’emblée, car tout change très vite et le livrable peut évoluer considérablement. Je préfère un cadrage ouvert à l’adaptation. Mais parfois, on reçoit un cadrage extrêmement figé. Dans tous les cas, il faut alimenter la discussion, clarifier progressivement les attentes client (besoins utilisateurs, enjeux métier…). Puis on partage et enrichit ces besoins avec l’équipe. Il s’agit d’impliquer plusieurs membres clés dès cette étape, pour commencer à baliser ce que sera le projet.

Ben Aston :

J’ai expérimenté que dans ces premières réunions de cadrage, réunir tout le monde, prendre un demi-jour pour faire du paper board, mettre plein de post-its et pointer haut niveau la solution, cela génère une compréhension partagée dès le début, car chacun a des visions différentes. En matérialisant et en affichant visuellement, on déclenche ces échanges nécessaires (« ah, je croyais que ça voulait dire ça », « non, pour moi, c’est autre chose »). Cela permet d’identifier précisément les zones d’ambiguïté pour y revenir côté client après.

Ce schéma général clarifie la vision et devient une référence commune (« Où est la photo du tableau blanc déjà ? »). Ça modélise comment tout s’articule et ce qu’on doit livrer.

Enfin, établir d’emblée au moins une architecture possible ferme le cercle sur le début et la fin du projet — cela permet de baliser l’enveloppe globale et de fixer le périmètre collectif.

Suze Haworth :

Tout à fait. Les ateliers avec l’équipe, puis le client, sont aussi très utiles : on comprend mieux le contexte côté client et vice-versa. On peut d’ailleurs faire un atelier interne, puis co-animer un atelier client d’une demi-journée.

Ben Aston :

Nous avons vu ce qu’il faut gérer : qui (l’équipe), comment (le process/la méthode) et quoi (architecture, budget, échéances, critères de succès…). Mettre tout cela sur un même tableau au début, même si ça change après, est extrêmement utile.

Sauf qu’en amorçage, on se trouve parfois à concevoir l’architecture d’une solution avant la signature, ce qui crée une tension : jusqu’où aller ? Faut-il avancer à fond ou rester prudent et progresser pas à pas pour éviter le hors sujet ou le blocage ? Comment gères-tu cette tension entre avancer assez et ne pas foncer tête baissée alors qu’on n’a pas toutes les garanties ?

Suze Haworth :

J’adopte une approche plutôt prudente, en restant transparente. Si le client tarde à valider ou s’il y a des rejets sur le scope, j’alerte d’emblée sur les risques de retard global. On peut continuer à avancer de façon modérée, juste assez pour garder le cap et l’implication de l’équipe. Sinon, il y a un risque que les contributeurs — ou même le client ! — décrochent. Maintenir la dynamique est important, même si c’est à « bas bruit » tant que le lancement n’est pas formel.

Ben Aston :

Parlons des difficultés classiques — le manque de dynamique au début : parfois, on présente un projet, puis rien ne se passe à cause d’incertitudes ou de questions en suspens. Comment gères-tu cette situation, quand tout semble s’arrêter ?

Suze Haworth :

C’est difficile, surtout si les ressources sont déjà planifiées, mais que tu n’as pas le go officiel pour engager du temps. Si possible, il faut réserver un minimum de temps pour que l’équipe reste mobilisée sur le sujet, via de la veille, de la recherche sur la concurrence, l’analyse de données, etc. Cela permet de les garder impliqués en douceur jusqu’au vrai lancement.

Ben Aston :

Parfois, même juste réunir toute l’équipe dans une courte réunion pour faire un point d’étape (« ce n’est pas lancé tout de suite mais voici les dernières infos ») aide à garder l’engagement, pour éviter que le projet sorte de leur radar.

Suze Haworth :

Il n’y a rien de pire que le silence radio complet, puis de revenir trois semaines ou un mois plus tard en lançant le projet. Il faut leur communiquer ce qui se passe côté client dans l’intervalle, expliquer les blocages, la date potentielle de reprise, et ce qu’on peut faire en attendant. Garder le lien avec l’équipe est indispensable.

Ben Aston :

Dernier point — beaucoup de chefs de projet reprennent un projet à mi-chemin, hérité du travail d’un.e autre, avec un plan « personnes, process, produit » tout fait mais à livrer sous leur responsabilité. Des conseils pour sortir du chaos ?

Suze Haworth :

C’est sans doute l’une des difficultés majeures, car il est assez rare de partir d’une feuille blanche : c’est souvent le management ou le commercial qui a cadré au début. On hérite parfois d’un coût cadré avec un périmètre très flou, qu’il faut recaler au budget réel. Il faut donc analyser les marges de manœuvre — si le budget est déjà validé, voir ce qu’on peut réellement livrer, et si besoin, ouvrir une discussion sur le périmètre ou les délais pour rester réaliste.

Quand on récupère un projet démarré par un autre, deux choses me paraissent clés : collecter un maximum d’informations sur l’historique, le client, ce qui a été livré à date, etc., puis enclencher un mini-kickoff, même en cours de route : rassembler l’équipe, rencontrer le client, acter ce point de reset pour tout remobiliser et identifier ce qui ne fonctionnait pas ou doit perdurer. Ça ne prend pas forcément beaucoup de temps, mais c’est crucial.

Ben Aston :

Oui, avoir le courage d’instaurer ce « reset » est puissant. En posant toutes les questions, même celles qui paraissent bêtes ou évidentes, on déniche beaucoup de flou dont personne n’avait eu conscience, ou que d’autres se posaient aussi. Même avec un workshop de démarrage, chacun dévie progressivement dans sa compréhension. Le reset permet d’aligner à nouveau les visions, de traiter les angles morts et d’éviter les mauvaises surprises. Cela révèle les vrais défis latents.

Suze Haworth :

Il ne faut jamais hésiter à poser toutes les questions — je dis toujours cela aux nouveaux PMs. Mieux vaut être curieux au début que silencieux et avoir ensuite de mauvaises surprises. Multiplier les questions est le meilleur réflexe.

Ben Aston :

Excellent conseil pour lancer un projet dans de bonnes conditions. Au fond, la réussite en initiation vient de la communication : poser les questions difficiles, même si elles gênent, c’est la clé pour apporter de la clarté et réduire l’effort gaspillé. Merci beaucoup Suze d’avoir partagé ces conseils avec nous !

Suze Haworth :

Merci, c’était un plaisir.

Ben Aston :

En tant qu’experte DPM, Suze participera à notre nouveau cours dès février : « Maîtriser la gestion de projets digitaux », une formation accélérée de sept semaines avec des vidéos interactives, des tables rondes et du coaching en option. Si vous voulez comprendre comment mieux démarrer vos projets, rendez-vous sur DPMSchool.com pour vous inscrire avant la clôture des places. Et pour enrichir la discussion sur l’amorçage de projet, commentez ce post ou rendez-vous dans l’espace ressources de The Digital Project Manager pour rejoindre notre communauté Slack. Vous y trouverez de nombreuses discussions sur l’initiation et la gestion de projet. D’ici là, merci de votre écoute.