Nivellement des ressources dans Monday – Fred Baker – MEMBRES UNIQUEMENT

[00:00:00] Mhm.

Galen : Bonjour à tous, bienvenue à notre session pratique sur l’utilisation de Monday pour planifier, équilibrer et gérer les ressources d’équipes projet. Pour ceux qui ne nous connaissent pas encore, je suis Galen et voici Fred Baker, consultant certifié Monday.

Fred, merci de te joindre à moi aujourd’hui.

Fred : Merci, Galen.

Galen : Bien, entrons dans la gestion des ressources. J’ai un petit scénario à présenter. Je sais que tu as paramétré ton environnement de test, donc laisse-moi planter le décor. Le scénario auquel je pense est le suivant : je dirige une équipe de chefs de projet dans une petite agence digitale.

Nous avons plusieurs chefs de projet qui mènent différents projets en même temps, tous de tailles, de durées et de complexités variées. Mais surtout, tous ces projets partagent les membres d’équipe des départements dev et créa. Et la vraie question que je me pose, c’est : quelle est la meilleure façon, pour mes chefs de projet dans ce scénario, de prévoir les ressources des équipes sur leurs projets en utilisant Monday ? [00:01:00] Plus précisément, je me demande comment savoir si on a surchargé un membre de l’équipe ? Et si c’est le cas, comment utiliser Monday pour équilibrer cette ressource, afin qu’elle ne soit pas en surcharge ? Voilà le genre de cas que j’aimerais explorer.

Je me disais qu’on pourrait commencer par les bases, par exemple, si tu pouvais me montrer rapidement comment tu affecterais des ressources à deux projets, puis on ira voir comment gérer la zone à problème où, tout à coup, quelqu’un travaille 12 ou 16 heures par jour. Est-ce raisonnable ?

Fred : Oui, oui, tout à fait. C’est un très bon scénario. Et la première chose que je dirais, c’est que ce que je vais te montrer n’est qu’une des 7 000 façons possibles d’y arriver, d’accord ? Ce qui est génial avec Monday, comme je le dis souvent à mes clients, c’est qu’il ressemble à une boîte de Lego, non ?

On peut construire ce qu’on veut avec. Il y a bien des façons d’atteindre un même résultat, et là où les gens rencontrent des problèmes, c’est quand ils tentent d’adapter Monday à leur processus ou leur processus [00:02:00] à Monday. Il y a plein d’outils intéressants. Le widget Workload, que j’ai ouvert ici, ou plutôt, c’est le widget Workload.

Je veux être exact, c’est bien le widget Workload. Ce widget fait partie des nouveautés lancées durant l’année écoulée. C’est aujourd’hui probablement la meilleure façon d’avoir une idée des capacités, et comme tu peux le voir dans mon exemple ici, en semaine 25, je suis à 61 % de capacité, mais tu peux empiler les tâches/projets. Je vais aller plus loin, mais l’idée c’est que tu peux accumuler les projets et regarder, ok, pendant telle période Fred est impliqué sur beaucoup de projets. Résultat : on voit du 93 % de charge, voire plus si on en ajoute. On arrive dans le rouge, et visuellement tu repères les surcharges ou au contraire les périodes plus calmes, comme ici à la semaine 29.

Ce widget parle avec un tableau de projet. Donc, tu aurais un tableau projet [00:03:00] d’un côté, et éventuellement un tableau projet “haut niveau”. Un tableau “haut niveau”, c’est une vue portefeuille avec tous tes projets listés.

Ils peuvent être dans des groupes différents. Ce tableau haut niveau s’adresse souvent à toute l’équipe, ou au chef de projet. Ensuite, à partir de là, tu as généralement un tableau “bas niveau”, une vue détaillée, par exemple pour un projet web design client, déjà lié au haut niveau, mais avec toutes les tâches. Ça peut être tout le déroulé, de la réunion de lancement à la collecte des ressources, wireframe, recette, etc. Dans le bas niveau, tout est cartographié. Le haut niveau, lui, annonce simplement, par exemple, qu’on réalise un site pour DPM, en précisant : Galen est le responsable, Fred le chef de projet, et les personnes attribuées au projet.

Donc voilà le tableau haut niveau — tous tes projets y figurent. Ajoutons un projet. Je vais l’appeler DPM et je vais m’y attribuer. J’ai différents types de paramétrages ici pour illustrer. L’un correspond à un “project kickoff” (lancement du projet) : quand débute le projet ? Je mets le 26, pour qu’il apparaisse dans la période courante. Tu peux utiliser une date précise ou une plage de dates (timeline). Testons du 26 juin au 31 juillet. Pas sûr que ce soit suffisant pour faire un vrai site web, mais bon !

Galen : Faut aller vite, alors. Hmm. Mmh [00:04:00]

Fred : On va dire que ce projet demande 100 heures, soyons directs. Ça, c’est la colonne “total d’heures projet” que j’ai créée (colonne chiffres, nommée “heures”, mais tu pourrais mettre autre chose, ou rien). Et ici, tu vois le total. Si tu utilises ça pour tes projets, tu sais combien de temps globalement ils cumulent.

Disons 375 heures. L’important, c’est l’engagement global sur les projets. Puis les semaines projet, somme des semaines ici. Ici c’est le total de semaines et non le “start-stop” : la timeline ici donnerait la durée. Disons six semaines, ça concorde avec ce que j’ai mis. La somme s’ajuste en bas. J’ai aussi une “type de service” ; tu pourrais avoir SEO, développement web, etc. Ça permet de filtrer, trier.

Il y a diverses façons de gérer le time tracking. Ici, colonne “suivi du temps” : soit démarrer/arrêter pour traquer en direct, soit saisir manuellement. Donc, le 27, de 9h à… disons 10h34, Fred travaille sur ce projet. Voilà 1h34 précisément suivie.

C’est prévu pour alimenter d’autres calculs en aval. D’autres colonnes ici : “burn hebdo attribué”. Si un projet fait 100h sur 10 semaines, ça fait 1h/semaine à consommer. Alors tu attribues le “burn” que tu veux. L’engagement total ici, ce n’est pas juste Fred mais, si tu es cinq dessus, on l’indique. Pour DPM, on a l’automatisation (règle de calcul) à 6 heures par semaine (100 heures sur 6 semaines).

Et comme j’ai déjà enregistré 1h34, il reste 98,43h. Les colonnes de calcul sont automatisées (formules), mais tu pourrais les personnaliser. Tu as aussi un “burn hebdo planifié”. [00:08:00] Parfois, le besoin moyen est de 6h/semaine, mais tu sais que tu vas faire plutôt 10h/semaine les 3 premières semaines, puis 5h les semaines suivant.

Voilà pourquoi tu peux saisir ça manuellement. Même principe pour le “burn hebdo planifié par personne”. Si vous êtes deux dessus, chacun 5h — fait par formule aussi. Après, tu as le “burn hebdo réel” : combien d’heures réellement suivies divisé par le nombre de semaines déjà passées. Ça te donne le taux hebdo réel.

D’autres colonnes résument tout ça : heures/semaine restantes pour finir dans les temps (si tu dois tout finir cette semaine, il faudra plein d’heures !). Tu as aussi le “burn planifié à date”, “burn réel à date”, pour comparer l’avancée.

Tout ça alimente le widget Workload — ici, je crois que la colonne prise en compte c’est “assigned weekly hours” (ce qui rentre dans la charge du widget), plus le timeline.

Donc, si maintenant je me vois surcharge en semaines 26, 28 et 29 : soit tu décales le projet pour respirer, tu fais glisser la timeline, soit tu réattribues le projet à quelqu’un (par exemple, j’ajoute George). Maintenant la charge est partagée, c’est moins “sur moi seul”.

Tu peux jouer sur l’affectation, le calendrier, etc. Et tu peux cliquer pour dérouler la charge par personne et voir la part de chacun. Tu retrouves les infos détaillées dans une fiche (card view) toute neuve, beaucoup plus ergonomique qu’avant. Encore plus facile pour ajuster les paramètres d’un projet à la volée.

Galen : Ce que je trouve intéressant, c’est que tu as créé des champs personnalisés pour des infos comme les heures, les allocations des personnes, et tu utilises des formules pour suivre le burn, comprendre la charge, etc. Et Monday ajoute là-dessus une visualisation sur la vue Workload pour facilement simuler l’effet de changements sur l’équilibrage, tout visuellement. Mais si besoin tu peux revenir à la vue “table compacte” et affiner les données. Si les variables changent (avancement ou ralentissement, retard…), tu ajustes, puis discutes avec le client ou le sponsor pour proposer d’augmenter l’équipe ou de décaler, illustrations à l’appui.[00:13:00]

Fred : Oui, tu peux aussi voir à quel point chacun approche la limite (par exemple, viser à rester à 70 % de charge). Peut-être que j’ajoute un peu de tâches pour Fred, puis réajuste jusqu’à trouver le bon équilibre (un coup 90, 94 %, je retire…). Grâce à la prévision, tu peux éviter ces problèmes en amont. Et la vue est presque comme un Gantt personnalisé par personne, différent du diagramme Gantt projet classique où l’on voit tout. Tu peux donc voir comment Galen sera chargé sur 7 semaines ou plus, et éventuellement décaler les tâches.[00:15:00]

Du fait de la dimension visuelle, c’est parfait pour présenter à la direction ou aux sponsors qui veulent une vision synthétique et n’ont pas le temps de fouiller : tu montres “point rouge = problème de dispo, point bleu = OK” sans devoir afficher tous les chiffres.

Galen : Oui, j’aime beaucoup. Je voulais aussi aborder la granularité : parfois, on doit ajouter un designer juste quelques jours ici ou là, et on raisonne souvent par “burn semaine/plannifié”. Comment tu fais pour intégrer cela ? Monday part-il sur une charge fixe par semaine ?[00:16:00]

Fred : Cette configuration fonctionne sur des charges fixes, mais on peut aussi procéder autrement. Par exemple, un timeline global projet, et des sous-éléments (sub-items) pour le besoin du designer par exemple. Je te montre, hypothétiquement : projet du 12 juin au 31 juillet, mais le designer intervient du 8 au 18 juillet. On attribue George à cette période. Puis, tu vois le résumé cumulé sur la timeline principale, en activant “afficher le résumé sur parent”. Cela te synthétise la présence du designer. Si on multiplie les affectations, la colonne résumé s’ajuste.

Il faut faire attention aux affectations croisées (parente/sous-élément), mais conceptuellement, tu attribues un designer ou un développeur pour des périodes précises et cela se réfléchit automatiquement dans leur allocation sur le widget.[00:19:00]

Galen : Parfait, nous faisions ça aussi en agence. On allouait précisément chaque ressource. Mais parfois sur des projets types “agiles” ou avec équipe fixe, on travaille par capacité globale, pas besoin de granularité : 4 personnes, 8 semaines, la moitié de leur temps… Mais on peut tout à fait mixer selon les besoins projet, client ou interne.[00:20:00]

Fred : Monday permet vraiment de faire comme tu veux. Ce n’est pas limitant : c’est une boîte de Lego. On peut toujours trouver une solution, via configuration, via app, via automation (Make, etc.), même s’il y a parfois des contournements. C’est aussi ce qui rend mon travail toujours différent — chaque client apporte un défi, et soit on trouve une formule vite, soit il faut bricoler, mais ça marche !

C’est cette adaptabilité qui fait que Monday et d’autres outils récents grignotent le terrain face à des outils comme MS Project qui étaient très puissants mais peu flexibles, chers et complexes à prendre en main. Tandis que Monday, en quelques heures, tu maîtrises l’essentiel. L’enjeu, c’est surtout de bien faire coller l’outil à tes process.[00:22:00]

Galen : Est-ce qu’il t’est arrivé que des montages complexes explosent quand Monday sort une nouvelle fonctionnalité qui simplifie tout ?[00:22:00]

Fred : Non, Monday est très prudent, ils cassent rarement quelque chose. En revanche, on passe du temps à bâtir des contournements (comme les niveaux haut/bas) puis un jour Monday lance un outil Portefeuille… et tout ce qu’on faisait devient natif, simple et beau ! Parfois tu te dis : “mince, j’aurais aimé avoir ça il y a 3 semaines”. Mais au moins on avance, ils écoutent clairement leurs utilisateurs et communiquent tout en amont. Ça ne m’est jamais arrivé de voir une config brisée d’un coup.[00:24:00]

Et aujourd’hui, Monday se diversifie : outil généraliste, puis CRM natif lancé il y a 1 an et demi. C’était à ses débuts assez rudimentaire mais aujourd’hui c’est puissant, très convivial, bien plus simple à prendre en main qu’un Salesforce — emails, pipeline, activités, tout y est. Idem pour les équipes Dev (produit concurrent de Jira), et nouvelle solution Service pour les tickets support… Intuitif et formateur très rapidement.

Galen : Impeccable. Merci, Fred. La suite ?[00:26:00]

Fred : Je te montre la vue Gantt : tu l’utilises pour le projet entier, tu peux déplacer, mettre des dépendances (ex. projet Z dépend du D, si tu bouges D, Z suit). Tu regroupes par projet, par assigné ou par type de service (ex. webdesign). Par exemple, tu vois que tu as quatre déploiements “workflow” qui se chevauchent au T2-T3, donc tu peux ajuster avant d’être en surcharge.[00:28:00]

Dashboard : autre atout, tu as toutes les synthèses : nombre d’heures restant, burn rate moyen, répartition des types de projets… Tu composes tes vues personnalisées pour tous les besoins (planning ressource, rapport exécutif, etc.).[00:29:00]

Galen : Exactement ce qu’il faut pour piloter, et tu adaptes la communication à chaque public grâce à ces vues sur-mesure.

Fred : Dernière astuce : j’ai demandé à mon fils George de documenter ce tableau Monday — tu as toute la doc dans le contexte, avec description des vues, définitions des colonnes, formules à copier, etc. Tu peux même gérer des notes de projet partagées, taguer des collègues pour le suivi. Ça fait un vrai mode d’emploi accessible, super utile pour la formation et la continuité.

Galen : Super d’avoir tout centralisé.

Fred : Oui.

Galen : Merci beaucoup Fred d’avoir pris le temps de nous montrer tout ça : équilibrage des ressources, burn, diagrammes de Gantt… et merci de partager ta connaissance de Monday.

Mhm.