Il y a quelques années, McKinsey a publié une étude qui montrait que 80 % des organisations interrogées estimaient que leur processus de prise de décision était inefficace — il prenait trop de temps et/ou les décisions prises n’étaient pas bonnes.
Près de la moitié des personnes interrogées considéraient que leur organisation ne prenait pas ses décisions assez rapidement. Les répondants disaient perdre beaucoup de temps dans une prise de décision inefficace — presque un tiers de leur temps — et ce pourcentage augmentait à mesure que l’on montait dans la hiérarchie de l’organisation.
Quelle pagaille, non ? Surtout alors que les entreprises s’efforcent de suivre la numérisation de tout.
C’est pourquoi le RACI est parfaitement adapté à cette période : dans tout le livre PM Book of Knowledge de l’Institut de Management de Projet, c’est le seul outil de gestion de projet qui se concentre sur les décisions — qui les prend et à quel niveau.
Il vous aide également à déterminer qui fait quel travail. Pour ces deux raisons, j’appelle souvent l’acronyme RACI une boîte de Pandore — un outil très simple qui dévoile toutes sortes de questions intéressantes sur l’autorité, l’autonomisation et la responsabilisation.
Si vous souhaitez un rappel sur l’outil RACI de base, commencez ici : Comment créer un tableau RACI (avec un modèle) et ici : Maîtriser les tableaux RACI en 30 minutes (vous devrez être membre pour accéder à ce mini cours). Vous pouvez également trouver un excellent livre blanc et d’autres ressources sur mon site web.
Le RACI sert à la cohésion d’équipe
Parce que j’ai appris le RACI en tant que consultante en changement organisationnel, j’en ai une approche un peu différente. Au lieu de penser à sa puissance pour la gestion de projet (ce qui est indéniable), je le considère d’abord comme un outil de construction d’équipe.
Mais que se passe-t-il dans une équipe lorsque les membres n’ont pas une vision claire de leurs rôles ? Voici quelques symptômes courants :
- Les charges de travail semblent déséquilibrées, certains membres de l’équipe en voulant à d’autres car ils n’assument pas leur part du travail.
- Double emploi, que les gens expliquent généralement par un problème de communication.
- Des personnes sont vexées si elles ne sont pas consultées avant que des plans ne soient établis.
- L’équipe a l’impression de gérer des urgences au lieu d’avancer de manière proactive.
- Stéréotypage de personnes issues d’autres services ou avec des identités professionnelles différentes
Tous ces éléments sont néfastes pour le moral de l’équipe, et pire encore, ils peuvent sembler être des problèmes entre les individus du groupe. Comme des conflits de personnalités. Mais la plupart du temps, il ne s’agit que de ce que les universitaires appellent une “confusion des rôles”, qui peut être résolue en clarifiant les rôles grâce à RACI.
Quelle déception de voir une équipe travailler pendant six mois sur un projet, pour qu’un supérieur hiérarchique vienne rejeter sa recommandation ! Et quelle frustration d’essayer de résoudre un problème sans un niveau de soutien suffisant ? Un vrai échange autour du RACI peut mettre en lumière ces problèmes avant que beaucoup de temps d’équipe ne soit gaspillé.
On remarque que les équipes bénéficiant d’une bonne clarté des rôles ont beaucoup plus de chances d’être des équipes performantes. Et, comme par hasard, les équipes performantes témoignent souvent d’un moral élevé également.
Problèmes courants avec le RACI original
Puisque McKinsey s’intéresse désormais à la prise de décision, ils ont également publié un article de blog sur les limites du RACI ici. De nombreux chefs de projet entretiennent une relation amour-haine avec cet outil. Un jour, une cliente m’a dit qu’elle préférerait mourir que de refaire un tableau RACI avec son équipe car « c’était comme regarder de la peinture sécher ».
Le premier problème est que le R (Responsable) et le A (Autorité/Approuvant) se confondent souvent. Tout l’intérêt de l’outil est d’éliminer la confusion des rôles, donc ce problème est plutôt ironique.
Le deuxième problème, c’est que si vous avez un projet complexe impliquant plusieurs personnes qui collaborent sur un livrable (plusieurs R), le démon de la confusion des rôles peut refaire surface.
Le troisième problème du RACI est qu’il n’intègre ni délai ni échéancier. Clarifier les rôles, c’est formidable, mais pas au détriment du respect des délais.
Le quatrième problème est que le rôle C (Consulté) peut parfois déborder, ses détenteurs ayant l’impression d’avoir plus de pouvoir qu’ils n’en ont réellement.
Qu’est-ce que le RACI 2.0 et quels avantages a-t-il sur le modèle original ?
Abordons ces quatre problèmes un à un, grâce à une version améliorée du RACI, que j’appelle RACI 2.0.
Problème n°1 : la confusion R/A
Avec notre RACI 2.0, nous opérons une distinction très claire entre ces deux rôles.
- Le rôle R accomplit le travail, ce qui inclut souvent la création d’un livrable. Cela peut consister à réaliser une action (comme faire une réservation de restaurant) ou à formuler une recommandation (« D’après mes recherches, je recommande d’engager cette agence, et voici les 3 raisons pour lesquelles. ») On considère que le rôle R (la personne responsable) est un rôle d’exécutant. Si vous ne produisez rien, il y a de fortes chances que vous n’ayez pas réellement un rôle R.
- Le rôle A prend les décisions. Dans RACI 2.0, nous définissons le A comme Autorisation ainsi que Responsable (nous pensons qu’Autorisation est plus clair). Peu importe comment vous l’appelez, soyez clair sur le fait qu’il s’agit de la personne responsable disposant de l’autorité pour prendre la décision finale concernant quelque chose. (Même exemple, décider où aller dîner. Ou accepter/rejeter la recommandation de quelqu’un d’autre). Ce rôle dispose également d’un pouvoir de supervision, ce qui signifie que cette personne peut dire : « Recommence et fais une deuxième version de ce que ce soit, jusqu’à ce que JE DÉCIDE que c’est suffisant. »
À noter que le Project Management Institute, avec le RACI original, précise clairement qu’il ne peut y avoir qu’UN SEUL rôle A par activité. C’est une prise de décision véritablement rationalisée et c’est la meilleure pratique. Mais dans la réalité, combien de validations différentes la conception d’un site web traverse-t-elle en moyenne ?
Surtout pour les travaux transversaux (qui impliquent plusieurs départements), il peut être très difficile de réduire le RACI à une seule personne décisionnaire. Dans RACI 2.0, nous encourageons les gens à regarder le nombre d’A initialement attribués et à le réduire autant que possible. Pas de garantie de l’amener à un seul.
Problème n°2 : Trop de R
Dans le RACI original, on peut assigner un nombre illimité de R à la création d’un livrable, ce qui reflète la réalité de la collaboration. Sauf que cela peut générer du travail en double et de la confusion : « Est-ce toi ou moi qui fais cette partie ? Et qui suit l’avancement de tout cela ? »
Dans RACI 2.0, nous avons créé un rôle R-Prime (ou R1) pour cette situation. Dès qu’il y a plus d’une personne dans le rôle R, désignez simplement l’une d’elles comme R-Prime. Ce R1 veille à ce que le livrable avance correctement (comme un mini-chef de projet pour ce livrable spécifique).
Plus il y a de R qui collaborent, plus le rôle de R-Prime devient essentiel. Il orchestre le travail de plusieurs personnes—mais cela ne signifie pas pour autant qu’il prend des décisions (cela reste du ressort du A).
Voici un exemple (basé sur l’exemple du SDA dans cet article sur le tableau RACI)
| Activité/Participant | R1 | R | A |
| Rédiger les contenus du site web | Sam Gamgee | Pippin Took | |
| Approuver les contenus du site web | Frodon Sacquet |
Cela signifie que Pippin travaille sur le texte AVEC Sam, mais en tant que R1, Sam doit s’assurer que l’ensemble du travail converge. Remarque : les personnes en R1 contribuent souvent ÉGALEMENT à la réalisation du travail.
Problème n°3 : Pas de planning ou d’échéances
Avec RACI 2.0, nous recommandons d’ajouter une colonne à votre tableau RACI indiquant la date limite de chaque tâche du projet. Rien n’avance vraiment dans le travail de projet transversal sans délai, comme nous l’avons tous appris à nos dépens. Ouf, celle-là est facile à corriger !
| Activité/Participant | R1 | A | Date limite |
|---|---|---|---|
| Rédiger les contenus du site web | Sam Gamgee | N/A | 3 avril |
| Approuver les contenus du site web | N/A | Frodon Sacquet | 5 avril |
Problème n°4 : Les C trop envahissants
Le rôle C correspond à "Consulté". Les C peuvent être des experts métier possédant une expertise précieuse à partager, et nous voulons réellement connaître leur avis sur un projet.
Mais ils ne sont pas des A, ce qui signifie qu’ils ne peuvent pas changer le cours du projet—ni même le ralentir. La personne en A peut solliciter leur avis ou s’assurer qu’ils ne sont pas tenus à l’écart, les remercier, puis l’ignorer si elle le souhaite. Les C ne peuvent ni approuver, ni opposer leur veto. Ils peuvent uniquement conseiller.
Vous pouvez toujours fixer une date limite pour la contribution des C. Après une certaine « date butoir », vous pouvez avancer avec votre projet. S’ils n’ont pas donné leur avis, vous pouvez leur envoyer un rappel (c’est là toute la force d’une date limite) et ensuite, vous êtes libre d’aller de l’avant. « Vous avez eu votre chance » en est le message.
Utilisez RACI 2.0 comme un langage
Nous aimons envisager RACI comme un langage que l’équipe projet et l’organisation peuvent apprendre à parler couramment. Nous voulons que nos clients deviennent des organisations « bilingues RACI ».
Quand vous êtes à l’aise avec RACI, il devient facile pour les collègues d’adapter leur rôle instantanément. « Hé, je suis débordé cette semaine, tu peux prendre mon R pour (ce livrable) ? »
On peut clarifier l’autorité sur le vif : « Qui a le A pour ça, au fait ? » ou plus probablement, « Appelons la hiérarchie, tout le monde croit avoir le A pour cette refonte de site ! » « Y a-t-il une date limite pour ces parties prenantes C ? Elles bloquent tout ! »
Le modèle RACI d’origine est-il dépassé ?
Non, les matrices RACI restent précieuses (à condition d’ajouter la colonne des échéances, voir ci-dessus). Mais leur élaboration demande du temps, il est donc important de bien choisir à quel moment les utiliser ou non.
Le lancement d’un projet qui implique plusieurs départements, zones géographiques et/ou fuseaux horaires différents est l’un des meilleurs moments pour réunir l’équipe transversale et élaborer collectivement une matrice RACI.
Travailler sur quelque chose de nouveau—une chose que vous n’avez jamais réalisée ensemble auparavant—est une autre excellente occasion de clarifier le rôle de chacun dès le début.
Les start-ups et les innovateurs évoquent souvent le fait de commencer avec un produit minimum viable (MVP), puis de tester l’idée sur le marché, de pivoter, puis parfois de pivoter encore.
Ce type d’agilité s’accorde mal avec les descriptions de poste (qui ont tendance à être assez larges et figées), mais fonctionne très bien avec la matrice RACI. La matrice de répartition des responsabilités que vous créez au début d’un projet peut évoluer et s’adapter au fur et à mesure de l’avancement du projet et des changements dans l’équipe.
Du moment que vous maîtrisez l’approche RACI, vous et votre équipe pourrez gérer les changements de rôle.
Votre expérience
Nous aimerions connaître votre retour d’expérience—le positif, le négatif, et même les difficultés—lors de l’application du modèle RACI classique ou lors de vos expérimentations avec le RACI 2.0.
Il existe de nombreuses façons d’apprécier les bénéfices du RACI—qu’il s’agisse de rendre les réunions plus efficaces, d’intégrer plus rapidement de nouveaux membres, ou de négocier davantage de ressources avec le sponsor du projet.
Pour plus d’analyses sur RACI et la gestion d’équipe, abonnez-vous à la newsletter de The Digital Project Manager, ou découvrez une alternative au RACI avec les matrices RASCI.
