Les matrices RACI

Matrice d’affectation des responsabilités

Selon le PMBok®¹,

• La matrice d’affectation des responsabilités² (en anglais RAM: responsibility assignment matrix) est une grille qui montre les ressources du projet attribuées à chacun des lots de travail (work package).
• Cette matrice est utilisée pour illustrer les relations entre les lots de travail, ou les activités, et les membres de l’équipe de projet.

Plus généralement, elle indique les rôles et les responsabilités des intervenants, au sein de chaque processus ou activité. Cette matrice représente l’organisation du travail en reliant dans un tableau commun la Structure de découpage de projet (WBS) et la Structure organisationnelle du projet (OBS)³.

RACI

Un exemple de matrice d’affectation des responsabilités est la matrice RACI. RACI est un acronyme donné pour Responsible, Accountable, Consulted, Informed. En français ces termes peuvent se traduire par Réalisateur, Approbateur (ou Autorité), Consulté, Informé. Le PMBok® donne la définition suivante : Réalise, Rend des comptes (A), Consulté, et Informé.

La définition des « rôles » est la suivante :

Les avantages d’une matrice RACI

La principale fonction d’une matrice RACI est de lever toute ambiguïté quant aux rôles des personnes ou des équipes impliquées dans un projet. Cette matrice est particulièrement utile lors de projets ou de tâches complexes, impliquant plusieurs équipes, et/ou plusieurs organisations.

La matrice RACI va au-delà du « qui fait quoi ». Elle permet d’éviter plusieurs écueils

• La dilution de responsabilité : personne ne sait qui doit s’occuper d’une tâche,
• Les redondances : plusieurs équipes / personnes s’occupant d’une même tâche,
• Le non suivi de délivrables : en s’assurant que nous avons bien un A en face de chaque ligne / tâche,
• Les conflits potentiels entre équipes / personnes / organisations, en s’assurant qu’il n’y a potentiellement pas de recouvrement de responsabilité (ou que les recouvrements soient clairement identifiés).

Les étapes de construction d’une matrice RACI

Une matrice RACI se construit en 3 étapes :

Etape 1 : Liste des activités / tâches

Cette étape consiste à lister l’ensemble des tâches, des jalons, des déliverables d’un projet. En fonction de la phase du projet, cette liste peut-être plus ou moins détaillée.

Etape 2 : identification des parties prenantes

Il s’agit ici, d’identifier l’ensemble des parties prenantes⁴ impliquées dans la réalisation des tâches listées précédemment.

Attention, à cette étape, nous ne parlons pas obligatoirement de personnes, mais de fonctions. Dans de petites équipes, par exemple, une même personne peut avoir plusieurs fonctions. Par exemple, une personne peut être chef de projet, et conseillé technique auprès de l’équipe de développeur. Dans ce cas, il ne faut pas mettre 1 seule ligne dans la matrice, mais deux :

• 1 pour la fonction de chef de projet (avec probablement l’attribut A dans la colonne Projet),
• et 1 ligne pour la fonction de conseiller technique (avec l’attribut C dans la colonne développement).

Etape 3 : Définition des rôles et responsabilité

Probablement l’étape la plus longue : il s’agit ici d’attribuer, pour chaque tâche, un rôle (R, A, C, ou I) à chaque partie prenante.

Il est recommandé que chaque partie prenante, dans un projet ou une tâche, ne reçoive au plus, qu’un des types de participation / responsabilité. Si une partie prenante endosse plusieurs rôles, cela peut vouloir dire les rôles et/ou les responsabilités ne sont pas encore clairement établies. Cette règle n’est pas obligatoire : il peut arriver, dans le cas des petites équipes qu’un rôle soit assigné à plusieurs participations / responsabilité.

Quelques règles

Les avantages de la matrice RACI sont indéniables, mais à la condition que la matrice ne soit pas ambiguë, sur sa forme, comme sur le fond. Nous avons plusieurs écueils possibles :

1. Une mauvaise compréhension des termes utilisés, ou différentes interprétations de ces termes par les intervenants,
2. Un non-alignement des intervenants sur les participants, et responsabilités définies,
3. Les responsabilités définies ne sont pas cohérentes.

Eviter le premier problème nécessite de lever toute ambiguïté sur les tâches :

• Définir le plus précisément possible, les tâches et leur contexte. Attention aux intitulés flous, ou aux tâches qui nécessitent différentes responsabilités, en fonction de l’étape dans laquelle nous nous trouvons.
• S’assurer de la compréhension commune des tâches par tous les participants.

Eviter le second problème implique que la matrice soit construite collectivement. Cela peut prendre la forme de groupes de travail, ou toutes les parties prenantes discutent ensemble des rôles et des responsabilités. Il est indispensable que la matrice soit relue, et validées par toutes les parties prenantes.

Concrètement, la construction de la matrice peut se faire lors de trois à quatre réunions,

• La première réunion se focalise sur la définition des tâches et des parties prenantes / des fonctions,
• Les réunions suivantes permettent de remplir la matrice avec les rôles / responsabilités,
• La dernière réunion consistant en une relecture collective, et l’apport de corrections éventuelles.

De cette façon, l’approbation de la matrice est largement facilitée, puisque les différents intervenants ont participé à sa conception.

Enfin, plusieurs méthodes peuvent être utilisées, pour éviter le troisième problème (incohérence des responsabilités):

• En début de construction, il peut être intéressant de faire un rappel, auprès des intervenants, sur la matrice RACI, ainsi que les définitions des rôles,
• La présence d’un “coach” lors des différentes réunions. Une personne “extérieure” au projet, peut avoir un regard plus pragmatique / objectif vis-à-vis des tâches, et des responsabilités, et peut aider à prendre les décisions, en jouant le rôle d’arbitre,
• Il peut être intéressant également de mettre en place certaines règles, limitant les possibilités.

Par exemple :

• Pour chaque tâche, il faut un responsable, ou responsable/réalisateur, unique,
• Pour chaque tâche, il faut au moins 1 réalisateur,
• Mais un trop grand nombre de réalisateurs peut conduire à une ambigüité (qui réalise quoi ?). Si vous tombez sur ce cas, il faudra peut-être découper la tâche en plusieurs tâches, afin de mieux les assigner aux réalisateurs.
• Ajouter une tâche communication, n’est pas indispensable, mais utile pour ne pas négliger cet aspect,
• La différence entre personnes consultées et informées, doit être très claire. La communication avec une personne consultée est obligatoirement bidirectionnelle, alors que la communication vers les personnes informées est monodirectionnelle.

Les limitations et inconvénients des matrices RACI

Le principal inconvénient des matrices RACI est leur manque de flexibilité.

• Nous avons globalement 4 rôles. En fonction de la complexité du projet, il pourrait y en avoir plus. Le risque est également de négliger certaines parties prenantes, à qui l’on attribue un rôle du type C(onsultées) ou I(nformées), alors qu’elles pourraient avoir un rôle plus important que cela.
• Elle est construite dans un contexte bien précis. Il n’est pas rare de devoir construire plusieurs RACI pour différentes étapes du projet, ou d’avoir une très longue liste de tâches, pour y faire figurer une même activité, mais différentes étapes du projet.
• Une modification du plan projet, ou des fonctions nécessaires à son exécution, nécessite une révision de la matrice RACI, ce qui peut être assez lourd.

La construction d’une matrice RACI n’est pas automatisable : on peut trouver des produits permettant la construction de la matrice “vide” (en listant les tâches, et les parties prenantes), mais la définition des rôles et des responsabilités est obligatoirement une tâche manuelle, et collective.

Attention également aux potentiels problèmes rencontrés avec la matrice, lors du projet : si au cours du projet, malgré la matrice RACI, des questions apparaissent sur les rôles, ou sur les tâches, c’est que les choses n’ont pas été définies suffisamment précisément. Il convient, dans ce cas, de vite réagir en proposant des définitions, sans quoi, les questions deviendront récurrentes, et la matrice apportera, finalement, plus de confusion, que de clarté.

Les variantes

Il existe des variantes à la matrice RACI, en fonction des rôles supplémentaires que l’on souhaite y faire figurer. Parmi ces variantes, deux sont assez courantes

RACI devient RASCI (ou RASIC) lorsque l’on y ajoute le rôle de support. Cela peut s’appliquer, par exemple, dans les phases de transitions projets -> Opérations, ou l’identification des équipes assurant le support est primordial.

RACI devient RACI-VS lorsque l’on ajoute deux rôles

• Le rôle de Vérificateur,
• Le rôle de Signataire (Signatory en anglais),

Je vous laisse consulter la page anglaise de Wikipedia, qui liste quelques autres variantes comme RACIQ (Quality Review) par exemple.

Conclusion

Nous venons de voir l’importance des matrices RACI dans un projet. Certes l’outil peut paraître assez lourd à construire, mais il s’avère être extrêmement utile, voir providentiel, lorsque le projet traverse des difficultés, surtout pendant les phases transitoires.

Je joins à cet article, un exemple de matrice RACI réalisée avec Excel.

L’aspect collectif de la construction, est au moins aussi important que la matrice elle-même, car c’est le seul moyen d’obtenir

• La pertinence et l’exactitude de la matrice,
• Une meilleure compréhension des tâches du projet, et donc une adhésion des équipes.
• L’approbation des parties prenantes aux rôles et responsabilités,