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

Comme je l’ai indiqué dans l’article précédent, les rôles A et R ne sont en rien liés directement aux concepts franco-français de maîtrise d’œuvre (MOE) et maîtrise d’ouvrage (MOA) … mais comme l’acronyme est anglo-saxon, il y a une certaine logique. On peut donc dire que le RACI va découler :

  • Du projet et de son organisation (ce qui est traité ici),
  • De la liste des tâches,
  • … Et bien sûr, du mode de réalisation.

RACI et projet

Le RACI s’insère dans l’ensemble contractuel du projet, c’est-à-dire liant directement plusieurs parties à la réalisation d’un objectif commun.

Prenons ici un exemple pour illustrer le propos.

La société [NUMBER1] veut mettre en place un portail de services à l’attention de ses clients. Après étude, elle a retenu:

  • Un éditeur de solution [PORTAIL],
  • Un prestataire [PREST] pour la mise en œuvre et les développements du portail,
  • Un hébergeur internet [HEBERG].

[PREST] a la possibilité de faire appel soit à ses ressources, soit à des ressources externes en sous-traitance ou en expertise (incluant [PORTAIL] … si nécessaire). En termes de RACI, on aura la conformation suivante :

RACI - Overview
Ce qui est vrai avec un prestataire externe … est tout aussi vrai avec un prestataire interne (c’est le cas des grands groupes dans lesquels les prestations informatiques sont déléguées soit à une filiale dédiée à l’IT, soit à une division spécialisée dans l’IT).

Pourquoi deux RACI différents ? Simplement parce que le client [NUMBER1] – dans le cas du schéma – n’a rien à voir dans les relations contractuelles entretenues par le prestataire [PREST] avec ses sous-traitants et experts.

Que se passe-t-il si le client [NUMBER1] exige de connaître et approuver le recours à la sous-traitance par [PREST] ? En terme de RACI … rien. Le prestataire [PREST] est la seule partie au contrat et ses sous-traitants ne sont pas liés directement au client. Rappelons que le RACI s’attache à la fonction, pas à la personne. Si la ressource sous-traitée est une fonction, elle apparaît comme telle au RACI et considérée comme une ressource de [PREST] (transparent pour le client). En terme contractuel, c’est affaire de juristes (et donc hors de notre propos).

Que se passe-t-il si le client choisi un mode d’exécution en régie plutôt qu’une prestation au forfait ? Une fois de plus, en terme de RACI … rien. Rappelons le encore, le RACI s’attache aux fonctions et aux rôles et responsabilité au sein d’une organisation. Dans le cadre de la régie, ce qui change vraiment, c’est la façon de gérer le projet du côté du client.

En réalité, et nous le savons tous, si les fournisseurs font correctement leur travail (et ceci dès la proposition commerciale), il y aura pour chaque relation contractuelle un RACI propre … et c’est là que va se situer le problème.

RACI_Detail
Prenons ici l’exemple de l’hébergeur [HEBERG] et imaginons qu’il fournisse à son client [NUMBER1] une prestation de type cloud. Toute une partie de la relation contractuelle qui est liée à l’exploitation (une fois la solution mise en œuvre et livrée par le prestataire [PREST]) est hors du périmètre du projet. Toutefois, les obligations décrites dans le contrat peuvent aussi être une contrainte. En effet, il se peut que le contrat ne couvre pas la période de projet ou … qu’il la couvre avec des obligations particulières et un RACI précis.

Chaque RACI individuel (ici …. 0.1, 0.2 et 0.3) peut interagir avec le RACI global (RACI #1). Si tel est le cas, il va donc falloir pour les tâches impactées soit ajuster les contrats, soit en tenir compte dans le RACI global.

Comme vous le voyez … il faut que le client [NUMBER1] connaisse très bien ses contrats (ou qu’il soit bien accompagné), et sache le cas échéant anticiper les besoins futurs ou ne pas se bloquer pour des évolutions futures.

On peut en déduire une fois de plus que ce qui est important dans le RACI est la notion de tâche accomplie (ce qui ne signifie pas ‘déléguée’) et pas la notion de MOE / MOA.

RACI et organisation de projet

Il faut garder à l’esprit qu’un projet est avant tout l’exécution de la relation client-fournisseur dans laquelle chacun doit tout faire pour que le projet soit livré complet, conforme, dans les délais et budgets impartis.

Le RACI a aussi pour but de garantir que chacun reste dans son rôle sur son périmètre de responsabilité. Détaillons et réduisons un peu le schéma du début.

RACI_Relation_Detail
Si on regarde de façon un peu plus macro le projet, on voit au premier coup d’œil que chacun est responsable de ses propres ressources, c’est-à-dire les ressources qu’il a directement mises au service du projet (dans certaines organisations plus complexes, il y a des chefs de projets techniques, infrastructure, métiers …. qui reportent tous au chef de projet principal).

Dans le cas qui nous intéresse, le chef de projet [PREST] est globalement responsable vis-à-vis du chef de projet client [NUMBER1] ce qui est cohérent puisque « R (= Responsible [for doing]): celui qui fait ».
Au niveau général, le chef de projet [NUMBER1] est comptable du résultat « A (= Accountable): celui qui rend des comptes » vis-à-vis de la société qui l’a mandaté pour ce projet.

La problématique de la délégation de faire

Attendre les ordres en toute circonstance, c’est comme informer un supérieur que vous voulez éteindre le feu : avant que l’ordre ne vous parvienne, les cendres sont déjà froides
(Sun Tzu – L’Art de la guerre – Article 3 : Des propositions de la victoire et de la défaite)

Comme j’ai eu l’occasion de le dire dans mon précédent billet, la délégation ne se conçoit pas sans contrôle efficient, et ceci est d’autant plus vrai pour celui qui est en position A.

Toute la difficulté réside dans la capacité à donner un niveau suffisant d’autonomie pour que le projet ne soit pas sclérosé par l’administration, tout en maintenant un niveau de contrôle satisfaisant.

Croire que ceci se fait uniquement sur la base d’un reporting … c’est se bercer d’illusions. Je sais à quel point les organisations sont friandes de reporting, mais il ne faut pas craindre d’affirmer encore et encore que seul l’échange verbal basé sur un questionnement pertinent et la capacité à ne laisser aucune zone d’ombre peut vraiment offrir ce niveau de contrôle. Il ne faut jamais hésiter à poser et poser encore les questions qui dérangent jusqu’à l’obtention d’une réponse satisfaisante.

Le RACI doit donc être suffisamment clair et détaillé pour que chacun comprenne ce qui est dans son périmètre d’action et c’est ce que nous verrons dans le prochain billet.

La suite … est ici.

Mieux nous connaître … Effixens.fr.

Les commentaires sont fermés.