Ce que vous pouvez arrêter de faire sur vos projets (avec Patrice Embry)

Lisez la transcription :

Nous essayons de transcrire nos balados à l’aide d’un programme logiciel. Merci de nous excuser pour les coquilles, le bot n’est pas exact à 100 % du temps.

Ben Aston :

Merci d’être à l’écoute. Je suis Ben Aston, et voici le balado du Digital Project Manager.
On nous dit toujours tout ce que nous devrions faire, et je fais partie de ces personnes qui le rappellent. Il y a cette pression d’améliorer ses compétences, de tout bien réaliser, et la pression d’être vu en train de bien faire les choses est vraiment énorme, mais faut-il vraiment tout faire, tout le temps ? Continuez d’écouter cet épisode pour découvrir comment vous pouvez gagner un temps fou en éliminant ou réduisant certains éléments de votre routine de gestion de projet, qui ne sont pas systématiquement nécessaires pour chaque mission.
Nous allons parler de comment récupérer un peu de votre vie, passer moins de temps au bureau ou à votre poste de travail, en retirant six tâches sur lesquelles vous pourriez économiser du temps. Ce balado consiste à vous libérer des contraintes du « il faut » et des obligations, et à rendre la façon dont nous travaillons plus efficace.
Aujourd'hui, je suis rejoint par Patrice Embry qui est en fait — et je dois la féliciter pour cela — probablement le membre le plus actif de notre équipe Slack. Si vous n’avez pas encore rejoint, vous pourriez être en train de discuter avec Patrice dès maintenant. Rendez-vous sur la section communauté du Digital Project Manager pour vous inscrire. Patrice est presque toujours présente et toujours en train de discuter, donc c’est une bonne personne à connaître.
Petite introduction : Patrice est PM digital indépendante. Elle est également certifiée Scrum Master niveau 2. Elle travaille dans l’industrie depuis longtemps, dans tout type d’agences et de sociétés. Écoutez d’autres de nos balados pour mieux comprendre ce qu’elle a déjà réalisé. Elle a touché à tout, c’est donc une personne extrêmement pertinente à connaître.
Bienvenue Patrice.

Patrice Embry :

Bonjour. Merci de m'accueillir.

Ben Aston :

C’est un plaisir. Alors Patrice, depuis notre dernière discussion, as-tu travaillé sur des projets intéressants en ce moment ?

Patrice Embry :

Alors je viens tout juste de terminer une application sur laquelle je travaillais, qui aide les personnes à la recherche de missions courtes et très rapides à trouver des emplois. Un peu comme un Care.com, mais encore plus rapide, pour les gens qui ont vraiment besoin d’un job ponctuel. C’était une application très intéressante. Elle n’est pas encore complètement lancée… Elle est en phase bêta pour le moment donc elle n’est pas tout à fait prête à être dévoilée, mais ce projet était intéressant car je travaillais avec des personnes du monde entier.
Je n’avais encore jamais travaillé avec quelqu’un du Nigéria auparavant, donc c’était ma première fois à dire bonjour en igbo, c’était plutôt amusant.

Ben Aston :

Ça ressemble à un projet d’arnaque. Je plaisante bien sûr ! L’équipe de développement était-elle basée là-bas ?

Patrice Embry :

Pardon ?

Ben Aston :

Tout l'équipe de développement était-elle basée au Nigéria ?

Patrice Embry :

Oui.

Ben Aston :

Ah, vraiment ?

Patrice Embry :

Oui. Le designer front-end était au… Le développeur front-end était au Nigéria. Le développeur back-end était au Mexique, notre responsable technique était en Suède, moi, j’étais près de Philadelphie, et la cliente était à Boston. Nous étions répartis dans de nombreux fuseaux horaires.

Ben Aston :

C’est beaucoup de fuseaux horaires à gérer.

Patrice Embry :

Oui, vraiment.

Ben Aston :

Ça n’a pas été trop compliqué ? Comment avez-vous fait ?

Patrice Embry :

J’ai trouvé un créneau qui pouvait convenir à tout le monde, et c’était 8h du matin, heure de l’Est. Nos collègues européens avaient un horaire un peu tardif, c’était assez tard pour notre collègue nigérian, et le Mexicain devait se lever un peu plus tôt que d’habitude, mais nous avons réussi à nous organiser.

Ben Aston :

C’est donc pour une start-up, cette appli ?

Patrice Embry :

Oui. C’est un service né d’une femme qui faisait ça pour quelques connaissances et puis d’autres personnes lui ont demandé, « Hey, tu peux aussi le faire pour moi ? », etc. Jusqu’au moment où elle s’est dit : « Je ne peux plus gérer toute l’organisation seule… ». Et elle s’est dit : « Faisons une appli pour ça. » C’est vraiment encore au tout début, donc je ne peux pas en dire trop pour l’instant, mais quand ça sortira, je le ferai savoir. Je pense que ce sera un service super pour beaucoup de gens.

Ben Aston :

Projet intéressant. Quelles ont été les grandes difficultés sur ce projet ? Des imprévus ?

Patrice Embry :

Ce n’était pas toujours simple… La cliente n’était pas très à l’aise avec l’informatique. Elle avait un niveau normal, comme beaucoup, mais pas plus. Comme on le voit souvent dans la tech, il faut parfois expliquer les bases. Il y a ce moment où tu te rends compte des éléments auxquels personne n’a pensé. Les tests, raison pour laquelle c’est encore en bêta, étaient très poussés, car on se rendait compte au fur et à mesure des cas auxquels on n’avait jamais pensé. C’était un vrai défi, mais très enrichissant, j’en suis ravie.

Ben Aston :

Quels outils as-tu utilisés pour coordonner toutes ces personnes dans différents fuseaux horaires ? Et pour gérer les exigences initiales, parfois floues, et piloter le projet ?

Patrice Embry :

Oui, c’était assez flou. On n’avait pas beaucoup de budget, ce qui colle bien au sujet du jour. Je ne pouvais pas passer beaucoup d’heures, il fallait vraiment choisir les tâches à faire ou à ne pas faire, pour ne pas plomber le budget. J’ai voulu économiser un maximum d’heures pour le développement.
Nous avons utilisé Slack car c’était gratuit, Chelo aussi, et beaucoup de Google Docs car ils sont gratuits également. Il a fallu jongler avec tous ces outils sans accès aux fonctions premium, pour rester le plus agile possible et aider la cliente au mieux.

Ben Aston :

Comment as-tu trouvé ce projet ? Du bouche à oreille ? Ça sonne comme une start-up…

Patrice Embry :

Tu me connais. Tu as rappelé que je suis toujours connecté sur Slack, et ton Slack n’est pas le seul où je suis active. En tant que freelance, il faut constamment multiplier les contacts, garder ouverts tous les canaux pour obtenir un maximum d’informations. Je parle à énormément de gens sur plein de sujets.
Je ne me rappelle même plus le long enchaînement d’événements qui m’a amenée sur ce projet, mais c’était sûrement du genre : « Ah, je crois connaître quelqu’un qui a peut-être… quelqu’un sur un autre réseau. » Donc beaucoup grâce au réseau ! Mais oui, je fais énormément de networking, j’ai des projets qui tombent par les canaux les plus inattendus.

Ben Aston :

C’est toi qui as rassemblé l’équipe ?

Patrice Embry :

Non.

Ben Aston :

C’était une de tes responsabilités ?

Patrice Embry :

Non, j’ai été intégrée à une équipe déjà formée, nous avons chacun trouvé notre place. Je n’ai pas eu à aller chercher les ressources. J’ai beaucoup apprécié l’équipe, et j’espère pouvoir à nouveau retravailler avec eux, car chacun avait vraiment de la valeur ajoutée.

Ben Aston :

C’est toujours enrichissant de travailler sur des projets où le client n’est pas toujours ultra-tech, mais ça apporte aussi généralement une flexibilité bienvenue, une confiance, comme « Vous êtes les experts, dites-moi ce que je dois faire ! » C’est top ! On peut vraiment mettre en place de bonnes choses.
L’envers, c’est l’assistance du type « Essayez d’appuyer sur Ctrl + F5… »

Patrice Embry :

Oui, il y en a beaucoup eu ! Mais c’est important d’y penser : quand on fait une appli pour le grand public, il faut partir du principe que tout le monde n’a pas le même niveau. Ce retour aux bases nous a aidé, on ne pouvait rien prendre pour acquis, même des gestes simples avec un écran tactile. Il fallait que l’utilisation soit super claire. Cela a été un vrai plus pour le projet.

Ben Aston :

Très bien. Parlons maintenant de la gestion réelle des projets au quotidien. D’un côté, il y a les meilleures pratiques, on publie sur le Digital Project Manager des articles sur le « comment faire », mais la réalité est parfois différente.
Selon toi Patrice, quand on arrive sur un projet, quels sont les éléments absolument non négociables à vérifier ? Qu’est-ce qui est indispensable, sans quoi le projet risque de dérailler dès le début ?

Patrice Embry :

Pour moi, c’est toujours le calendrier et les exigences (requirements). Ensuite, le budget arrive en troisième position. Il varie d’importance d’un projet à l’autre, mais on ne peut pas échapper à un calendrier précis, ni à la définition des exigences. Sinon, on ne sait pas ce qu’on fait. Pour moi, ce sont les incontournables.

Ben Aston :

Juste pour clarifier, quand tu parles d’exigences, tu ne parles pas d’un cahier des charges, mais alors sous quelle forme exprimes-tu ces exigences ?

Patrice Embry :

Bonne question ! Ça ne doit pas forcément être formel, mais il faut savoir très précisément le périmètre (scope), et même aller plus loin : que doit vraiment accomplir ce produit ? Un cahier des charges laisse souvent des zones non détaillées. Il y a forcément d’autres choses à faire, à discuter, ou des fonctionnalités à ajouter pour mener à bien le scope. C’est de ces exigences dont je parle : elles doivent être identifiées et communiquées. Sinon, personne ne sait ce qu’il faut livrer !

Ben Aston :

Exactement, c’est aussi ce que je fais. Quand j’arrive sur un projet, ce sont le devis, l’estimation, la planification et les exigences que je cherche à obtenir car… Sans plan ni exigences, impossible de piloter ou contrôler le projet.

Patrice Embry :

Comment saura-t-on si c’est terminé ? Ou si ça ne s’est pas arrêté ? Exactement.

Ben Aston :

Souvent, quand on récupère un projet, les exigences ou le cahier des charges sont déjà obsolètes. On s’est mis d’accord pour autre chose, ou modifié en cours de route…
Comment fais-tu pour garder tout le monde aligné, et maintenir ces éléments à jour tout au long du projet ?

Patrice Embry :

Je rappelle les deadlines à chaque réunion d’équipe, que ce soit chaque semaine ou tous les quinze jours selon le projet. On revoit où on en est, la prochaine étape, et même la suivante, pour avoir une vision claire de ce qu’il faut faire.
J’indique la date de fin, la date importante à viser. Pas forcément le lancement, mais par exemple l’entrée en QA ou en UAT. Si ça change, j’informe tout le monde. S’il y a un risque de retard, je le communique très vite.
Pour les exigences, j’essaie de les maintenir à jour dans Trello, Jira, ou tout autre kanban, où on peut documenter l’évolution de chaque fonctionnalité, relire les échanges et garder l’info accessible.
Si ce n’est pas digitalisé, il faut garder une documentation historique à jour, pour enregistrer ce qui a été décidé avec le client, ce qu’on prévoit d’ajouter, etc. C’est un process de maintien permanent de la documentation, quelle qu’en soit la forme.

Ben Aston :

Pour ma part, je modifie le cahier des charges à chaque gros changement, en demandant une signature du client, histoire qu’on garde une trace écrite, surtout s’il y a plusieurs interlocuteurs. Avoir la preuve des validations, c’est indispensable.

Patrice Embry :

Absolument.

Ben Aston :

Puisqu’on parle des incontournables (cahier des charges, exigences, calendrier, estimation), discutons maintenant des éléments sur lesquels il est possible de faire plus léger, comme tu l’évoques dans ton article.
Tu parlais par exemple des budgets détaillés et décompositions de projet. Peux-tu développer…

Patrice Embry :

J’ai commencé dans de très grosses structures où tout était « processé » à l’extrême. On était nombreux PMs à travailler de la même façon, avec des process très précis sur tout.
Mais en agence plus petite ou à mon compte, tu ne peux pas toujours appliquer le même niveau de détail sinon, tu ne respectes plus le budget. Dans ces grosses boîtes, je faisais des budgets très détaillés, sur tableau Excel, formules, TCD, calculs d’avancement chaque semaine par rôle, etc. C’était très complet et ça me permettait de répondre à toute question sur le budget à n’importe quel moment. Mais si maintenir un tel niveau de suivi exige trop d’heures et que ni le client ni l’agence n’en voient la valeur, à quoi bon ?
Pour moi, il ne faut pas croire que tout découper dans les moindres détails est toujours nécessaire. Demandez-vous vraiment ce qui est pertinent pour le projet, pour le client, et ajustez votre implication à ce qui a de l’impact réel, sans processus inutiles.

Ben Aston :

En gestion de projet, tu fixes un pourcentage d’heures alloué pour la gestion par rapport au total des membres de l’équipe, ou tu analyses tâche par tâche ?

Patrice Embry :

Auparavant, oui, c’était sur une base de pourcentage, et c’est ce qui fonctionne quand le chiffrage global couvre bien tout. J’ai l’avantage d’avoir travaillé dans de nombreux environnements, ce qui me donne du recul. Je regardais les tâches dans leur ensemble puis j’appliquais un pourcentage, mais aujourd’hui, je le fais plutôt tâche par tâche, c’est plus fin. Je ne fais plus de pourcentage global, ce n’est pas assez précis pour moi ni pour des petites structures ou pour du freelance.
Mais si ça vous convient, continuez ainsi. Pour ma part, parfois, le calcul global n’était pas suffisant parce que, souvent, l’estimation de base est erronée et dans ce cas, le pourcentage n’a pas de sens.

Ben Aston :

Donc ce n’était pas trop, ça n’était pas assez d’heures… Quel pourcentage appliquais-tu ?

Patrice Embry :

Avant, avec des chargés de compte, j’ajoutais 20% pour la gestion de compte, et 20% supplémentaires pour la gestion de projet – ce qui fait 40%.
C’est beaucoup, mais si la base n’est pas juste, ça ne fonctionne de toute façon pas. J’ai compris que c’était rarement le calcul qui était mauvais, mais le montant total sous estimé. Faire attention à ses estimations, c’est primordial pour la rentabilité du projet.

Ben Aston :

En effet, je pense aussi. Pour moi, la gestion de projet c’est 20% global, et le compte client légèrement moins. Il faut adapter le niveau de détail des budgets en fonction du client et de son appétence au risque. Faire de la prévision ultra précise a un coût, et il faut que le client en soit conscient.
Certaines solutions logiciels de gestion de projet permettent une gestion automatisée, mais dans la réalité, cela reste très manuel – on récupère les heures, on rentre dans Excel, et on fait les calculs. C’est chronophage.
Alors si tu fais plus simple, comment gardes-tu le contrôle quand tu as moins de granularité ?

Patrice Embry :

Avant, je faisais des projections d’heures, par rôle, et les corrections au fur et à mesure. J’ajustais tout chaque semaine. C’est la première étape que je supprime si le suivi détaillé n’est pas justifié par le budget ou la taille du projet.
Avoir les projections initiales suffit parfois, l’essentiel est de voir où on en est par rapport au budget. Toute l’analyse en profondeur peut être allégée. Se concentrer sur les points de base : budget OK ? Risque de dépassement ? Avancement cohérent avec le budget dépensé ? Si oui, continuons. Simplifier l’usage de l’outil ou du suivi, sans exploiter toutes les possibilités.

Ben Aston :

C’est pertinent. Pour les gros projets, plus l’équipe est grosse, plus il faut surveiller les dépenses de près. Sur un projet avec un burn rate de 50K par semaine, la marge de manœuvre est très réduite.
La durée entre deux contrôles budgétaires doit aussi être adaptée à la taille de l’équipe.

Patrice Embry :

Oui. Je vérifie tout chaque semaine, mais sans aller dans le détail à chaque fois. On peut parfois rencontrer des clients qui s’en fichent : « Voici le budget, et je me moque si on déborde ». Au final, même dans ce cas-là, je préfère avoir un suivi budgétaire, car quelqu’un doit quand même garder une trace précise du projet.

Ben Aston :

C’est presque un piège ce « l’argent n’est pas un problème ». Plus personne ne contrôle, et c’est la dérive…

Patrice Embry :

Oui, au bout d’un moment, les dépassements n’ont plus d’importance, et tout le monde fait n’importe quoi. J’en ai vu, c’est terrible.

Ben Aston :

Quand, après trois mois, on réalise qu’on a déjà dépassé le budget…

Patrice Embry :

Et alors, qui s’en préoccupe…

Ben Aston :

On continue à poser des heures, ça empire, et le budget passe dans le négatif. Il faut absolument garder une trace. On a aussi parlé des rapports d’avancement, que tu évoques dans ton article. Quels éléments mets-tu en avant dans les rapports d’avancement selon les clients ?

Patrice Embry :

Parfois, en tant que PM, on a tendance à vouloir prouver notre valeur par des rapports ultra détaillés. Mais si le client ne lit pas tout, à quoi bon ? La cliente de mon appli voulait juste trois informations : tout va-t-il bien, va-t-on tenir les délais, et attendez-vous quelque chose de moi ? Souvent, elle manquait même les réunions de suivi. Bref, je faisais des rapports complets… pour rien. À force de vouloir tout lister, on oublie que le client n’a peut-être pas besoin d’en savoir autant.
Adaptez vraiment votre rapport à votre client, ne remplissez pas seulement pour prouver votre implication. Cela évite de passer des heures inutiles sur ces rapports.

Ben Aston :

Absolument. On a souvent l’automatisme de dupliquer le rapport du projet précédent, puis on finit par accumuler des sections inutiles. Mieux vaut partir du minimum, et n’ajouter que si le client le demande vraiment. Un rapport d’avancement ne doit pas prendre des heures à produire sous peine d’être contre-productif.

Patrice Embry :

Exactement. J’ai déjà eu des demandes de clients pour plus de détails. Je leur explique combien d'heures supplémentaires cela représente, ce que ça signifie sur la durée du projet, et souvent, ils se rendent compte que ce n’est pas si utile que ça.
Ils préfèrent dans la plupart des cas une adaptation ponctuelle, ou finalement ne rien changer. Expliquez-le et vous pourrez souvent éviter le superflu.

Ben Aston :

Oui, et en mettant en avant le coût réel sur le projet, la plupart des clients revoient leur demande.
Mais attention, si le projet est risqué ou avec un client compliqué, il faut documenter les risques visibles dans les rapports, pour ne pas se retrouver sans preuve si jamais un problème arrive.

Patrice Embry :

C’est clair.

Ben Aston :

C’est ça.

Patrice Embry :

Il faut être confiant pour retirer certains éléments, mais aussi savoir que l’on pourra les remettre au besoin. Vous pouvez jauger cela avec votre expérience, votre connaissance du client, du type de projet, etc.

Ben Aston :

Merci de la précision. Autre sujet : les cérémonies Scrum. Parfois, vouloir tout faire (backlog grooming, sprint planning, revues, rétros, etc.) devient vite chronophage. Ton point de vue : faut-il vraiment conserver toutes ces cérémonies ?

Patrice Embry :

Certains sont très puristes et s’en offusquent, mais même en tant que Scrum Master certifiée, je pense qu’il faut se concentrer sur ce qui sert le projet. Si tu dois enchaîner grooming, planning, review, chacun à part, ça peut vite être lourd et coûteux. Si tu peux regrouper certains rituels pour gagner en efficacité, vas-y. Parfois cela apporte même plus, car tu mises sur la dynamique du groupe juste après un review ou un grooming.
Encore une fois, c’est une question de contexte et de jugement. Si tu peux condenser, n’hésite pas.

Ben Aston :

C’est une suggestion très utile. Pour les rétrospectives aussi, il ne faut pas les rendre trop lourdes, surtout si tout s’est bien passé, contentons-nous d’un bilan rapide. Pas besoin d’envoyer des questionnaires de satisfaction ou de faire des stats si personne ne va les exploiter. Il faut doser en fonction du vécu.

Patrice Embry :

Parfois tout s’est bien passé, et on peut juste valider l’ensemble et avancer.

Ben Aston :

Il faut être pragmatique, ne pas s’enfermer dans le « Il faut », mais adapter en continu.

Patrice Embry :

Exactement. C’est comme les rapports d’avancement qui servent à montrer notre utilité au client, alors que les rétrospectives, c’est souvent pour l’interne. Comme pour tout, il faut savoir estimer l’apport réel de chaque rituel par rapport au temps passé. Si on estime qu’une rétrospective de trente minutes suffit, alors allons-y. S’il y a un gros problème à traiter, avançons dessus et ne passons pas 5 heures sur un bilan rarement relu.

Ben Aston :

Pour terminer, parlons des kick off meetings. Tu suggères qu’on peut parfois les remplacer par un simple mail. Comment ça marche ?

Patrice Embry :

Oui.

Ben Aston :

Et ensuite, à la semaine prochaine ?

Patrice Embry :

Oui. Je sais que ça paraît étrange, mais c’est ce que j’ai commencé à faire en laboratoire pharmaceutique, où les projets étaient très répétitifs. Les équipes restaient les mêmes, tout le monde connaissait son rôle et le client. En réunion de lancement, généralement, on rappelait seulement les rôles et le contexte. Alors, je me suis mise à envoyer un mail avec ce qui était particulier sur ce projet spécifique, le planning, les premières tâches. Si tout le reste est déjà connu, c’est bien plus efficace. Je l’ai pratiqué souvent, ça fonctionnait toujours très bien.

Ben Aston :

Oui, je vois l'intérêt. Pour moi, il y a toujours du changement (nouveau client ou nouveau défi), mais il faut effectivement se demander à chaque fois « Est-ce vraiment utile ou n’est-ce qu’une habitude ? ». Idem pour les briefs, souvent copiés-collés, et c’est du temps perdu si tout le monde connaît déjà l’information. Il faut vraiment centrer l’attention sur les points utiles, sans tomber dans la lourdeur des process standards.

Patrice Embry :

Exactement.

Ben Aston :

Pour finir : adaptez vraiment chaque projet comme un cas à part. Ce n’est pas parce que vous avez mis beaucoup de soins dans un projet précédent que vous devez nécessairement répliquer exactement la même formule à chaque fois. Il faut s’adapter au client, au contexte et à la nature du projet.

Patrice Embry :

Absolument.

Ben Aston :

Merci beaucoup Patrice d’avoir été des nôtres ! Si vous souhaitez poursuivre la conversation, commentez l’article de Patricia ou rejoignez la section communauté sur thedigitalprojectmanager.com. Merci de nous avoir écoutés, à bientôt.