Construire et faire évoluer des équipes de gestion de projet (avec Brian Kessman de Lodestar Digital)

Lire la transcription :

Nous testons la transcription de nos podcasts à l’aide d’un logiciel. Veuillez excuser les éventuelles fautes, le robot n’est pas toujours exact à 100%.

Ben Aston :

Merci de nous rejoindre, je suis Ben Aston et voici le podcast du digital project manager. Aujourd’hui je suis accompagné de Brian Kessman et nous allons parler de l’article qu’il vient d’écrire pour nous sur la constitution et le développement d’équipes de gestion de projet digital en agence. Mais avant de parler de ton article Brian, pourquoi ne pas nous en dire un peu plus sur toi.

Brian Kessman :

Oui bien sûr, tout d’abord merci de m’accueillir sur votre podcast et pour l’invitation à écrire l’article, ça m’a beaucoup plu. Pour me présenter, je suis basé à Chapel Hill, en Caroline du Nord, je viens à l’origine de New York, j’ai grandi à Long Island et j’ai vécu quelques années à Manhattan mais maintenant nous sommes installés ici et aujourd’hui je dirige un cabinet de conseil, Lodestar Digital, c’est mon activité.

Ben Aston :

Super, alors parle-nous un peu de Lodestar, en quoi consiste Lodestar ?

Brian Kessman :

Bien sûr. Lodestar est un groupe de conseil. Son objectif est d’aider les agences digitales et créatives à construire et à améliorer leurs services numériques, cela signifie en pratique les accompagner dans la réorganisation ou la transformation des équipes, tout cela dans l’optique de produire un meilleur travail digital. Il s’agit parfois de créer de nouvelles disciplines digitales, comme la gestion de projet digitale, de développer ou rationaliser les processus. Parfois c’est aussi l’implémentation de pratiques agiles, mais adaptées au secteur créatif. En gros, ce sont ces catégories de services.

Ben Aston :

Super, donc tu fais maintenant du conseil dans ce genre de domaines, alors comment es-tu venu à la gestion de projet digital et à accompagner les agences dans ce type de transformation ? Quel est ton parcours là-dessus ?

Brian Kessman :

J’ai commencé la gestion de projet il y a des années en faisant du conseil en technologie et après cela, j’ai travaillé dans la publicité mais j’ai pris du temps pour faire du conseil en tech, c’est là que j’ai découvert la gestion de projet. De retour en agence, j’ai pu appliquer ces compétences, donc pendant globalement dix-sept ou dix-huit ans, j’ai surtout été en agences, avec une forte orientation digitale même dans des agences plus classiques, mais les rôles gardaient une dimension digitale.

Voilà grosso modo mon parcours, mais particulièrement ces dix dernières années, j’ai surtout eu des rôles orientés amélioration des processus et de la livraison en agence ainsi que le développement de sites web, d’applications, etc. Et donc j’ai vu beaucoup de difficultés de croissance typiques à ces agences qui étaient souvent de taille petite ou moyenne, quand elles grandissaient, elles rencontraient des problèmes similaires à ceux que j’avais déjà rencontrés et réglés ailleurs, alors j’ai voulu aider d’autres agences à les adresser car la demande pour du digital augmente beaucoup et beaucoup d’agences éprouvent encore des difficultés, que ce soit du côté créa pour aborder le digital ou à l’inverse des agences digitales qui grossissent et veulent s’améliorer.

Ben Aston :

Oui, alors de quoi s’agit-il concrètement lorsqu’on parle d’aider les agences traditionnelles à devenir digitales et passer à l’échelle ? Quelles sont les difficultés typiques que tu rencontres, quels sont les problèmes récurrents auxquels font face les agences ? Je suis sûr que ça parlera à nos auditeurs qui vivent sûrement les mêmes soucis.

Brian Kessman :

Oui, la plupart du temps, le problème principal dans une agence créative vient d’une approche très cloisonnée des disciplines. On se contente d’effectuer une passe entre équipes ou métiers, ce n’est plus aussi grave qu’avant mais cela existe encore, surtout dans les grandes agences traditionnelles. J’essaie alors de proposer le modèle d’équipe pluridisciplinaire, où les équipes, fixes ou temporaires, travaillent main dans la main, il y a plus de transparence, une meilleure compréhension du rôle de chacun. Cela élève beaucoup la compétence digitale de tous.

Un exemple classique : un designer travaille sur une maquette de site sans véritable sensibilité digitale, donc il ne prend pas en compte la réactivité, et une fois la maquette transférée au designer digital ou au développeur, tout est à refaire car cette dimension n’a pas été considérée.

Ben Aston :

Oui ça me parle, c’est typiquement le cas quand une personne qui n’a jamais designé de site web te sort des dimensions délirantes ou des mises en page folles et tu te dis « attends, ce n’est pas comme ça qu’on fait un site ». Ce genre de détails, il faut s’en rappeler !

Brian Kessman :

Ou alors on te donne un design de panneau d’affichage mais on n’a jamais pensé à la landing page qui va avec ou autre.

Ben Aston :

Oui, il suffit de transformer l’affiche en landing page. Juste en ajoutant un bouton, non ? Bon, et actuellement, en gérant des projets digitaux, tu aides les agences à mieux fonctionner, mais quels sont les outils que tu utilises, ou quelque chose que tu aurais découvert récemment et que tu trouves révolutionnaire, à recommander absolument ?

Brian Kessman :

Oui, alors il y a un outil qui m’a vraiment accroché dernièrement. C’est assez nouveau, je crois qu’InVision a récemment lancé Designbetter.co, je ne sais pas si tu connais ?

Ben Aston :

Non je ne crois pas que je l’ai vu, non.

Brian Kessman :

Ils essaient vraiment d’aider à améliorer les pratiques design, pas seulement du design digital, mais le design au sens de résolution de problèmes business. Le contenu y est très riche : podcasts, articles de blog, cours email, tous conçus par de grands leaders du design. C’est une ressource incroyable pour comprendre comment constituer de belles équipes et produits. J’en écoute le plus possible et je le recommande à tout le monde, peu importe la discipline, c’est super. Mais c’est plus pour l’éducation ou le développement, parce que mon travail consiste surtout à conseiller, non à gérer au quotidien des projets digitaux.

Ben Aston :

Oui.

Brian Kessman :

Je m’appuie beaucoup sur les ateliers, entretiens, sondages. J’utilise le mapping des parties prenantes pour identifier où il peut y avoir des relations brisées dans une agence. Il y a aussi le mapping des processus et l’analyse des écarts de compétences, j’utilise cette matrice de compétences dont j’ai parlé dans l’article, etc.

Ben Aston :

Intéressant. Et je parie qu’en revenant sur la question des outils, tout le monde adore ça. Lorsque tu aides les agences à devenir plus digitales ou à travailler plus en équipe, y a-t-il des outils qui aident particulièrement à casser les silos et à faire évoluer les façons de travailler ?

Brian Kessman :

Oui, bien sûr. C’est ce que tu veux, je suppose. Ce sont surtout des logiciels de gestion de flux de travail. Il y en a plein sur le marché, il faut voir lesquels sont le plus adaptés à l’agence. Je veux dire, JIRA est phénoménal pour le développement de produits logiciels, beaucoup d’agences l’utilisent pour la création aussi. Il y en a plein, mais le principal est de créer de la transparence sur le travail et de fluidifier les échanges et la collaboration.

Ben Aston :

Très bien. Parlons maintenant de ton article, qu’on a publié. Il est vraiment axé sur la croissance des équipes de gestion de projet digital et sur la meilleure façon de le faire. Si tu ne l’as pas encore lu, fonce, c’est une excellente ressource, que tu sois ou non un lead de ton équipe DPM : c’est un guide pas à pas pour constituer une équipe de Digital Project Management. Même si tu ne montes pas d’équipe en ce moment, tu en tireras des choses applicables à ta gestion de projets, à une autre échelle. Brian y expose les cinq « P » pour faire grandir une équipe de PM : Purpose, People, Partnerships, Process et Performance.

Purpose concerne la réunion des parties prenantes autour du pourquoi du scaling DPM, People c’est le recrutement des bonnes personnes avec les bonnes compétences, les bons salaires, Partnerships c’est les partenariats internes et la structuration de l’équipe pour que le PM réussisse, Process ce sont les outils, modèles, méthodes pour garantir la cohérence et la valeur, et Performance c’est le suivi et l’amélioration continue des progrès. Voilà pour un résumé rapide, tu trouveras plus de détails dans l’article.

On va maintenant s’attarder sur le premier P, Purpose, le « pourquoi » d’une équipe DPM. C’est essentiel : souvent, les gens se retrouvent chargés contre toute attente de gérer le projet digital de l’agence. On le voit souvent dans la team Slack : des membres rejoignent, ils disent qu’on vient de leur confier la gestion de projets digitaux, et qu’ils se posent des questions sur leur mission exacte. Fréquemment, c’est une réaction à quelque chose qui a mal tourné : « ces projets digitaux ne se gèrent pas comme les autres », « nos projets dépassent toujours le budget ou prennent du retard, alors il faut quelqu’un pour porter le chapeau, donc hop, toi tu es DPM ». Tu proposes une vision du but d’une équipe DPM et des recommandations ; penses-tu qu’il y ait différentes variantes selon les agences ?

Brian Kessman :

Pour moi, il n’y a pas tellement de variantes, en fait ça dépend surtout de la façon dont on va formuler ce but, mais fondamentalement ça reste le même. L’enjeu c’est vraiment d’avoir pris le temps de formuler ce but, sinon on se retrouve perdu : toi-même tu ne sais pas ce que tu fais, personne ne le sait non plus, tu n’as pas le soutien qu’il te faut, tu n’es pas en position de réussir. Mais à partir du moment où ce but est posé, il ne varie plus vraiment dans le fond.

Ben Aston :

Oui, et pour moi, ayant déjà monté des équipes DPM, le défi c’est qu’on est embauché pour créer ou faire grandir une équipe, mais il y a toujours un équilibre à trouver, car il y a d’un côté le statu quo – où la gestion de projet digitale n’était pas structurée – puis on veut bâtir une vraie équipe DPM, mais en commençant petit. Alors comment scaler cette équipe sans se retrouver dépassé ? Comment accompagner cette transition ? Comment savoir jusqu’où aller ?

Brian Kessman :

Tout est question de système intégré ; si l’objectif est bien défini dès le début, la spécialisation est la clé. Il faut se concentrer sur la valeur spécifique ou les résultats attendus de ton rôle, une seule spécialisation à la fois. Par exemple, livrer des projets avec succès en réduisant les risques grâce à la planification : c’est l’objectif que j’ai proposé pour les PM. On se concentre sur ce résultat, cette réduction des risques via le projet ; la spécialisation, c’est la planification de projet. Si tu restes focalisé là-dessus, il y a toujours des zones grises, mais les limites sont plus claires.

Ben Aston :

Oui, très intéressant. Tu parles ensuite des personnes, et notamment de l’importance de bien choisir le leader de l’équipe. As-tu des conseils pour identifier ou développer des leaders dans une équipe DPM ? Quels profils recherches-tu pour la direction d’un PMO ?

Brian Kessman :

C’est un subtil équilibre entre compétences techniques et qualités humaines. Il faut d’une part l’expérience, la pratique, et de l’autre côté, ce qui compte le plus dans le leadership, ce sont les soft skills : être capable d’inspirer, de motiver, d’avoir de l’empathie pour ton équipe, comprendre les défis de leurs rôles. Soutenir l’équipe, c’est du « servant leadership » : tu n’agis pas à la place des autres, tu aides, tu déblayes les obstacles pour leur permettre de progresser et tu leur apportes les pièces du puzzle dont ils ont besoin. C’est ça être un bon leader.

Ben Aston :

Oui tout à fait, et tu expliques que le leader d’équipe PM doit consacrer 50 % ou plus de son temps au mentoring et au soutien, certains auditeurs doivent se dire qu’ils n’y passent pas autant de temps. À quoi ressemble ce mentorat, ces soutiens au quotidien ? J’imagine que ça passe par la relecture des rapports de statuts, le suivi des prévisions ou des plannings, mais sur le mentorat, as-tu des exemples concrets pour aider les PM juniors à progresser ?

Brian Kessman :

Oui, il s’agit surtout d’être disponible pour leur parler. Pendant ces échanges, avec un peu de recul, tu peux percevoir là où ils rencontrent des difficultés, souvent sans même s’en rendre compte. D’où l’importance des points individuels hebdomadaires ou mensuels, d’aller prendre un café, déjeuner, etc. Un autre aspect, c’est l’observation comportementale lors de leurs réunions, par exemple lors des kick-offs ou onboarding, voir comment ils se comportent –

Ben Aston :

Oui, c’est clair.

Brian Kessman :

Donc il faut observer puis faire un retour. Cela rejoint la matrice de compétences dont j’ai parlé dans l’article. Si tu as défini ces compétences, tu peux situer chaque PM, et avec des exemples réels issus de ces réunions, expliquer ton évaluation et comment les aider à progresser, avec des objectifs clairs pour les six mois à venir, par exemple.

Ben Aston :

Oui, c’est très utile. Tu as aussi évoqué la formation professionnelle. Quels développements recommanderais-tu à un DPM ? Le PMP, le scrum master, d’autres certifications ? Qu’as-tu trouvé de plus utile ?

Brian Kessman :

Il y a deux dimensions. Quand je gérais moi-même des projets, j’ai étudié pour le PMP sans passer l’examen finalement, j’en ai tiré tout ce qu’il me fallait. Mais j’ai suivi la formation certifiante Scrum Master et Product Owner, et là c’est précieux. Tout le monde devrait passer par là car cela donne un autre point de vue sur la gestion de projet, d’autant plus que c’est la tendance du secteur, y compris dans beaucoup d’agences qui devraient y songer, même sous forme adaptée de l’agilité.

Donc oui, c’est important, mais aussi, pour mieux collaborer, il faut s’ouvrir à d’autres disciplines : chef de projet, tu touches à tout dans l’organisation donc il faut une bonne compréhension du design, du développement ; trempe-toi dans le code, ou écoute par exemple le podcast d’InVision dont j’ai parlé, ils donnent un ressenti réel du métier du design. Plus tu comprends mieux ces disciplines, plus tu pourras collaborer efficacement avec les équipes. Voilà ce que je recommande.

Ben Aston :

C’est un excellent conseil, effectivement, plus on comprend ce que font nos équipes, plus on peut anticiper les blocages. Plus tu connais le boulot de l’équipe, qu’il s’agisse de stratégie, UX, design, développement ou QA, plus tu seras à même d’aider à résoudre les problèmes, parfois juste avec la bonne question. Parfois, un petit supplément de connaissance fait une grande différence.

Brian Kessman :

Oui, tout à fait. Tu parlais de la dimension stratégique, c’est super important : les PM bossent généralement main dans la main avec les designers et développeurs mais crois-moi, on est rarement aussi proches des équipes stratégie. Si tu arrives à te rapprocher de la stratégie, tu gagneras beaucoup en management de projet : cela te permettra de mieux garantir l’alignement avec la stratégie, d’atteindre les objectifs du projet. C’est une discipline clé que les PM côtoient peu, du moins d’après ce que j’ai vu, mais j’espère que ce n’est pas toujours le cas.

Ben Aston :

Oui, souvent c’est cloisonné, notamment là où la gestion de compte ou la stratégie relève du directeur de clientèle, puis le projet passe à l’équipe. Mais c’est si important que le PM comprenne la stratégie sous-jacente, pour délivrer des projets vraiment efficaces. Être stratégique, ça permet d’aller droit au but, de couper au bon endroit, ou d’ajouter ce qu’il faut à un projet pour s’assurer qu’il génère les bons résultats. C’est vraiment la raison d’être d’un projet !

Revenons sur ta matrice de compétences : je l’ai trouvée très utile et bien pensée, mais évidemment elle ne donne pas toutes les réponses. Quand on télécharge la matrice, comment définir par exemple, pour la compétence « planification de projet », les niveaux attendus selon les grades ? Comment trier ça ?

Brian Kessman :

C’est spécifique à chaque agence en fonction de la complexité des projets et des clients. Certaines agences n’embauchent que des seniors, par exemple. L’idéal c’est de le définir en équipe, ce n’est pas au directeur de la gestion de projet d’imposer cela, mais de poser la question : quels sont les types de missions, les zones de friction, quelles opportunités avons-nous, quels écarts à combler ? C’est une démarche collaborative, plus tout le monde se sent impliqué, moins c’est perçu comme de l’évaluation punitive et plus c’est vu comme un outil de progression, pour mieux comprendre et valoriser les compétences.

Ben Aston :

Oui, ça aide. Dernier point sur les personnes : tu parlais du recrutement, de l’importance de l’équipe leader, de l’embauche des bons PM. Or le recrutement est souvent soumis à des contraintes budgétaires. On veut souvent un senior, mais le budget ne suit pas. Quels conseils as-tu pour embaucher dans ces conditions ?

Brian Kessman :

C’est justement là que la matrice de compétences prend tout son sens : elle sert de référence pour justifier ton besoin d’un senior, en montrant objectivement les compétences en jeu et pourquoi elles sont nécessaires selon la complexité ou les défis des projets.

L’idéal est d’impliquer RH ou la finance dès l’établissement de la matrice, pour qu’ils comprennent pourquoi tu as besoin d’un certain profil à chaque étape, avec une fourchette de salaire pour chaque niveau. Ça évite les frustrations au moment du recrutement, ils savent déjà ce qu’implique chaque type de mission et ce que le marché exige. Avec cette anticipation, ils peuvent aussi anticiper ce besoin dès les prévisions budgétaires.

Donc cet outil est capital pour justifier tes besoins RH.

Ben Aston :

Très utile en effet. Et parfois on a aussi besoin de profils juniors pour délester les seniors des tâches administratives et leur permettre de se concentrer sur le pilotage stratégique. Troisième P : Partnerships, ou les relations internes. Tu utilises la matrice RACI pour clarifier tout cela. Pour ceux qui ne connaissent pas, peux-tu expliquer ce que c’est et à quel niveau de détail tu construis la matrice ?

Brian Kessman :

Oui bien sûr, c’est un gros travail à bâtir et ça demande beaucoup de collaboration. La matrice RACI : imagine chaque étape de ton process, aussi détaillé que tu veux (même si je déconseille l’excès !). Tu découpes tes phases, tes étapes, tes tâches principales. Pour chacune, RACI signifie : Responsible (responsable), Accountable (redevable), Consulted (consulté) et Informed (informé). Il ne doit y avoir qu’un seul Accountable par étape : c’est la personne qui garantit le bon déroulement, dans le bon cadre. Les Responsibles font le travail, Consulted et Informed parlent d’eux-mêmes (ex : le designer fait la maquette mais la décision impacte le périmètre ou le planning, il doit donc consulter le PM). Ces matrices sont longues à bâtir mais il vaut mieux y aller progressivement et s’adapter selon les besoins de clarté.

Ben Aston :

Excellente explication sur la subtilité des rôles. Mais lors d’une transition vers plus de digital, il y a souvent trop de personnes qui veulent être consultées ou informées à chaque étape, ce qui alourdit le projet. As-tu un conseil pour limiter le nombre de personnes consultées ou informées et éviter la surcharge ? Car tout le monde pense que son avis compte mais ce n’est pas toujours utile d’avoir tous les avis !

Brian Kessman :

Oui, c’est un bon problème, cela montre que tout le monde est impliqué. Mais il faut rationaliser, tu ne peux pas réunir vingt personnes à chaque réunion ! À ce titre, comme déjà abordé, un outil collaboratif de gestion de flux permet de créer de la transparence, de poster des messages à chaque étape ou décision, même automatiquement. On peut ainsi recueillir des avis en ligne (Consulted), et automatiser l’information (Informed) via des notifications ou emails, sans avoir à réunir tout le monde à chaque fois. C’est très utile pour éviter la surcharge.

Ben Aston :

Clairement, c’est pratique ! Passons à la gestion de processus, le P préféré des PM : tu parles de standardiser les process, ce qui est primordial dans toute agence. Mais même dans une agence digitale, les types de projets sont très variés, un PM peut bosser le matin sur un projet de service design, l’après-midi sur une refonte de site. Comment standardiser tout en gardant l’adaptabilité pour chaque type de projet ? Comment gérer cet équilibre ?

Brian Kessman :

C’est aussi une question de stratégie d’agence : veux-tu te spécialiser pour maximiser les répétitions, ou rester généraliste ? Par exemple, une agence qui ne fait que de la réalité augmentée appliquée au secteur de l’habitat aura des process très standardisés, tout tournera autour de cette spécialité.

Mais même en généraliste, il y a toujours des schémas récurrents, il suffit de les repérer et de standardiser ces éléments communs. Idéalement, tu travailles pour une agence spécialisée et tu bénéficies de la répétition, sinon, repère les catégories de projets et ce qui peut être rendu systématique, puis optimise-les.

Ben Aston :

Oui, très juste. Pour ma part, j’ai trouvé utile de bâtir un processus global pour le type de projet le plus complexe et d’en extraire ensuite des sous-processus pour les projets plus simples (par exemple, un projet de stratégie UX n’est qu’une partie d’un projet de replatforming plus large, le process découle du même modèle). Cette standardisation amène beaucoup d’efficacité et évite l’impro sur chaque nouveau projet « un peu différent » qui fait déraper les budgets. D’où l’intérêt du cadre général qui sert de référence pour tous les cas particuliers.

En standardisant ainsi, on évite que des tâches inutiles ne s’infiltrent et qu’on ait des efforts inutiles qui ne servent ni le projet, ni la qualité du livrable.

Brian Kessman :

Oui, je suis d’accord.

Ben Aston :

Enfin, parlons du dernier P, Performance, aspect souvent négligé. À quelle fréquence mesurer la performance et sur quels critères, selon toi, pour s’assurer d’une amélioration continue ?

Brian Kessman :

Là encore, commence modeste : cible une ou deux priorités. Par exemple, parmi les indicateurs clés de performance (KPI) que j’ai listés, tu as le délai moyen de livraison, le taux de projets livrés à temps, ou la rentabilité. Ce sont des indicateurs tangibles, simples à mesurer. Pour les critères plus « mous », tu peux t’appuyer sur des sondages internes ou auprès des clients, trimestriels par exemple (plutôt internes plus souvent, pour les clients il faut éviter l’excès). Avec ces résultats, ajuster chaque trimestre les axes à améliorer.

Les enquêtes clients sont précieuses aussi ; tu peux utiliser le net promoter score pour mesurer s’ils recommanderaient l’agence, et recueillir leurs retours qualitatifs. Cela permet non seulement de progresser en interne mais aussi de vérifier la satisfaction client, essentielle à la fidélisation. Pour tout ce qui relève du qualitatif, les sondages sont la meilleure arme.

Ben Aston :

As-tu un conseil pour obtenir vraiment des réponses quand tu envoies ces surveys NPS ? Car c’est souvent bref mais les gens boudent les enquêtes. Comment les encourager sans plomber les scores ?

Brian Kessman :

Bonne question ! Précisons déjà que ce ne sont pas que les surveys : il faut aussi nourrir la relation directe, que le client se sente partenaire et pas juste questionné pour des stats. Si tu sens qu’il ne répond pas, appelle-le directement. La relation est essentielle, sinon même les outils les plus optimisés ne servent à rien. À minima, rends le survey mobile friendly ! C’est fatigant d’obtenir des réponses mais si tu as construit une relation solide, tu pourras appeler, relancer…

Ben Aston :

Super. Merci beaucoup Brian, ravi de t’avoir accueilli, la discussion sur la construction et la montée en puissance d’équipes DPM est capitale, merci d’avoir partagé tout ça !

Brian Kessman :

Avec plaisir, c’était sympa, merci Ben.

Ben Aston :

Si le sujet vous intéresse, réagissez sous l’article et rejoignez la communauté sur thedigitalprojectmanager.com, participez à la team Slack pour de nombreuses discussions passionnantes. Merci de nous avoir écoutés et à bientôt !