Vous entendez le terme RACI, et vous gémissez intérieurement. Loin de l’acronyme à la consonance un peu excitante, il peut souvent devenir une bête à créer, avec des maux de tête causés par le fait d’essayer de déterminer qui devrait se voir attribuer quel rôle pour chaque tâche ou produit à livrer.
Le tableau RACI (aussi connu sous le nom de matrice ou diagramme RACI) devrait être là pour vous faciliter la vie en tant que Chef de Projet, mais peut être l’éléphant dans la salle au début du projet, que personne ne veut compléter ou réviser, ou même utiliser dans ce cas. Comment pouvez-vous faire de votre RACI un outil utile qui peut vous aider, vous et votre projet?
Dans cet article, je vais vous aider à simplifier le processus RACI en vous montrant comment utiliser les graphiques RACI de la manière la plus efficace et adéquate, en vous donnant des conseils pour éviter les problèmes courants et en vous fournissant un modèle de matrice RACI à utiliser sur votre projet.
Premièrement, qu’est-ce qu’un tableau RACI?
En termes simples, il s’agit d’un outil qui identifie les rôles et les responsabilités par rapport aux tâches d’un projet.
Que signifie RACI ?
- Responsible = Responsable
- Accountable = Manager
- Consulted = Consulté
- Informed = Informé
Le RACI met en correspondance les tâches et les livrables avec les rôles de votre projet, et la prise de décision et les responsabilités sont attribuées à chaque rôle en utilisant les termes ci-dessus. Voyons donc un peu plus loin ce que chacun de ces termes signifie.
Responsable: Effectuer la tâche
Cette personne s’occupe de la tâche ou du produit à livrer. Ils sont responsables de l’exécution du travail ou de la prise de décision. Il peut parfois s’agir de plus d’une personne, mais essayez de minimiser le nombre de personnes impliquées.
Manager: S’approprier la tâche
Cette personne ou ce rôle est responsable de l’exécution globale de la tâche ou du produit à livrer. Ils ne feront pas le travail, mais ils sont responsables de s’assurer qu’il est finalisé. Idéalement, il devrait s’agir d’une seule personne plutôt que d’un groupe afin d’éviter toute confusion quant à l’identité du propriétaire réel de la tâche.
Consulté: Aider
Cette personne, ce rôle ou ce groupe fournira des renseignements utiles à l’exécution de la tâche ou du produit à livrer. Il y aura une communication bilatérale entre les responsables et les personnes consultées.
Informé: Garder l’œil ouvert
Ces personnes ou groupes seront tenus au courant des tâches ou des produits livrables. Il peut s’agir d’un rapport d’étape ou d’un rapport sur l’achèvement de la tâche ou des produits livrables. On ne leur demandera pas de retours ou d’examen, mais ils peuvent être touchés par les résultats de la tâche ou des produits livrables. Il devrait y avoir une communication unidirectionnelle avec ces rôles ou groupes.
Pourquoi devrais-je m’en soucier? Les avantages d’un tableau RACI
1. Simplification de la communication
La mise en place d’un RACI peut être utile tout au long de la vie d’un projet. Plutôt que d’impliquer chaque personne dans chaque décision, vous pouvez rationaliser la communication, impliquer les bonnes personnes au bon moment et accélérer les signatures et la prise de décision.
2. Éviter la surcharge du personnel
Vous savez ce que cela représente d’avoir les opinions de tout le monde et le cauchemar que cela peut être d’essayer d’intégrer tous les points de vue? Oui, c’est ici qu’un RACI peut être utile. L’avantage d’avoir la distinction entre Consulté et Informé, c’est que vous pouvez séparer ceux qui participent aux retours et ceux qui ne sont informés que de l’avancement de la tâche.
3. Éviter la surcharge de travail et les silos
Nous savons tous qu’un chef de projet porte souvent plusieurs chapeaux, assume beaucoup de responsabilités et souvent plusieurs rôles dans un projet. Le tableau RACI peut être un outil utile pour aider à déléguer et éviter l’épuisement des chefs de projet.. Cela permet également d’atténuer le fait d’avoir un seul point d’échec, où toutes les connaissances et la responsabilité d’une tâche reposent sur une seule personne, ce qui crée des silos.
4. Établir des attentes claires
Vous pouvez créer beaucoup de gains d’efficacité en utilisant un tableau RACI sur votre projet. Lorsque vous créez un RACI au début d’un projet, il peut être utile d’aider à définir les attentes quant à la personne qui gère ou est responsable du travail à venir. Les personnes impliquées dans le projet devraient être en mesure de voir clairement où elles doivent être impliquées et avec quelles tâches. Il peut aussi aider à éliminer la confusion en sachant qui est responsable en dernier ressort de l’achèvement d’une tâche. Il est particulièrement utile d’établir des attentes avec les intervenants de niveau supérieur qui sont informés sur le projet : cela leur permettra de savoir quels renseignements ils recevront dans le cadre du projet.
Quand dois-je utiliser un tableau RACI?
Un tableau RACI est-il utile pour tous les projets? En bref, la réponse est non. Si l’on ajoute trop de complexité et de processus à certains petits projets qui évoluent rapidement, cela peut en fait ralentir les choses et créer des bloqueurs. Ainsi, si votre équipe de projet est petite, que les rôles sont déjà très clairement définis ou qu’une structure similaire a déjà été utilisée avec succès auparavant, alors envisagez de simplement assigner des tâches aux personnes. Vous n’avez pas nécessairement besoin de définir l’implication de chacun dans chaque livrable.
Cependant, dans le cas de projets de plus grande envergure avec de multiples parties prenantes, le fait de ne pas utiliser un RACI et de définir clairement les responsabilités dès le départ peut entraîner des difficultés plus tard, lorsque les gens demandent pourquoi ils n’ont pas été impliqués, ou lorsqu’ils découvrent qu’il faut un autre niveau d’approbation. C’est un excellent moyen d’éviter les surprises et une trop grande participation des intervenants tout au long du projet, ce qui ralentit les décisions et le travail, et le projet dans son ensemble. En premier lieu, s’il y a de la confusion ou des questions concernant qui fait quoi ou participe à quoi, utilisez un RACI pour convenir des rôles et des responsabilités dès le départ.
Devrais-je utiliser un RACI sur des projets utilisant la méthode Agile?
La Scrum Alliance a publié un article qui contenait un ajout intéressant au tableau RACI pour tenir compte des différences dans la méthode Scrum, le RACI + F. Malheureusement, l’article n’est plus en ligne mais vous pouvez en trouver un résumé ici. F est l’abréviation de Facilitate, donc ce tableau utilise le RACI standard plus ce rôle supplémentaire pour quelqu’un qui anime ou entraîne. L’article soutient que l’ajout de ce rôle tient alors compte de la façon dont un projet Scrum est exécuté, et que les rôles peuvent être délégués en conséquence.
Cependant, ce rôle de Facilitateur semble être mieux assigné au ScrumMaster ou au Chef de Projet, ce qui ne fait qu’ajouter une couche supplémentaire d’informations au tableau. Je crois aussi fermement qu’il faut garder le RACI aussi simple que possible, et ajouter un autre rôle ne va pas dans ce sens.
Utilisez le RACI judicieusement sur les projets Agile
Une autre façon d’examiner les projets Agiles et le tableau RACI est qu’il y a déjà une répartition claire des responsabilités et de l’imputabilité : le Responsable étant l’équipe qui travaille sur le produit et le Manager étant le propriétaire du produit. Ensuite, vous n’avez plus qu’à identifier les contributeurs et ceux avec qui vous partagez des informations. Beaucoup des principes d’Agile permettent une communication étroite et régulière avec l’équipe, de sorte que les personnes qui doivent être consultées sont là et n’ont pas nécessairement besoin qu’on leur dise qu’elles sont des collaborateurs. Chaque projet Agile ne devrait donc pas utiliser le graphique RACI. Beaucoup de rôles sont implicites si vous suivez une Méthodologie Agile, comme Scrum. Évaluez vos besoins avant d’aller de l’avant avec un RACI-remember, ils ne sont pas nécessaires pour chaque projet.
Comment créer un tableau RACI
La merveilleuse Meghan McInerny a donné une conférence au Colloque DPM 2017, et a fait la suggestion géniale que le Seigneur des Anneaux est en fait un projet réussi, et que la Communauté est une équipe. Donc pour rendre cela un peu plus facile à comprendre, prenons ce projet comme exemple. Quel est le projet ? Apporter la bague au Mordor et au Mt Doom. (Juste un projet standard, n’est-ce pas… ?)
Étape 1: Identifier les rôles du projet
Pensez à qui est impliqué. Tout d’abord, j’ai créé le tableau ci-dessous énumérant les noms en haut. Ceci met en évidence la première chose à décider lors de la création d’un RACI : faites-vous la liste des rôles ou des personnes spécifiques ? Traditionnellement, vous devez définir les rôles fonctionnels en haut de l’écran. Cependant, je pense qu’il y a des cas où il est préférable d’utiliser des noms, et c’est souvent ce que je préfère.
Comment créer un tableau RACI. Étape 1: Identifier les rôles du projet
Raisons de préciser par rôle:
- Si une seule personne remplit plusieurs rôles
- Cela évite d’avoir à mettre à jour lors d’un changement de personnel.
- Cela évite d’avoir un mélange de noms et de groupes plus larges, par exemple, “client” ou “département X”
Raisons de préciser par le nom:
- Il est plus simple de définir qui est impliqué dans le projet
- Si plusieurs personnes remplissent des rôles similaires
Les rôles sont plus fréquemment utilisés, car il arrive souvent qu’une seule personne remplisse plusieurs rôles. Cependant, s’il y a plusieurs personnes qui remplissent un même rôle et que les tâches ne se chevauchent pas trop, il serait peut-être préférable d’utiliser des noms. Pour mon exemple du Seigneur des Anneaux, j’ai utilisé des noms (magicien comme rôle peut sembler un peu trop bizarre…), mais vous pouvez voir un exemple ci-dessous de rôles. Comme je l’ai dit, je préfère utiliser des noms pour attribuer clairement la responsabilité.
Étape 2: Déterminer les tâches ou les produits livrables du projet
Examinez le projet et décomposez-le en tâches et produits livrables clairs. Mettez-les dans la colonne de gauche de votre tableau. J’ai créé quatre tâches pour mon LOTR RACI (oui, un autre acronyme). Souvent, il y en aura beaucoup plus que cela, mais essayez de ne pas aller trop dans le détail, sinon le graphique pourrait devenir trop complexe pour être utilisé efficacement plus tard. Si vous suivez une liste claire des produits livrables pour le projet, vous pouvez également les énumérer. Comment créer un tableau RACI. Étape 2: identifier les tâches ou les livrables du projet.
Étape 3: Attribuer le RACI à chaque rôle et tâche
Passez en revue chaque tâche et réfléchissez aux différents rôles et à ce dont ils devraient être responsables. Chaque tâche ou produit livrable devrait avoir au moins un responsable et un manager. Assurez-vous qu’un seul rôle ou nom est attribué à l’obligation de rendre compte – c’est vraiment important. Réfléchissez bien aux personnes à consulter pendant que la tâche est en cours, et à celles qui devraient être informées une fois la tâche terminée. Jetez un coup d’oeil à mon exemple LOTR RACI ci-dessous. Frodon est responsable de la livraison de la bague au Mordor. Gandalf, en tant que leader du Mouvement, est manager. Cependant, Sam aide Frodon en cours de route – il est consulté, c’est-à-dire activement impliqué. (NB : vous n’êtes peut-être pas d’accord avec certaines de mes missions ci-dessous, mais bon, je n’avais aucune partie prenante avec qui en discuter et être d’accord!) Comment créer un tableau RACI. Étape 3: assignez le RACI à chaque rôle et tâche.
Étape 4: Mettez-vous d’accord avec votre équipe
C’est tellement important: alignez toutes les hypothèses que vous avez faites avec votre équipe, ne le faites pas en silo. Rassemblez la communauté ! Si vous n’avez pas passé en revue les rôles avec les collaborateurs, discutez rapidement de la façon dont vous avez mis sur pied le RACI et assurez-vous que tout le monde est satisfait de ses rôles et responsabilités dans le projet.
Étape 5: S’entendre avec les principaux intervenants du projet
Organiser un appel ou une réunion pour se mettre d’accord avec les principales parties prenantes du projet. Gandalf, Frodon et la Fellowship ne pouvaient pas s’appeler sur leur portable, alors ils ont tenu une réunion pour discuter et s’entendre. Essayez de faire en sorte qu’elle soit aussi allégée que possible afin d’éviter les commentaires difficiles à manier et les discussions qui prennent beaucoup de temps. Pensez aussi à la personne avec qui il faut communiquer une fois que tout le monde est d’accord.
Voilà votre tableau RACI! Maintenant, je peux mettre ça de côté et me concentrer sur mon projet, d’accord? Eh bien, non. C’est l’un des plus gros problèmes des documents comme un RACI: une fois créés, ils sont ensuite oubliés et consignés dans un dossier poussiéreux sur le serveur, pour ne plus jamais être ouverts. Comment en faire un document de travail utile?
Étape 6: Rendez-le utile pendant toute la durée du projet
- Lorsque vous réalisez une tâche ou un produit livrable, référez-vous au RACI et déterminez qui est responsable de quoi.
- Assurez-vous que ce qui a été établi au début d’un projet, les rôles et les responsabilités par rapport aux tâches, sont toujours exacts.
- Une bonne façon de le faire est d’héberger une version en ligne, en utilisant Google Docs ou Confluence, ou un outil utilisé dans votre organisation. Pour en savoir plus sur les outils de gestion de projet, consultez cet article ici. C’est une excellente façon d’amener les gens à s’impliquer davantage.
- Dans votre bilan à la fin d’un projet, utilisez le RACI pour voir comment les rôles et responsabilités assignés ont fonctionné. Aviez-vous besoin d’autant de personnes impliquées? Les personnes responsables ont-elles accompli la tâche ou fallait-il impliquer davantage de personnes? Les gens ont-ils été consultés et informés au bon moment?
Les pièges courants du RACI et comment les éviter
Comme je l’ai mentionné tout au long de cet article, il y a des inconvénients à utiliser un tableau RACI:
- Cela peut ajouter à la confusion par un manque de compréhension des différences entre les termes
- Cela peut prendre du temps à créer
- Il est souvent ignoré après l’approbation.
- Il peut ajouter une complexité inutile à un projet
- Il ne tient pas compte de l’approbation des tâches ou des produits livrables
Il y a donc de nombreux pièges courants auxquels il faut faire attention lorsque l’on crée une matrice RACI. Voici quelques mises en garde à votre intention et des moyens d’atténuer ces risques:
1. Le chef de projet, le maître d’œuvre de l’ensemble du projet
Souvent, par défaut, le gestionnaire de projet (ou le responsable de produit) est la personne ou le rôle responsable de tout. Puisqu’ils exécutent le projet, ils exécutent en fin de compte tout ce qui s’y trouve. Essayez de vous éloigner de cette ligne de pensée. Pensez où les producteurs d’œuvres devraient être responsables, c.-à-d. les concepteurs, les développeurs, les directeurs commerciaux, les services à la clientèle, les chefs de service, etc.
2. Confondre responsabilité et obligation de rendre compte
Ces termes sont assez proches dans leur définition, ce qui peut prêter à confusion, parce que le Manager (Accountable) est le rôle qui est le responsable ultime de la tâche ou du produit à livrer, tandis que le Responsable est le rôle qui fait la tâche. C’est là que d’autres types de définitions matricielles peuvent aider à clarifier. Je donne un aperçu ci-dessous de quelques alternatives connues.
3. Tension entre les personnes Consultées et Informées
Étant donné que Consulté a une connotation positive et implique que les personnes à qui ce rôle est assigné se sentiront plus incluses et leurs retours incorporés, cela peut parfois causer des tensions lorsque les personnes sont assignées à Informé. Ces dernières peuvent penser qu’elles ne sont pas au courant ou que leurs retours ne sont pas entendus. Les personnes ou les groupes informés verront le livrable une fois qu’il aura été complété. Veillez à ce que cela soit clairement communiqué dès le départ et qu’il y ait accord sur l’attribution des rôles, afin d’éviter les problèmes à l’avenir.
Quelques conseils pour réussir votre tableau RACI
- Assurez-vous qu’un RACI sera bénéfique pour le projet, pensez à la façon dont le RACI sera utilisé et pourquoi.
- Choisissez votre modèle et assurez-vous d’en comprendre les termes. Assurez-vous d’avoir une définition de ces termes à portée de main au fur et à mesure que vous travaillez, ou à partager à côté du tableau.
- Veillez à ce qu’un seul rôle soit marqué comme Manager, et non pas un groupe entier, pour vous assurer qu’une seule personne est propriétaire plutôt que plusieurs personnes, ce qui peut entraîner de la confusion et ralentir la prise de décision.
- Ceux qui sont Informés ne sont pas nécessairement tout le monde sur le projet, ce sont ceux sur lesquels la tâche ou le produit livrable aura un impact, ou ceux qui ont un intérêt direct.
- Même si vous créez le brouillon du RACI, ne le faites pas de manière isolée. Demandez aux principales parties prenantes du projet d’apporter leur contribution.
Quelles sont les alternatives à un RACI?
Voici quelques autres sortes de tableaux RACI, et les raisons de les utiliser.
RASCI
Probablement l’alternative la plus utilisée au RACI, le tableau RASCI représente: Responsable, Accountable (Manager), Supportive (Favorable), Consulted (Consulté), Informed (Informé). Les personnes favorables rendent compte des rôles au sein de l’équipe qui soutiennent le Responsable dans l’exécution de la tâche. La différence entre Favorable et Consulté, c’est que le Consulté donnera des informations, tandis que le Favorable participera activement à la tâche.
CARS
Aller plus loin avec le RACI, les partisans du modèle CARS affirment qu’il élimine l’information inutile que le RACI fournit. C’est l’acronyme de:
- Communicate = Communiquer – la consultation et l’information
- Approve = Approuver – l’approbateur qui prend les décisions
- Responsible = Responsable – comme dans le RACI, la personne qui effectue le travail
- Support = Aider (favorable) – couvre les personnes qui aident le Responsable dans son travail
Certains pensent que le modèle RACI attribue des termes qui sont assez évidents, c’est-à-dire que la responsabilité est souvent celle du chef de projet ou du propriétaire du produit, et que l’Informé est peut-être un éventail plus large d’intervenants dans le projet que vous n’avez pas défini. CARS devient plus spécifique aux actions, et comme le RASCI, ajoute le rôle Support (favorable) lorsque les tâches ne sont pas accomplies par un seul rôle ou une seule personne.
RAS
J’aime la simplification de celle-ci, car elle garde les termes Responsable, Approuver et Soutenir. Cependant, il ne tient pas compte du propriétaire de la tâche, ce qui pourrait créer de la confusion.
DACI
Relativement similaire au tableau du RACI, mais en remplaçant Responsable par Drivers (Dirigeants) et Accountable par Approvers (Approbateurs), poussant ainsi les descriptions plus loin vers des termes basés sur l’action. Cela permet de clarifier ce que ces rôles feront, là où il peut y avoir confusion avec la matrice RACI.
CLAM
Une variante du DACI qui, encore une fois, met davantage l’accent sur les actions en jeu que sur les rôles, c’est-à-dire Contributes (Contribue), Leads (Dirige), Approves (Approuve), Monitors (Surveille).
Dans l’ensemble, bon nombre des variations du RACI visent plutôt à définir les termes avec plus de clarté ou à préciser davantage les mesures à prendre afin que toute ambiguïté entre les rôles soit dissipée. Il n’y a pas beaucoup de différence entre les modèles en termes réalisation, donc souvent vous pouvez simplement revoir les différents modèles et choisir celui que vous préférez ou qui convient le mieux au projet.
Modèle Matrice RACI
This content is exclusive to DPM Pro Members!
DPM Pro Members get:
- Instant access to expert-crafted TEMPLATES to save you time.
- Workshops, mentorship, and community support to grow your career.
- Ebooks to guide you through the PM role.
Want in?
Are you Pro Member? Sign in to unlock the content.
Une étude de cas RACI
A titre d’exemple, j’ai récemment travaillé sur une pièce de découverte et de définition pour la mise en place d’un programme de fidélité, pour une marque de mode. Vous pouvez voir ci-dessous le RACI que j’ai créé (j’avais des noms dans le tableau, mais j’ai changé de rôle pour le rendre anonyme).
Comme vous pouvez le constater, il y a un bon nombre de tâches et de produits livrables, ainsi que des intervenants. En créant ce RACI, j’ai rencontré quelques conflits que j’esquisse ci-dessous :
Répartition entre l’Agence et le Client
Il y avait beaucoup d’intervenants du côté des clients, puis aussi en interne, à l’agence où je travaillais. Pour éviter de créer le plus grand RACI au monde, j’ai gardé ce tableau à l’intention principalement des parties prenantes côté client, l’agence ayant un rôle à jouer, car nous avions une petite équipe de notre côté. Dans le cas des petits projets, vous pourriez probablement répartir les rôles de l’agence également, mais j’avais évalué les besoins du tableau au début du projet et j’avais déterminé que ce tableau devrait être utilisé principalement dans l’intérêt de la gestion des intervenants externes.
Participation des noms et des groupes
Pour les intervenants principaux, je les ai regroupés au lieu de les nommer individuellement. Nous avons identifié les principaux intervenants de l’équipe de base, puis l’équipe élargie, de sorte qu’ils n’ont pas tous été fusionnés, mais nous les avons quand même gardés en groupes pour simplifier les choses.
Responsabilité totale du propriétaire du produit côté client
Étant donné que le propriétaire du produit côté client était un chef du projet important et un point central de diffusion de l’information de son côté, il aurait été facile de le rendre tout simplement Manager de tout. J’ai vraiment dû y réfléchir et essayer d’attribuer une responsabilité plus large afin d’éviter de créer un point d’échec unique et un cloisonnement. J’en ai ensuite discuté avec eux pour m’assurer qu’ils étaient d’accord avec l’approche. Toutefois, le propriétaire du produit avait encore tendance à être Manager d’un certain nombre de tâches.
Conclusion
Les gens trouvent souvent des problèmes avec les tableaux RACI, disant qu’ils ne sont pas assez granulaires, car ils ne décomposent pas ce que la personne à qui le rôle est assigné devrait réellement faire. Cependant, ce n’est pas à cela que servent les RACI. Rappelez-vous qu’un RACI n’est pas un plan de projet.
Un RACI est un document utile, à condition qu’il s’agisse d’un effort commun, qu’il soit utilisé après le début d’un projet et qu’il convienne au projet. Assurez-vous d’évaluer les besoins de votre projet dès le début et de faire en sorte que le RACI soit adapté à son objectif. Assurez-vous que tout le monde comprend les termes que vous utilisez (quel que soit le type de tableau que vous utilisez!).
Alors, qu’en pensez-vous ?
Utilisez-vous les tableaux RACI et dans quelle mesure les trouvez-vous utiles? Y a-t-il d’autres versions que vous utilisez que vous aimez (ou détestez!) et que vous voulez partager? Postez dans les commentaires ci-dessous pour continuer la conversation!