Peut-on faire du travail d’équipe en droit ?
Et aussi un peu de nostalgie, d’agacement et des tableaux (pour changer)
Bonjour,
Bienvenue dans cette 6ᵉ édition de ma newsletter dédiée au Legal Practice Management et au Legal Design. La barre des 500 inscrites et inscrits est dépassée, on vogue gentiment vers les 600. Merci à vous de m’accorder ce temps de lecture.
Aujourd’hui, on va s’attaquer à un monstre : l’idée que le travaille juridique est un travail solitaire.
Depuis 3 ans je suis responsable pédagogique du LAB EFB.
J’ai pris la suite de Mélik Boudemagh, et je passe définitivement les rênes à Fabien Masson le 31 décembre.
J'ai profité de mes fonctions pour tenter de corriger un défaut qui touche 95% des avocats et des juristes. Un défaut qui m’a privé d’un certain nombre de soirées, coincé au bureau et qui est devenu une obsession.
L’incapacité à savoir travailler en équipe.
Je n’ai pas dit travailler “à plusieurs”, j’ai bien dit travailler en équipe.
Ça requiert notamment de :
#1 Réinventer sa façon de travailler
#2 Utiliser un véritable outil de gestion de projet
#3 Imposer un langage universel fait de livrables, de jalons, et de tâches
#4 Savoir définir correctement une “tâche”
#5 Assigner toutes les tâches à des jalons.
#6 Exiger que les coéquipiers “pitchent” leurs contributions
#7 Procéder à la rétroingénierie de son livrable final
#8 Se réjouir qu’on détruise votre beau château de sable.
#1 Réinventer sa façon de travailler
Boris est un collaborateur plutôt sénior et brillant dans un grand cabinet. Il fait du contentieux et gère de gros dossiers.
Un jour, pour un dossier plus complexe que d’ordinaire, on lui dit de “prendre quelques juniors” pour l’aider. Boris voit dans cette offrande un fardeau, parce qu'il va falloir la piloter cette nouvelle équipe.
Et Boris, il est plus confortable tout seul.
Boris me dit qu’il a convoqué l’équipe pour faire une réunion, avec plateaux repas et tout et tout. Chacun a pris des notes, on s’est réparti le travail de recherches.
Ses coéquipiers doivent revenir avec leur partie.
Boris relira tout et fusionnera l’ensemble.
Mais là, j’annonce à Boris que rien ne va.
Boris a voulu se rassurer en faisant partir son équipe sur de la rédaction.
Mais il ne pilote pas son équipe, il lui délègue le travail qu’il ferait seul.
La première étape du chef d’équipe est solitaire. C’est préparer les outils que l’équipe va utiliser.
“Qu’on me donne quatre heures pour couper un arbre, j’en passerais deux à aiguiser ma hache”.
C’est une citation que Lincoln n’a jamais prononcée mais qu’on lui attribue.
Conservons l’idée.
Il faut un outil qui puisse recevoir les contributions de chacun des membres de l’équipe et les transformer en actions. C’est tentant de s’en passer et de fonctionner au feeling. Ça passe les 5 premiers jours. Après, la complexité devient telle qu’on regrette d’avoir grillé cette étape.
#2 Utiliser un véritable outil de gestion de projet
Qu’on appelle cet outil, “outil de pilotage”, “ERP”, “outil de gestion de projet”, au final, ça ressemble à un tableau qu’on partage au sein de l’équipe..
Monter un tel tableau prend du temps.
Ce n’est pas choquant d’y investir une demie journée voire une journée entière, avant même de convoquer la première réunion.
C’est même un exercice particulièrement fécond. Il contraint le chef de projet à visualiser tout le projet de A à Z, à imaginer un déroulé qui sert d’hypothèse de base et à anticiper les questions de fond qui vont se poser.
Boris m’a montré avec fierté qu’il avait monté un tableau sur Excel pour gérer.
Que son tableau était joli ! Trop joli.
Il y avait des jolis contours faits à la main, des belles cellules fusionnées des titres insérés joliment au-dessus de quelques lignes.
Un tel tableau ne permettait pas de piloter quoi que ce soit.
C’était une simple liste, la liste de Boris.
Avec cette jolie mise en forme, plus aucune fonctionnalité d’Excel ne marche.
Si les chefs de projets montent leurs outils dans Excel, c’est parce qu’un tel outil est avant tout une base de données. Comme chacun l’enrichit individuellement, cette base agrège rapidement des dizaines, voire des centaines de lignes avec plein de colonnes.
Donc, si le tableau fait mal aux yeux quand tout est affiché, c’est normal.
Ce n’est pas un document, mais un “outil”.
On ne le lit pas in extenso, on utilise les fonctions de filtres et de tri que permet Excel pour isoler les infos qui permettent de répondre à des questions :
- “Que reste-t-il à faire sur ce sujet ?”
- “Y a-t-il encore des tâches pendantes pour ce jalon ?”
- “Qu’est-ce qu'untel ou unetelle a accompli ou doit encore faire ?”
- “De quoi doit-on parler au prochain point ?”
#3 Imposer un langage universel fait de livrables, de jalons, et de tâches
Selon moi, le tableau idéal pour gérer un projet est constitué des trois listes, chacune isolée dans un onglet à part : les “livrables”, les “jalons” et des “tâches”.
La logique c’est que :
Toute action qu’un coéquipier accomplit doit avoir une existence dans ce tableau en tant que tâche,
Toute tâche dans le tableau doit être assignée à un jalon (réunion avec le client, deadline, point d’équipe, etc.),
Toute tâche doit aussi se rattacher à un livrable final. Les livrables finaux constituent, ensemble, ce qui marque la fin du projet (le jeu de conclusion finalisé).
C’est un fonctionnement assez universel que je trouve particulièrement efficace pour tout type de projet. Je le dégaine dès que nécessaire et il s’est toujours révélé efficace.
Le fait d’identifier les livrables finaux oblige à déconstruire le résultat envisagé, à appliquer la méthode SMART. Et donc à vite monter en compétence sur le sujet.
Poser les jalons amène à créer le rétroplanning, à anticiper les moments où “ça va passer tout juste”, même plusieurs mois à l’avance.
Imaginer les tâches à produire d’un jalon à l’autre permet de simuler le projet intégralement.
Précisons qu’Excel n’est pas l’idéal pour faire des liens entre les informations d’onglets différents.
L’idéal, c’est de partir sur des outils du type Airtable, Notion ou Monday, etc.
#4 Savoir définir correctement une “tâche”
Dans le tableau que Boris m’avait montré, on voyait des lignes intitulées : “Recherches sur la contrefaçon de droit d’auteurs”, “Recherches sur la concurrence déloyale”, “Recherches de pièces”, “Déterminer le plan”, etc..
En colonnes, des deadlines et des noms de membres de l’équipe.
Parfois une tâche était assignée à deux personnes, parfois trois, parfois à “tout le monde”.
De telles lignes, ce ne sont pas de vraies tâches.
Une tâche, c’est quelque chose qui prend entre 15 min. et 2h. Et si ça dépasse on scinde en deux tâches.
Ça commence par un verbe d’actions et ça se résout par un “rendu” qui formalise le résultat. Quelle que soit la tâche, elle doit se traduire par un paragraphe sur un doc Word, une diapositive Powerpoint, un projet de courriel, etc.
Par conséquent :
On n’intitule pas une tâche : “Faire des recherches sur la contrefaçon de droits d’auteurs”, ou “Vérifier la faisabilité de la contrefaçon du droit d’auteur”.
On écrit : “Faire une fiche Droit applicable sur la contrefaçon du droit d’auteur”.
Et on aura prévu que cette Fiche Droit applicable contient une mineure, une majeure, l’avis de l’auteur sur la pertinence, les recommandations (pièces complémentaires à aller chercher, informations à confirmer, etc.).
Grâce à ces exigences, la personne qui se voit assigner cette tâche sait exactement ce qu’elle doit faire. Produire un document dont la forme lui impose d’explorer tous les aspects de fond dont le chef de projet a besoin.
En langage process, on dit qu’une tâche doit avoir un “enregistrement”.
Cela veut dire que pour chaque tâche qu’il assigne, Boris doit identifier la forme que le résultat doit prendre. Ça le conduit à anticiper sur ce qu’il doit faire de ce travail.
Par exemple, demander à quelqu’un de restituer des recherches, ça ne sert à rien, ce n’est pas exploitable. C’est beaucoup plus efficace de lui demander de “Rédiger une argumentation à trous” pour soutenir un point.
Même sans avoir tous les éléments, si le résultat est validé, le rendu sert de base aux tâches suivantes. Lesquelles viseront à “Adapter le rendu avec les nouvelles infos”, “Faire une V2”, etc.
#5 Assigner toutes les tâches à des jalons.
Boris assignait des dates butoir aux tâches.
Mais ses coéquipiers, qui étaient pour la plupart collaborateurs, avaient d’autres dossiers à travailler en parallèle, et parfois des urgences qui les court-circuitaient.
Au début, ils prévenaient en avance de leur retard, en s’excusant. Puis ils ont laissé Boris les relancer, ce qui était épuisant mentalement pour lui, et même un peu vexant.
Pour amener chacun à effectuer sa tâche dans les temps au sein d’une équipe où il y a quasi le même niveau hiérarchique, il faut laisser jouer deux leviers de pression : la crainte du jugement public et l’envie de briller en public.
Concrètement, les coéquipiers ne sont pas tenus de réaliser leur tâche et de livrer leur rendu pour une date précise, mais pour un point qui, lui, est prévu à une date précise.
Chaque réunion d’équipe constitue un jalon parmi d’autres, et on positionne toutes les réunions au moment où l’on construit le tableau de gestion de projet.
On procède sous la forme d’un rétroplanning, en posant d’abord les dates qui nous sont imposées (rdv clients, dates butoir, etc.). Et ensuite on intercale les points d’équipe dont on estime avoir besoin pour rythmer l’accomplissement des tâches.
Ce fonctionnement présente des avantages :
C’est simple à suivre pour le chef de projet. Pas besoin d’ouvrir son tableau en permanence pour voir s’il y a des tâches en souffrance. On laisse venir les points d’équipe.
Ça donne l’ordre du jour de chaque point d’équipe. Un peu avant le point, il n’y a qu’à ouvrir le jalon : la liste des tâches devant être revues ou validées constitue l’ordre du jour.
Pas de problème si on décale le point : on embarque toutes les tâches à revoir dedans.
Le point d’équipe devient une réunion productive. Dans une réunion productive, tout le monde regarde le tableau de projet et tout ce qui se dit, fait l’objet d’une inscription dans ce tableau en direct (créer une nouvelle tâche, ajouter un jalon, commenter la tâche d’un coéquipier, valider une contribution et créer les tâches de son plan d’actions, etc.). Pas de prise de note individuelle, pas de synthèse.
Ça pousse à la ponctualité : si un coéquipier n’a pas effectué sa tâche, il doit le reconnaître devant toute l’équipe. On repousse sa tâche au prochain point d’équipe au son de la foule qui clame “Shame ! Shame ! Shame !...”. Ça calme. A l’inverse, s’il est ponctuel, l’équipe le constate aussi.
#6 Exiger que les coéquipiers “pitchent” leurs contributions
Boris voulait faire de la co-construction, travailler en mode “Agile” (sans trop savoir ce que le mot recouvre). Chaque coéquipier comprend qu’il peut à n’importe quel moment déverser sur lui ses avis, ses débuts d’idées, ses “il faudrait que…”.
Comme Boris était content d’avoir créé un tel esprit de participation, il a accueilli les apartés à la machine à café, les mails fleuves avec plein de réflexions dedans. Puis il s’est rendu compte que ça lui prenait 80% de son temps et il a refermé les vannes.
Le problème n’était pas qu’il se faisait bouffer, le problème c’est qu’il n’avait pas donné de règles pour garantir son confort.
Travailler en mode co-construction avec une équipe, c’est comme passer un marché.
Le chef d’équipe se rend disponible pour examiner les contributions de tous, sur tous les aspects du projet.
En échange, il impose à chacun de pitcher ses contributions, et uniquement dans le cadre d’un jalon (un point d’équipe par exemple).
Le pitch, c’est une vente.
Tout coéquipier qui considère que son idée est valable doit faire une proposition qui expose un problème, propose une solution et un plan d’actions prêt à l'emploi. L’équipe ou le chef d’équipe doivent être dans la position où ils n’ont plus qu’à dire “oui” ou “non”.
Ça fait le tri.
uiconque veut présenter une idée doit l’avoir travaillée un minimum. La suite immédiate d’un “oui”, doit être l’inscription pure et simple dans l’outil des tâches que le contributeur avait imaginées.
En échange de cette exigence de travail et d’engagement, quiconque inscrit son idée pour un jalon a la certitude qu’elle sera écoutée et fera l’objet d’une décision.
Même si en pratique, on amendera la contribution en direct, il demeure qu’en réunion, on ne crée pas, on valide.
La création c’est réservé aux ateliers, aux brainstormings, et il y a des règles à respecter pour que ça soit utilisable.
Très important : même une contribution rejetée doit être saluée. Parce qu’on respecte le travail qu’y a investi le coéquipier pour la proposer.
Parce qu’en écartant une piste, on a contribué à renforcer la certitude sur les choix existants.
Vous voyez ce qu’il se produit ? On glisse doucement vers des sujets de management.
#7 Procéder à la rétroingénierie de son livrable final
Boris a appliqué tous les principes que je viens d’exposer.
Le projet “glissait sur l’eau”. Des difficultés, certes, comme pour tout, mais pas de “coup de flippe”.
Le tableau de projet pensait pour Boris, respectait les deadlines pour lui.
Boris pouvait se permettre le luxe de travailler sur d’autres sujets en parallèle, d’oublier le projet et d’y revenir dès que besoin. L’outil le remettait à jour très vite.
Bref, Boris disposait d’un système.
Sauf qu’est arrivé le moment où il a fallu le sortir ce jeu de conclusion de l’enfer (48 parties, 130 pages, 400 pièces…).
Et Boris ne voulait pas devoir se retrouver dans la position de tout reprendre pour rédiger le premier jet. On aurait perdu 70% du travail déployé par l’équipe.
C’est à ça que sert l’onglet des livrables. A préparer le terrain pour que les contributions de l’équipe génèrent d’elle-même un premier jet du livrable final.
En droit, le livrable final d’un projet s’incarne généralement dans document. Si l’on veut que les contributions de chacun s’insèrent et composent une première version acceptable, il faut déconstruire le document en ses composantes de base.
Ce travail est impossible à faire si on part sur un format classique de conclusions, ou de contrats, voire de consultation. Où tous les sujets sont noyés dans une prose écrite selon l’inspiration du moment.
C’est sur ce point que le Legal design a un rôle important à jouer.
Les habitués savent que je milite pour l’usage de matrices dans le travail de rédaction. Ces matrices sont une façon de préparer le terrain. Elles impliquent d’atomiser un document ou un ensemble de documents en blocs
Par exemple, si vous adoptez ma méthode de rédaction des conclusions, vous savez que les prétentions produisent des moyens, que chaque moyen se soutient en 5 temps et que chacun de ces temps se traite au format N1, N2, Référence, Citation.
Ce travail implique de se projeter dans le livrable final et préparer le terrain en lui choisissant une matrice qui vous fournira les blocs à produire (et pour chacun, les règles de rédaction).
Par conséquent, Boris ne visait pas “un jeu de conclusions de 130 pages pour telle date”. Il visait “35 blocs rédigés pour telle date”.
Ces 35 blocs ne sont qu’une hypothèse.
Peut-être qu’il en aura 50 car l’équipe aura trouvé de nouveaux développements.
Peut-être qu’il en aura 27 car l’équipe aura écarté certaines pistes.
Peut-être que les blocs finaux seront différents de ceux qu’il imagine.
Il demeure que grâce à cette hypothèse, Boris peut identifier les rendus à produire dans les jalons qui précèdent. Ainsi, de tâche en tâche, on récupère le rendu précédent, et on l’enrichit (un peu comme quand on monte le process d’une prestation de services en Legal practice Management).
#8 Se réjouir qu’on détruise votre beau château de sable.
Travailler en équipe, c’est rigoureux, c’est méthodique et c’est ingrat.
On travaille des scénarios dans le détail, puis on ajoute un effort supplémentaire dans le seul but de placer ses coéquipiers dans la position la plus confortable possible pour tout remettre en cause.
Et pourtant, tous les semestres, des centaines d’élèves du LAB EFB écrivent dans leur rapport de fin de projet qu’ils ont adoré découvrir le travail en équipe.
C’est ce que j’ai tenté d’appuyer ces trois dernières années en tant que responsable pédagogique.
Il faut admettre que ça s’est compliqué : de plus en plus d’élèves avocats sont saturés de travail par les cabinets qui les emploient en alternance et n’ont pas le temps de vivre à fond cette expérience.
Alors un message pour certaines et certains dans la profession. Si vous avez des élèves avocats qui font le LAB, plutôt que de leur dire que l’EFB ne sert à rien, intéressez-vous à leur projet, à leur méthodologie.
Inverser la logique, et voyez ce que eux, peuvent vous apporter.
Vous seriez surpris.
Moi, ils me surprennent tous les semestres.
Ressources
Pour l’entrée en matière en gestion de projets, je vous recommande la Boîte à Outils du Chef de Projet de Dunod (Jérôme Maes, François Debois).
Pour faire de meilleures réunions, Passez en mode Workshop chez Pearson m’a souvent fourni l’inspiration. (Jean-Michel Moutot, François Xavier Duperret et David Autissier).
Et si le travail en équipe vous intrigue, je vous remets cette vidéo de Legal Pilot où nous avions parlé gestion de projet avec Victor Billette de Villemeur, Kristina Lazatian et Valère Sède.
On se retrouve dans un mois
Passez de bonnes fêtes ! J’ai pas mal travaillé sur les contrats, je pense que je vais faire un point là dessus. Ou pas, on verra ce que 2024 inspire !
www.linkedin.com/in/romainhazebroucq