RACI, Give and Take Matrix : même combat ?

Tous les contextes projet ont leur organisation spécifique où peuvent émerger des rôles particuliers. Une question triviale vient alors à l'esprit de tous et toutes : qui fait quoi ? Quelles sont les responsabilités de chacun·e ? Comment s'assurer que toutes les tâches nécessaires au bon fonctionnement de l'équipe et du projet seront réalisées ? Voici quelques outils pour s'en sortir.

Le RACI

Le principe

L'approche la plus évidente pourrait être de lister les tâches, lister les opérations nécessaires au bon fonctionnement d'un projet, et de se demander qui fait quoi dessus. C'est le principe de base du RACI. Loin de désigner un quignon de pain particulièrement sec et difficile à avaler, il s'agit de l'acronyme de "Responsible, Accountable, Consulted, Informed". Il s'agit d'un atelier où l'on va réfléchir en termes de profil, c'est-à-dire qu'on va se demander quelles sont les attributions du chef ou de la cheffe de projet, de l'équipe de développement, de l'équipe de test, etc. En effet, le but de cet atelier est de décortiquer chaque action nécessaire à la réalisation d'un projet ou à la vie d'un produit, et de se demander pour chacune d'entre elles :

• qui en est responsable, qui a autorité sur cette action. Oui, le "A" est totalement tiré par les cheveux, mais que voulez-vous, en français "Responsable" ça aurait fait un deuxième R. Peu importe comment on l'appelle, la personne qui "a le A" est la seule et unique responsable de l'action, c'est elle qui porte toute la responsabilité de la réalisation ou non de l'action ;
• qui la réalise, c'est-à-dire qui doit réaliser l'activité. Il peut y avoir plusieurs personnes qui ont le R. C'est le rôle du A de sous-traiter l'activité au R. Parfois, c'est le A qui réalise directement l'action. On peut donc cumuler le A et le R ;
• qui doit être consulté·e pour cette action. Le ou les C ne font pas l'action et n'en sont pas responsables, mais on doit quand même leur demander leur avis. Les C sont tenu·e·s de répondre à cette sollicitation avant que l'action soit prise ;
• qui doit en être informé·e. Ce n'est pas que la personne que vous mettrez en copie du mail pour "laisser une trace". Les I sont spécifiquement informé·e·s de la réalisation de l'action.

Il peut arriver, sur certaines actions, qu'il y ait des personnes qui ne soient pas R, A, C, ou I. Certains rôles n'auront peut-être aucune tâche où ils sont R, A, C ou I. Dans ce cas, il faut respirer un grand coup et, pourquoi pas, questionner la pertinence de sa présence sur le projet.

On peut aussi faire un RACI sur un sujet plus précis, par exemple pour clarifier le rôle entre plusieurs personnes de niveaux hiérarchiques équivalents mais avec des responsabilités différentes. À titre personnel, j'ai souvent fait des RACI avec un client pour clarifier les rôles et responsabilités entre chef·fe de projet MOE, chef·fe de projet MOA, Scrum Master, Product Owner, testeur·euse, etc. dans des structures où tous ces rôles n'étaient pas toujours clairement définis. Voici un exemple de ce qui pourrait ressortir d'un atelier "RACI" :

‍

‍

Comment mener l'atelier

Une heure peut suffire pour établir un RACI. Il s'agit de lister les différentes tâches et d'attribuer les R, A, C et I à chacun des rôles. Il y aura probablement des discussions, voire des désaccords sur l'attribution des lettres aux différentes rôles. Ainsi, je vous conseille de commencer par ce qui est consensuel avant d'en arriver à la discussion. Parfois, par peur de la "confrontation" ou d'un désaccord, on va chercher à tordre le modèle, par exemple en mettant plusieurs A sur une action, ou bien trop de R. Parfois aussi, certaines personnes vont demander à être informées alors que ce n'est pas forcément pertinent pour elles. Je vous conseille de laisser ces discussions se faire et ces points de vue se confronter, car ils peuvent être symptomatiques d'un mal plus profond dans votre organisation, qu'il ne faut pas mettre sous le tapis.

Avis et cas d'usage

Le RACI a un énorme avantage : il s'agit d'un outil facile à appréhender car il constitue l'approche la plus intuitive pour se répartir les tâches au sein d'un projet. Il permet aussi très précisément de savoir quoi faire : pas besoin d'être autonome et intelligent·e, un tableau vous dit quoi faire ! En revanche, il est nécessaire de le réactualiser à chaque nouvelle tâche, donc ce n'est pas forcément un outil très facile à maintenir.

Attention cependant à bien garder à l'esprit que, même si l'on réalise un RACI en fonction des rôles, il est important de le mettre à jour, notamment lorsque l'équipe change. En effet, même si une personne reprend le rôle de quelqu'un sur le projet, ça ne veut pas dire que cette personne a les mêmes compétences ou les mêmes envies que la personne qui l'a précédée.

Comme exprimé, le RACI a l'avantage d'être intuitif à faire et à comprendre, mais paraît plutôt rigide une fois qu'il est fait. Je vous propose maintenant de parler de la Give and Take Matrix, qui s'intéresse aux attendus plutôt qu'aux tâches.

Give and Take Matrix

Le principe

Se répartir les tâches c'est bien, mais il y a fort à parier que vos projets sont plus complexes qu'une simple liste de tâches régulières à dérouler. Dans ce cas, il peut être opportun de se dire que si la liste des tâches peut évoluer, les attentes des uns envers les autres, elles, demeurent des constantes. C'est le principe de la "Give and Take Matrix" : vous proposer de construire un tableau qui détaille ce que chaque rôle attend de l'autre. On parle aussi de "Matrice des Attendus".

La matrice se présente sous la forme d'un tableau à double entrée, avec en lignes et en colonnes les dénominations des rôles qui composent l'équipe. Sur la diagonale, on propose de décrire les responsabilités de chaque rôle vues par lui-même. Ensuite, on remplit chaque case du tableau comme suit ; pour la case en ligne A et en colonne B, on va indiquer deux choses :

• ce que A attend de B ;
• ce que A apporte à B.

Comme pour le RACI, on peut le faire à l'échelle d'une équipe ou bien sur un nombre d'individus plus resserré.

Comment mener un atelier "Give and Take Matrix"

Au moins une heure sera nécessaire à la réalisation de cet atelier, tant il peut être riche en discussions. Voici le déroulé que je vous conseille, avec les durées à adapter en fonction de la taille du groupe :

• introduction et accueil (5 min) ;
• chaque rôle réfléchit à ses responsabilités ("sa diagonale") ; si plusieurs personnes ont le même rôle, elles se mettent d'accord sur leur vision de ce rôle (10 min) ;
• chaque rôle réfléchit à ce qu'il attend des autres rôles et à ce qu'il apporte aux autres rôles ("sa ligne") (15 min) ;
• chaque rôle vient renseigner sa ligne sur la matrice en explicitant éventuellement (15 min) ;
• en groupe, chaque rôle lit ce que les autres attendent de lui et ce qu'il apporte aux autres, et renseigne ses responsabilités vues par lui-même puis voit quels sont les points d'accord et les divergences (15 min).

‍

Voici, par exemple, la même équipe que précédemment, qui a fait l'exercice de la "Give and Take Matrix" :

‍

Avis et cas d'usage

La Give and Take Matrix est un outil qui peut être assez puissant pour clarifier les rôles et responsabilités de chacun et chacune, mais surtout pour verbaliser les attendus et éléments nécessaires de tous et toutes pour avoir une expérience positive sur le projet. Lorsque la vie du produit ou du projet sera plus tumultueuse, il sera plus simple de se référer aux attendus des un·e·s et des autres plutôt que de mettre à jour une liste de tâches. De plus, cette matrice fait davantage appel à l'autonomie de l'équipe que le RACI.

Deux approches

Bien que le RACI et la Give and Take soient deux approches différentes pour clarifier "qui fait quoi ?" sur un projet, sont-elles à opposer réellement ? Au final, quelle que soit la méthode qui vous parle le plus, l'essentiel est de se lancer et de provoquer cet atelier avec votre équipe !

‍