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

Comme je le faisais remarquer dans l’article précédent, il faut que le RACI soit clair et détaillé. Ceci implique que le RACI doit s’attacher aux tâches et aux profils, et bien sûr au mode de réalisation du projet.

RACI et tâches

C’est finalement le travail le plus facile à faire. En général, un projet est organisé en phases successives (par exemple : « design, réalisation, test, mise en œuvre, support ») qui sont coordonnées (par exemple : « gestion de projet, coordination fonctionnelle, coordination technique »). En détaillant chaque phase et chaque module de coordination, on arrive à un niveau suffisant pour le RACI. Les deux écueils à éviter sont :

  • Un découpage trop macro (par exemple : « comité de pilotage »).
  • Un découpage trop micro (par exemple : « création de la version 1 du compte rendu de comité de pilotage », « envoi de la version 1 du compte rendu de comité de pilotage », « lecture du compte rendu de comité de pilotage », …).

Mais alors, comment savoir si on est à la bonne maille ou si on doit, soit regrouper, soit détailler ? C’est simple :

  • Si une tâche a plus d’un R ou d’un A, ou qu’on a une option pour l’un quelconque des rôles (par exemple : dans un cas il est C, dans un autre il n’est rien) c’est qu’elle doit être détaillée pour lever l’ambiguïté.
  • Si plusieurs tâches similaires en thème ou en fonctionnalité adressent les mêmes profils, et que ces profils ont les mêmes rôles quel que soit la tâche, ceci signifie qu’on peut grouper les tâches.

Un RACI est un outil vivant. Si de nouvelles tâches sont identifiées en projet, il faut penser à les inclure. Ceci peut poser un problème lorsque le RACI fait partie des éléments contractuels d’un projet. Il faut dans ce cas exiger que le nouveau RACI soit approuvé comme avenant contractuel et l’acter au niveau des organes de gestion du projet. Ce point n’est pas négociable.

Si vos soldats, d’audacieux qu’ils étaient auparavant, de-viennent timides et craintifs, si chez eux la faiblesse a pris la place de la force, la bassesse, celle de la magnanimité, soyez sûr que leur cœur est gâté ; cherchez la cause de leur dépravation et tranchez-la jusqu’à la racine.

(Sun Tzu – L’Art de la guerre – Article 9 : De la distribution des moyens)

RACI et profils

Le RACI va jeter une lumière crue sur les rôles et responsabilités de chacun des acteurs du projet. A ce titre, on peut dire que c’est un outil clivant. Deux écueils menacent le RACI.

  • L’approche binaire : Les deux seuls profils qui apparaissent en colonne sont « Client » et « Fournisseur » sans plus de détail. En projet, chacun est donc libre de s’organiser comme bon lui semble dans son périmètre. On rencontre ce type de RACI assez fréquemment chez des éditeurs qui ont un RACI type pour la mise en œuvre de leurs solutions, ou des sociétés de service dans leurs propositions commerciales. Ceci est insuffisant pour l’exécution du projet. Deux options s’offrent dans ce cas :
    • Exiger un RACI plus précis : C’est la solution recommandée. Le client va mentionner clairement les différents rôles présents dans son organisation (en fournissant les fiches de poste associées le cas échéant), et le fournisseur va segmenter son équipe en rôles.
    • Faire du RACI un livrable de projet : cette solution est à éviter car elle est postérieure à la conclusion du contrat et peut s’avérer complexe à gérer. Je me souviens avoir vu un client ne pas valider le RACI après en plus de 60 versions en 4 mois !
  • L’approche nominative : C’est un travers qui se retrouve chez certains clients. Chaque personne est nommée en tant qu’individu. En général, une telle approche dénote soit une totale méconnaissance des rôles au sein de l’entreprise, soit une volonté de ne pas décider, soit une incapacité à aller au bout du processus. On a typiquement ceci dans des entreprises :
    • Qui se sont réorganisées mais qui pour des raisons « politiques » ont laissé telle ou telle personne conserver des responsabilités qu’elle ne devrait plus avoir (exemple : on a centralisé les achats de fournitures de bureau de l’entreprise sur une seule personne, mais Mme Machin conserve quand même les achats de fournitures de bureau pour son service parce qu’elle a l’oreille de la Direction et que personne n’a voulu lui ôter cette friandise après une énième jérémiade du type « on ne me fais plus confiance ! »).
    • Dans lesquelles les individualités sont fortes et les rivalités interpersonnelles aussi. Chacun a son pré carré dans lequel il fait tout en se comportant en « M. Le Comte ».

RACI et mode de réalisation du projet

C’est ici que l’exercice prend une complexité particulière et requiert à la fois de l’expérience et de la capacité d’abstraction. Deux modes existent : le forfait et la régie.

Rappelons au passage que le mode forfait n’est pas assimilable à une obligation de résultat, pas plus que la régie ne l’est à une obligation de moyens (ce sont des termes juridiques, bien souvent dévoyés, et dont l’intérêt majeur est de déterminer qui a la charge de la preuve d’une inexécution ou d’une mauvais exécution d’une obligation contractuelle).

Trêve de digression et sans entrer dans les détails, il est important de comprendre qu’une prestation au forfait entraîne une obligation de livrer « complet – conforme » la prestation décrite au prix décrit, dans le délai annoncé et en suivant le planning contractuel. Le prestataire est donc libre des moyens qu’il met en œuvre si tant est qu’il respecte son obligation. Le client participe activement pour les tâches qui lui sont dévolues en respectant le planning (par exemple : participer aux réunions et expliquer comment se déroulent les processus, fournir un fichier des articles …).
Dans le cadre de la prestation en régie, c’est le client qui joue le rôle du prestataire au forfait. Le prestataire en régie va fournir la capacité de travail avec une ou des ressources dont il est garant du bon niveau d’expertise.

Rappelons au passage que l’Homme de l’Art a un devoir général de conseil et d’alerte à l’égard de son client et ce quel que soit le mode choisi – forfait ou régie. Ce devoir peut aller jusqu’au refus d’exécution ou au retrait si les circonstances l’exigent.

Forfait ou régie, le mode influe peu sur les tâches elle-même (à l’exception notable du suivi des charges en j/H et coûts), mais l’impact est non négligeable sur les R et A (en potentiellement sur les C et I) au sein de chaque tâche. Il y a donc une véritable revue de cohérence à faire pour éviter que ne soient sous la responsabilité du prestataire ou du client soit des tâches qui n’ont rien à y faire dans ce mode d’exécution, soit des tâches qui sont affectées au mauvais profil.

Prenons quelques exemples :

  • Forfait de mise en œuvre d’une solution SAP par une équipe complète du prestataire
    • Signature du relevé des temps des consultants du prestataire par le client : IMPOSSIBLE.
    • Suivi de présence des consultants par le client : IMPOSSIBLE, doit être fait par le prestataire.
    • Paramétrage de la solution : Aucune action du client sur aucun des rôles RACI (sauf dérogation prévue au contrat), ce dernier ne peut que vérifier que le résultat du travail du prestataire sur la solution produit bien fonctionnellement le résultat attendu.
    • Validation des spécifications fonctionnelles : seul le client peut le faire.
  • Prestation de développement en régie d’une étiquette code-barres sur laquelle le prestataire fournit un développeur
    • Adaptation du paramétrage de la solution : Seulement si la ressource fournie par le prestataire est annoncée comme étant capable de de faire.
    • Modification d’autres formulaires ou coordination technique : IMPOSSIBLE, la ressource est dédiée à la fourniture de la prestation décrite.
    • Signature du relevé des temps du consultant du prestataire par le client : OBLIGATOIRE

Si vous n’êtes pas familier de l’exercice, le mieux est de vous faire accompagner en expertise par un cabinet de conseil comme Effixens.

Commencez par vous mettre au fait de tout ce qui concerne les ennemis ; sachez exactement tous les rapports qu’ils peuvent avoir, leurs liaisons et leurs intérêts réciproques ; n’épargnez pas les grandes sommes d’argent ; n’ayez pas plus de regret à celui que vous ferez passer chez l’étranger, soit pour vous faire des créatures, soit pour vous procurer des connaissances exactes, qu’à celui que vous emploierez pour la paie de ceux qui sont enrôlés sous vos étendards : plus vous dépenserez, plus vous gagnerez ; c’est un argent que vous placez pour en retirer un gros intérêt.

(Sun Tzu – L’Art de la guerre – Article 13 : De la concorde et de la discorde)

Avant de clore cette série d’articles, je voudrais évoquer le cas particulier des normes de développement.

Certains clients très experts disposent de ces normes qui décrivent la façon dont les développements doivent être conduits (exemple : pas de boucles imbriquées, pas de requête en « SELECT * » sur une base de données, cartouche normé …). Ces normes s’imposent au prestataire, que ce soit dans le cadre d’une prestation au forfait ou en régie. Ceci n’a pas d’impact en RACI pour une double raison :

  • Ce sont des exigences du client qui doivent être prises comme faisant partie de la spécification du besoin. Elles sont donc traitées comme le sont les spécifications.
  • l’Homme de l’Art dans le cadre de son devoir général de conseil et d’alerte à l’égard de son client doit proposer la solution la plus pertinente au meilleur coût. Si le respect de ces normes entraine une dégradation de la qualité du livrable final, ou si, par l’application de normes différentes ou plus récentes, le produit final est meilleur, il conviendra de le mentionner clairement dans les spécifications afin que le client puisse opter ou non pour le respect de la norme.

Voilà, cette série d’articles est désormais terminée. Il y aurait encore mille choses à dire mais vous voici désormais mieux armé.

Mieux nous connaitre …. Effixens.fr.

Les commentaires sont fermés.