Maîtriser le dérèglement du périmètre (avec Suze Haworth)

Lisez la transcription :

Nous expérimentons la transcription de nos podcasts à l'aide d’un logiciel. Veuillez excuser d’éventuelles fautes, car le bot ne corrige pas 100 % du texte.

Ben Aston :

Bienvenue sur le podcast DPM, où nous allons au-delà de la théorie pour vous donner des conseils d’expert afin de mieux piloter vos projets digitaux. Merci de nous écouter. Je suis Ben Aston, fondateur du Digital Project Manager. S’il y a bien une chose qui déraille pratiquement tous les projets, c’est le dérèglement du périmètre. On sait tous que c’est mauvais. On sait tous qu’on veut l’éviter. Mais comment le reconnaître dans toutes ses formes ? Quelles en sont les causes ? Qui est responsable ? Et surtout, comment l’appréhender concrètement ? Aujourd’hui toutes ces questions trouveront réponse dans ce podcast où nous parlons de la gestion et de la maîtrise du dérèglement du périmètre projet.

Ce podcast est sponsorisé par Clarizen, leader des logiciels de gestion de projet d’entreprise.

En savoir plus sur clarizen.com

Je suis accompagné aujourd’hui de Suze Hayworth. Suze fait partie de nos experts DPM sur The Digital Project Manager, et travaille comme cheffe de projet digital senior indépendante à Londres, au Royaume-Uni. Elle a plus de 10 ans d’expérience en agence et a été confrontée à de nombreux dérapages de périmètre, c’est donc la personne idéale pour échanger avec nous aujourd’hui. Bienvenue Suze.

Suze Hayworth :

Bonjour Ben.

Ben Aston :

Alors Suze, on discutait juste avant d’enregistrer. Peux-tu nous décrire les types de projets sur lesquels tu travailles actuellement et certains des défis que tu rencontres ?

Suze Hayworth :

Oui, donc en ce moment je travaille en freelance dans une agence à Londres, à cheval entre un rôle de cheffe de projet senior et de directrice de projets sur deux comptes. Pour l’un d’eux, je travaille pour IKEA, donc un grand distributeur e-commerce. On est en train de leur réaliser un design system, une sorte de prototype de design system. Je m’occupe également d’un autre détaillant e-commerce en Grande-Bretagne. Beaucoup de projets retail donc en ce moment. Oui, et pour les défis, c’est toujours difficile d’en parler... surtout quand ils sont en cours. Oui, je crois que...

Ben Aston :

C’est ce client pénible ?

Suze Hayworth :

Non, au contraire. Ils sont vraiment, je dois le dire.

Ben Aston :

Tu peux !

Suze Hayworth :

C’est vrai, ce sont de très bons clients en ce moment. Je trouve que la particularité en gestion de projet c’est de travailler avec l’humain. J’adore collaborer avec des personnes, aux profils variés et avec leurs particularités. Mais il arrive parfois d’être un peu frustré parce qu’on peine à obtenir leur contribution ou qu’ils ne veulent pas faire certaines tâches. Ça m’est arrivé récemment.

Ben Aston :

Que du bonheur ! Parle-nous de ce projet de design system, car je trouve ça intéressant et c’est le genre de projets qui deviennent de plus en plus courants. Avant, chacun traitait chaque projet comme un cas unique et les créatifs voulaient être créatifs… Explique-nous c’est quoi un design system ? Et quel est le projet sur lequel tu travailles justement et comment vous déployez cela ?

Suze Hayworth :

C’est vraiment passionnant, effectivement, parce que comme tu le dis, les design systems prennent de plus en plus d’importance dans le monde digital. Ils sont en quelque sorte une bibliothèque de styles pour la conception numérique des entreprises et marques. Ils définissent une base de composants, modules, templates que tout designer ou développeur travaillant avec la marque peut utiliser pour leurs conceptions et leur code. Cela fait office de socle, ce qui favorise l’efficacité, la réutilisabilité du code et des designs, ainsi que la cohérence au sein de l’entreprise.

Pour une marque comme IKEA, gigantesque, avec quantité d’agences et d’équipes, un design system fixe des standards pour tous. Par exemple, un bouton ou un appel à l’action peut rester cohérent entre plateformes, appareils, applications — quels que soient les supports utilisés.

Ben Aston :

Peux-tu nous détailler le processus de gestion de ce genre de projets ? Car cela peut vite tourner au projet « sans fin ». Par quoi avez-vous commencé, et sur quoi itérez-vous ? Où se fixe la limite du produit ?

Suze Hayworth :

Pour IKEA, beaucoup de marques réalisent ce travail en interne. IKEA a fait le choix de se tourner vers l’externe pour bénéficier d’un regard neuf. Nous avons commencé par une analyse conceptuelle des principes de design digital d’IKEA. C’était plus stratégique pour définir l’expérience et les principes de conception fondateurs. Ensuite, on a posé les bases du design avec certains éléments fondamentaux : couleurs, typographie, grilles… que l’on fait ensuite évoluer.

Puis, nous avons procédé à des tests utilisateurs sur différents supports d’IKEA, et depuis, nous créons et construisons des composants spécifiques, hébergés sur un site de design system — interne pour l’instant. L’objectif est de mettre en place un prototype polyvalent à faire évoluer en solution complète en fin de cette phase.

Ben Aston :

Cette solution complète, c’est en quelque sorte un guide de style vivant comprenant des extraits réutilisables, des modèles prêts à l’emploi ? C’est la finalité recherchée ?

Suze Hayworth :

Tout à fait, tout design system doit être une entité évolutive, donc sans fin prédéfinie. Il ne s’agit pas d’un produit figé. Nous venons tout juste de démarrer, en posant les principes, les fondations, quelques composants. Ensuite, il faudra grouper ces composants, développer des modules, des templates, et réfléchir aux méthodes d’adoption et de diffusion dans l’entreprise. C’est un projet énorme vu le nombre d’acteurs. Même après presque un an, on a juste amorcé le projet.

Ben Aston :

Ça doit être passionnant. Alors, as-tu récemment découvert des outils qui te facilitent la vie, ou des lectures intéressantes à conseiller ?

Suze Hayworth :

Non, pas vraiment de nouveaux outils dernièrement, je reste fidèle à mes classiques... Mais c’est un peu ironique, vu que je suis moi-même sur un podcast, d’avouer que j’écoute beaucoup plus de podcasts ! Avant, j’écoutais surtout de la musique dans les transports, mais désormais, j’utilise mon temps différemment, pour apprendre, en écoutant un panel de podcasts. C’est formateur et utile (même si je reste debout par manque de siège !).

Ben Aston :

Lesquels t’ont marquée ou aidée ?

Suze Hayworth :

D’abord, évidemment, le podcast The Digital Project Manager. J’en ai aussi enregistré un récemment pour... c’était le Drunken… Après ma session au DPM Summit, j’en ai discuté avec eux. The Bureau of Digitalists à ce même sommet sort de bons épisodes aussi, et Brett qui l’organise en publie un intitulé Sprints and Milestones — lié à son livre sur le pilotage de projets digitaux, une bonne ressource.

Ben Aston :

Super, les podcasts. Récemment, j’ai découvert Blinkist. Honnêtement, je n’écoute guère de podcasts autres que le mien… Mais j’achète souvent des livres sans jamais les lire. Blinkist propose des résumés de livres très condensés, à lire ou à écouter en 15 minutes environ.

Suze Hayworth :

Oui, j’en ai entendu parler !

Ben Aston :

Oui, quelqu’un lit les idées clés du livre ou les résume. On peut accélérer l’écoute, donc en 7 minutes, tu auras capté l’essentiel du livre !

Suze Hayworth :

C’est génial. Je veux essayer, car j’essaie aussi de lire plus de livres.

Ben Aston :

Voilà mon astuce lecture du moment : Blinkist. Bon, recentrons-nous sur le dérèglement du périmètre. Pour ceux qui ignorent ce que c’est, pourquoi s’y intéresser ?

Suze Hayworth :

C’est quand votre périmètre – les livrables, les fonctionnalités prévues – s’élargit par rapport à ce qui a été convenu, sans prise en compte du temps ou du budget supplémentaire. Le projet peut alors déraper sous différentes formes et les délais ou livrables s’étaler insidieusement.

Ben Aston :

Donc, c’est du travail non prévu qui va impacter le budget, le planning, et le volume de travail. Il y a plein de raisons à ces dérapages, non ?

Suze Hayworth :

Oui, énormément.

Ben Aston :

Selon toi, quelles sont les causes les plus fréquentes… et les plus insidieuses ?

Suze Hayworth :

Celles que j’observe le plus souvent : le manque de clarté du périmètre au départ. Si les livrables ou le cahier des charges sont trop vagues, chacun peut interpréter à sa façon ce qui doit être livré. Le projet peut alors gonfler sur des bases imprécises.

D’abord, il faut poser clairement le périmètre dès le début. Et s’assurer que les personnes qui approuvent comprennent vraiment le périmètre grâce à des points synthétiques et une explication approfondie, pas seulement la lecture d’un document ! Une bonne pratique est de parcourir ces points ensemble, lors d’une réunion, pour s’assurer que tout est compris.

C’est là que j’ai vu de nombreux problèmes, lorsque le périmètre était accepté, mais que certains attendaient autre chose que ce qui était explicitement mentionné.

Ben Aston :

Oui. On manque de clarté au départ, on utilise des formules vagues (« on va créer un modèle de page ») sans définir le contenu du modèle. Ou bien les problèmes de compréhension client : il ne saisit pas ce qu’implique un « template ».

Suze Hayworth :

Exactement. Il y a deux aspects : bien définir les livrables, mais aussi vérifier la compréhension réelle de la personne qui valide le périmètre, car même en étant explicite, elle peut s’imaginer obtenir autre chose que ce qui est écrit.

Ben Aston :

Tu viens d’évoquer le manque de clarté, l’incompréhension client. Ce sont vraiment les deux principales origines du dérèglement.

Mais parlons du côté insidieux. As-tu déjà vu du dérèglement du périmètre particulier, ou arrivé par surprise ? Donne-nous des exemples issus de ton expérience.

Suze Hayworth :

On associe rarement le dérèglement du périmètre aux équipes internes, mais elles peuvent aussi provoquer ces écarts. Si tout le monde n’a pas une compréhension claire des tâches, chacun peut, sans s’en rendre compte, allonger son timing ou ajouter des éléments non prévus (designers, développeurs, etc.). Parfois, certains veulent montrer ce dont ils sont capables ou ajoutent des fonctionnalités non validées.

Cela surprend d’autant plus que, normalement, tout le monde est censé être sur la même longueur d’onde ! Il y a aussi le cas de parties prenantes internes qui souhaitent « en donner plus » par souci relationnel avec le client. Ou qui s’engagent sur des sujets dont vous n’étiez même pas au courant… C’est là que le côté sournois du dérèglement intervient.

Ben Aston :

Je confirme, c’est souvent en interne que le « dérèglement furtif » survient, surtout en stratégie, UX ou design. Mais aussi en développement lorsque quelqu’un veut en mettre plein la vue (« gold plating »), sans qu’il soit jamais question de prendre en charge ce travail supplémentaire.

Suze Hayworth :

Exactement.

Ben Aston :

Qui assume alors la responsabilité ? Quand chacun travaille avec sa propre interprétation, ou lors de la phase QA, où les critères d’acceptation n’ont pas été bien formalisés (« ne testez pas sur IE9, on s’en fiche ! »), mais l’équipe QA continue tout de même. Ou les développeurs corrigent des « bugs » non prioritaires... Tu as déjà vécu ça, non ?

Suze Hayworth :

Complètement. La QA est une source majeure de dérive. C’est vraiment difficile d’anticiper le temps nécessaire à la QA, notamment si l’on n’a pas fixé en amont un « device matrix », les critères d’acceptation, et les niveaux de priorité des bugs. Certains problèmes peuvent être considérés comme non bloquants. Bref, il faut cadrer un maximum en amont pour réduire l’incertitude, mais aussi communiquer ouvertement avec le client : l’informer dès qu’il y a une dérive sur un navigateur particulier (comme IE) et proposer des alternatives. Exposer rapidement les problèmes permet de trouver ensemble des solutions.

Ben Aston :

C’est très utile. Nous avons évoqué plusieurs causes de dérives : manque de clarté, équipes qui « se lâchent », QA… Maintenant, parlons responsabilités. Pour mieux gérer le sujet, il faut comprendre qui est à l’origine de la dérive : le client qui fait des demandes en plus (par ignorance ou mauvaise compréhension), ou nos propres équipes internes (par sur-qualité ou sur-engagement).

Tu évoques aussi d’autres acteurs : prestataires tiers, utilisateurs, et nous-mêmes, chefs de projet. Jusqu’à quel point sommes-nous responsables ?

Suze Hayworth :

L’objectif n’est pas de blâmer, mais d’identifier les risques : analyser qui, dans le projet, pourrait provoquer un dérapage, c’est déjà de la gestion des risques. Concernant nous-mêmes : on a tendance à regarder à l’extérieur (équipe, client, etc.), mais il faut se remettre en cause, notamment sur la communication lors des incidents. Je l’admets, ça m’est déjà arrivé : parfois on essaie de régler les soucis sans les signaler, pour éviter de transmettre trop de mauvaises nouvelles au client.

On veut préserver la dynamique du projet, avancer malgré tout, et « rattraper » ici ou là, mais sans toujours exposer ces points au client. Je pense qu’il faudrait être plus transparent et ouvert, et apporter systématiquement des solutions alternatives en cas de problème détecté — cela facilite grandement les échanges.

Si la dérive est interne, essayez de rectifier, mais informez le client. Si le client veut en ajouter, ne cherchez pas à le satisfaire au détriment du projet : étudiez l’impact, proposez des alternatives, discutez avec le client sur ce qu’on peut déprioriser éventuellement.

Ben Aston :

On a déjà sauté à la partie « gestion » du problème !

Suze Hayworth :

Désolée.

Ben Aston :

C’est très bien, car après constat, il faut gérer la dérive. Mais on peut aussi agir en amont : si nous chefs de projet sommes plus clairs sur nos périmètres (« scope »), on diminue les risques. Demandez l’avis d’un autre chef de projet, du QA, voire d’un analyste métier pour mettre en lumière les angles morts du périmètre, afin d’avoir un document plus solide.

Il ne suffit pas de balancer un cahier des charges au client et attendre qu’il signe. Il faut vraiment passer en revue avec lui, dialoguer et éviter ainsi beaucoup de malentendus dès le départ.

J’aime beaucoup ta vision sur la gestion — il n’est pas question de « mettre sous le tapis » ! Très souvent, il y a une tentation de ne pas faire remonter les soucis pour préserver la relation client, mais à terme, c’est pire. Être transparent, proactif, analyser les impacts, c’est vraiment la bonne posture.

Autre point : souvent, le dérèglement du périmètre est présenté comme une pathologie des projets en cycle en V (« waterfall »), mais est-ce aussi un problème pour les projets agiles ? À quoi faut-il être particulièrement attentif en agilité, où on itère et où le périmètre est plus « flou » ?

Suze Hayworth :

Oui, je veux vraiment souligner cela. On voit souvent le dérèglement du périmètre très négativement, car on cherche à tout figer, à bannir tout changement. Mais l’un des principes fondateurs de l’agilité justement, c’est d’embrasser le changement, car c’est ça qui crée un meilleur produit ou service au final. Le changement devient donc une bonne chose – tout dépend ensuite de comment on le gère.

Dans le cas d’un projet agile, par exemple en scrum, on définit le contenu du sprint, le backlog. Mais le client peut vouloir injecter des demandes supplémentaires en plein sprint ; cela peut impacter les livrables prévus. Il faut alors réajuster : réorganiser les priorités, vérifier l’effort, valider les compromis entre stories/épopées. L’avantage de l’agile, c’est qu’avec des cycles courts et des livraisons régulières, on peut ajuster plus facilement.

Ben Aston :

Effectivement, la clé c’est peut-être de transformer la discussion. Changer de posture et adopter celle — tu en parles — qui intègre le changement. Très souvent, cette discussion autour du périmètre a une connotation négative (« ça va coûter plus cher, allonger le planning… »). Mais si on travaille dans un dialogue ouvert, en co-priorisation avec le client, on arbitre régulièrement ensemble ce qui compte le plus. Le changement n’est alors plus une menace, mais une opportunité : au lieu de se rendre compte trop tard qu’une fonctionnalité prioritaire n’entre plus dans le budget, on adapte ensemble et on évite les chocs de dernière minute (« soit vous payez plus, soit on dépriorise »).

Suze Hayworth :

Tout à fait. Il faut que cette discussion autour des livrables soit continue, car tout doit répondre à l’intérêt de l’utilisateur final. Si on vous demande quelque chose de nouveau, demandez-vous d’abord quelle valeur ça peut apporter, pourquoi ce besoin émerge, et adaptez en conséquence la priorisation — ce qui, in fine, bénéficie vraiment aux utilisateurs. Passez ces nouvelles demandes au filtre du sens pour aboutir aux arbitrages pertinents.

Ben Aston :

Excellent conseil. Dialoguer, penser « utilisateur ». Cette conversation résonne beaucoup chez moi. Le dérèglement du périmètre n’est pas forcément une catastrophe ; au contraire, cela peut être bénéfique pour le client, l’utilisateur, et même l’équipe. Il s’agit de l’accueillir et de le canaliser.

Pour ceux qui se disent : « mes projets sont systématiquement en dépassement de budget, en retard, avec de grosses dérives de périmètre », c’est un cas assez répandu chez les PMs juniors. Quelle est ta première recommandation pour reprendre le contrôle ?

Suze Hayworth :

Si vous arrivez sur un projet qui démarre, misez tout sur le chiffrage, l’estimation du temps, et la définition du périmètre. Assurez-vous que l’estimation est collective, réaliste, avec l’équipe, et aussi précise que possible vu qu’il s’agit malgré tout d’estimations. Cela permet de ne pas se retrouver dépassé par le budget ou les délais.

Si vous arrivez sur un projet en cours, faites un état des lieux, analysez l’avance/retard, estimez le reste à faire. Puis dialoguez avec le client pour l’informer des problèmes et échanger des solutions — toujours dans la transparence.

Ben Aston :

Super. Merci beaucoup Suze de t’être jointe à nous. Ce fut un plaisir. Suze, en tant qu’experte DPM, interviendra d’ailleurs dans notre prochain cours qui démarre en février : « Maîtriser la gestion de projet digital ». Si vous sentez que vous avez besoin d’une formation PM, foncez ! Il s’agit d’une formation intensive de sept semaines, qui alterne vidéos interactives, devoirs, webinaires, discussions de groupe et sessions de coaching optionnelles. Rendez-vous sur DPMschool.com pour vous inscrire avant que le cours ne soit complet. Si vous souhaitez enrichir ce débat sur le périmètre projet, commentez cet article et rendez-vous dans la rubrique ressources du site pour rejoindre notre équipe Slack où foisonnent de discussions passionnantes. Merci pour votre écoute, à bientôt.