Négliger son RACI, Une pelle pour creuser sa tombe (1)

Pour être intervenu « en pompier » sur des projets en crise, je suis à chaque fois surpris par la vacuité, le manque de précision ou l’inadéquation de la matrice des rôles et responsabilités (quand ce n’est pas son absence pure et simple) lorsque je fais un audit préalable au plan d’action. Faire un lien unique avec l’échec du projet est réducteur (une « catastrophe » est rarement l’effet d’une seule cause). Toutefois cette matrice reste une des pierres angulaires d’un projet. C’est la raison pour laquelle je vais l’aborder en détail, mais compte tenu du sujet, je vous propose de voir les différents aspects en plusieurs fois.
.

Revenons donc aux fondamentaux.

Qu’est-ce que la matrice des rôles et responsabilités ? Elle est plus connue par son acronyme anglo-saxon: RACI.

C’est donc un outil synthétique qui décrit le « qui fait quoi » au cours d’un projet (ou d’un ensemble de projets). Elle ne s’attache pas aux personnes dénommées (Pierre, Paul, Jacques) mais à la fonction dans l’organisation (Chef de projet, Responsable application, Responsable infrastructure…) qui est la structure pérenne d’un projet (les personnes passent, les organisations restent).

RACI_small

A quoi sert un RACI ? Le RACI est un des outils qui sécurise le déroulement d’un projet en indiquant à chaque acteur du projet le rôle exact qu’il occupe sur une tâche, une activité ou dans un processus donné. Il y a donc une notion de segmentation et de complétude, mais le RACI ne décrit jamais comment cette tâche, cette activité ou ce processus se déroule.

Vu sous cet angle ceci apparaît simple, mais il en est tout autrement. Le premier écueil est celui de la terminologie anglo-saxonne portée en français intelligible.

Que signifie RACI ?

Commençons déjà par ce qui est simple :

  • Vide. On l’oublie un peu facilement, mais une case d’une matrice RACI peut être vide et c’est tout à fait normal. Dans ce cas, aucune action n’est requise.
  • I (= Informed): Informé. J’aborderai plus loin la question de l’émetteur de l’information. toutefois, bien que la notion soit simple à comprendre il ne faut jamais oublier que  …. « Trop d’information tue l’information ».
Trop d'infomation tue l'information

Crédits photo – M. Jacques Darolles – Publié avec sa permission – Panneau d’Officier Mécanicien Navigant d’un Boeing 747-200

  • C (= Consulted): Consulté. Contrairement à l’informé, la personne consultée à l’obligation de réagir, c’est à dire de répondre à la consultation. Ceci ne signifie en rien qu’il doit toujours apporter une information additionnelle, et la réponse peut être « je n’ai pas de remarque à faire ». C’est donc un contributeur.

Le silence ne vaut jamais réponse à quelque niveau de la matrice que ce soit. Le silence est dangereux car l’interprétation fréquente qui en est faite est « le silence vaut approbation » … ce qui est faux et dangereux. Si la personne consultée ne répond pas, les causes peuvent être multiples (de l’absence de compréhension de la question auquel peut se greffer la crainte de demander, à la volonté délibérée de refuser de répondre pour ne pas manifester son opposition ou pour ne pas endosser une responsabilité). Comme disait la grand-mère de Madame le maire de Lille … « Quand c’est flou c’est qu’il y a un loup ».

 Ensuite viennent deux concepts plus difficile à appréhender:

  • R (= Responsible [for doing]): celui qui fait. Pourquoi n’ai-je pas utilisé le mot de « responsable » ? simplement parce que ce concept n’est pas celui qu’il faut mettre en lumière. Le R dans un projet est celui qui porte la responsabilité de faire le travail, c’est à dire celui qui le réalise.

 Cette personne est donc chargée de mener à bien l’ensemble des tâches avec les moyens qui lui sont dévolus. Si ces derniers ne sont pas suffisants (temps personnel ou capacités personnelles si elle est seule, quantité, qualité et disponibilité des ressources affectées si elle coordonne une équipe… ), elle doit prendre toutes les mesures utiles et nécessaires dans son périmètre de responsabilité. Si ces mesures excèdent ce périmètre de responsabilité, il devra y avoir une escalade afin que des mesures correctives soient prises par la hiérarchie.

Peut-on avoir plusieurs R ? Si on considère R comme responsable, on voit que la question n’a pas de sens car plusieurs responsables = pas de responsable. Vous voyez pourquoi j’ai centré R sur « celui qui est chargé de la réalisation ». Si on a plusieurs R sur une même activité, il faut segmenter cette dernière pour déterminer par tâche un périmètre unique de responsabilité.

  • A (= Accountable): celui qui rend des comptes. Le A dans un projet est celui qui porte la responsabilité d’approuver la conformité du résultat du travail effectué. Alors pourquoi ne pas l’avoir appelé « Approbateur » ou « Autorité » comme le suggère Wikipedia ? Simplement une fois de plus parce que ces termes sont trop réducteurs.

Finalement, on peut se dire que c’est génial d’être A, on attend sans rien faire et on sanctionne les R ….. faux et archi-faux !

Un A ne peut pas être passif car la délégation (de faire) ne se conçoit pas sans contrôle. Nous le verrons dans les prochains épisodes, mais le A est celui qui a la tâche la plus compliquée car sa tête est sur le billot, mais ce sont bien souvent les autres qui font que la hache tombe ou non. C’est ce qu’on appelle …. L’art du commandement.

Considérez qu’avec de nombreux calculs on peut remporter la victoire, redoutez leur insuffisance. Combien celui qui n’en fait point a peu de chances de gagner !

(Sun Tzu – L’Art de la guerre – Article 1 : de l’évaluation)

Peut-on avoir plusieurs A ? Au niveau le plus haut d’un projet ou d’un ensemble de projet, ceci n’est pas possible. Il y a une personne unique ou une entité qui est chargé au final d’approuver et de rendre des comptes pour l’ensemble. A des niveaux inférieurs, et si tant est qu’il y ait une segmentation claire des aires de responsabilité, c’est tout à fait possible, mais au niveau de l’activité (la ligne du tableau), il en va comme du R, il n’y aura qu’un seul A.

Peut-on cumuler A et R ? Cette conformation est tout à fait possible. C’est même la conformation normale de certaines activités de projet comme par exemple l’organisation d’un comité de suivi projet par le chef de projet.

Alors au final, qui va informer, A ou R ? Si vous avez compris le raisonnement, ce peut être aussi bien A que R, et c’est une question de contexte (sensibilité de la communication, contexte politique ou opérationnel, accord explicite entre A et R ….). On peut décider que lorsque l’information est opérationnelle / fonctionnelle, elle est plutôt du ressort de R et quand elle est organisationnelle / managériale, elle est plutôt du ressort de A. Une autre façon de voir serait de dire que l’information descendante (vers les opérationnels) est du ressort de R et l’information ascendante (vers la direction) du ressort de A. Dans tous les cas, l’information doit être univoque et concertée.

Je vois déjà poindre le nez des concepts de maîtrise d’oeuvre et maîtrise d’ouvrage …. et c’est donc la raison pour laquelle je vais au plus vite m’éloigner de ces notions très franco-françaises. Pourquoi ? Tout simplement parce que MOE et MOA ne sont pas assimilable à R et A. Ceci sera d’ailleurs traité dans le prochain billet.

La suite … est ici.

Mieux nous connaître … Effixens.fr.

Les commentaires sont fermés.