Make IT Strategic

Very nice post. This will help possible client to get a quality person.

A ma connaissance, il n'y a pas véritablement d'experts en diagramme Ishikawa. Par contre, ce type d'outil est utilisé par de nombreuses catégories de consultant. Baccou Bonneville Consultants utilise régulièrement cette représentation graphique.

Cordialement,

Serge Baccou
Cogérant
Baccou Bonneville Consultants

concept très intéressant! existe-t-il des consultants experts pour ce genre de graphique? merci

Même si cette version fonctionne dans votre organisation, il reste que "R : Responsable" et "A : Acteur" est une mauvaise traduction française de la version originale. C'est très exactement pour dénoncer cette mauvaise traduction que j'ai écris cette blog note.

Utiliser une mauvaise traduction peut poser quelques problèmes d'interprétation notamment avec des nouveaux collaborateurs ou avec des sous-traitants. Une mauvaise interprétation est dramatique car elle change le sens des rôles et responsabilités !

Il serait préférable de proposer à votre organisation (au PMO par exemple) une correction même si ça ne sera vraiment pas simple à appliquer.

Dans ma structure nous avons une autre interprétation du RACI

R : Responsable
A : Acteur
C : Concerné
I : Informé

C'est hétérodoxe mais cela fonctionne , et c'est un vocabulaire partagé dans l'entreprise. (Mais pas vraiment par la communauté)

Et cela fonctionne , c'est au Responsable de mobiliser les acteurs dans , son rôle et de leur demander des comptes.

J'enregistre le S : Support (parce que ne trouvais pas de rôle pour des contributeurs)

Enjoyed your 6 outlined steps, and I agree that Continuous Improvement cycles are important. But even more so is QC, you're right I don't think any support desk or team should be without a Quality Control Manager

Ce que tu décris coincide avec mon utilisation du RA(S)CI

Il n'y a pas de façon type de faire un RA(S)CI, car son objectif est justement de définir les activités et les responsabilités afin que chacun s'engage sur son rôle.
C'est pour quoi il faut bien que chacun s'entende sur la signification de chaque rôle
En tant que 'R', tu es sensé garantir que tout sera réalisé comme prévu, c'est bien le rôle du chef de projet
Le 'A' est pour le donneur d'ordre, le maitre d'ouvrage, les décideurs... de la tâche concernée
Attention, le RA(S)CI est à utiliser avec plusieurs niveau de raffinement, et pour chaque activité où tu as été mis comme 'R', tu peux la décomposer pour déléguer certaines sous-tâches pour lesquelles tu serais 'A' et d'autres intervenant seraient 'R'
De la même façon que les 'décideurs' ne vont pas contrôler toutes les activités et ne se mettront 'A' que sur des points spécifiques et stratégiques (sauf s'ils ont le temps de tout controler...)

Quant au 'S', effectivement, si tu attends des inputs de la part d'autres intervenants, il est important de les faire apparaitre afin d'obtenir leur engagement (et celui de leur hierarchie)

Cela ne me choque pas qu'un chef de projet soit R en non A dans un RACI. C'est le cas dans le RACI que j'utilise en ce moment. Dans ce RACI, le A est un manager de pôle qui pilote plusieurs chefs de projet. Ensuite, vos collaborateurs peuvent être R en plus ou à place de vous. Par contre, l'usage de S semble approprié et nécessaire à votre contexte.

Je suis chef de projet mais dans le RACi qu'on me propose je ne suis pas en A mais en R sur toutes les lignes. cela me gene etant donne que je ne serais redevable et imputable (la reunion de ces temes traduit bien accountability) de rein. ia;je tort de penser que je devrais etre A sur certaines taches ou mes collaborateurs seraient en R (j'ai une equipe legere de 3 seniors finance, programme et suivi-evaluation)? de plus il n'y a pas de S dans ce qu'on me propose or mon projet est manager dans le systeme comptable global de l'entreprise et je suis tres dependant des inputs des financiers sur les reporting ne devraient-ils pas etre visbles en S?

J'ai quelques remarques sur l'usage des 'rôles'
Selon moi (et l'expérience), il ne faut définir qu'un seul responsable (R), c'est celui qui pilote (et éventuellement réalise) l'action
(A) est bien l'approbateur, mais pas seulement hiérarchique. Il doit bien y avoir l'accord du management, mais d'autres approbateurs peuvent être nécessaires, comme la qualité ou le client
(C), c'est bon, je l'associe au rôle d'expert qui peut apporter un avis, un conseil, ou même simplement un utilisateur qui peut apporter son expérience pour info
(I) rien à ajouter

Par compte, en lien avec ma façon de voir le (R), j'utilise systématiquement le (S) Support, qui apporte les ressources nécessaires à la réalisation de la tâche

Pour une organisation projet, il y aurait donc le chef de projet qui serait (R), le management en (A), les contributeurs en (S), les experts en (C) et ceux qui veulent en (I)