Le client
La formation a démarré. Les stagiaires se réunissent en équipe et échangent sur les projets auxquels ils contribuent. Ils en sélectionnent un. Les voilà qui s’approchent des paperboards à leur disposition pour cadrer le projet. La 1ère question à laquelle ils doivent répondre porte sur la gouvernance du projet. Il s’agit de définir qui est le Chef de projet. Aussitôt, un prénom fuse. L’équipe passe au Client et, soudain, tout s’arrête. Le porteur du projet sélectionné se tourne vers moi et m’interpelle : « je ne sais pas qui est le client du projet ! ».
Les utilisateurs
Il n’y a pas de confusion dans leur esprit sur la nature de ce Client. Nous avons évoqué préalablement la différence entre client et utilisateurs.
Evoquons toutefois dans un 1er temps les utilisateurs !
Les véritables Clients du projet
Les utilisateurs sont les véritables clients du projet – ou plutôt du produit. Rappelons que le produit correspond à l’objet du projet, qu’il soit matériel, immatériel ou financier. Nombre d’entreprises évoquent le métier. Si nous voulons échapper à la dénomination anglaise « users« , nous pouvons nous raccrocher à celle de « customers » du PMBok de PMI. Le « customer » est le commanditaire du produit, le bénéficiaire de ce livrable. Dans Prince2, il s’incarne dans le « senior user« .
Cette partie prenante représente les utilisateurs et en garantit les intérêts.
Une nécessaire représentation des utilisateurs ?
Si le projet nécessite une telle représentation des utilisateurs, nous pouvons imaginer qu’il ne s’agit pas d’un petit projet ni d’un simple produit. Ou alors peut-être que la diversité et/ou la multiplicité des utilisateurs nécessite un tel rôle ? Nous pourrions aussi évoquer la grande distance qui sépare les utilisateurs du projet imposant une telle représentation.
Cependant, bien des projets n’ont pas ces contraintes. Il n’y a donc pas lieu d’incarner ce rôle. Dès lors, les intérêts des utilisateurs sont directement garantis par… le Client du projet !
Le Client du projet
Nous pouvons donc en revenir dans ce 2nd temps au Client du projet.
Le Project Owner
Il est la personne physique qui est propriétaire du projet. J’aime bien son équivalent dans l’ICB d’IPMA : le « project owner« , soit le propriétaire du projet. Cela permet de remettre à sa place un Chef de projet qui n’est chef de rien du tout puisque le projet ne lui appartient pas. Il en est dépossédé légitimement par l’organisation qui l’a plutôt confié à un « project owner ». Ses équivalents respectifs dans PMI et Prince2, « sponsor » et ‘ »Executive« , résonnent moins clairement à mon oreille. Je leur préfère encore la notion de « maître d’ouvrage » que nous retrouvons dans le code des marchés publics ou dans certaines directions fonctionnelles de l’organisation à l’instar des DSI qui l’affectionnent.
« Un Client, ce n’est pas très moderne ! »
Assertion formulée lors de la présentation de ce qu’est la gouvernance d’un projet ! Sans rire !
Pourtant, les 3 grands référentiels stipulent l’existence de ce rôle !
Par ailleurs, puisqu’il est « moderne » de ne pas avoir de Client, tirons en les conséquences !
Le Chef de projet reçoit de son organisation (Dieu sait qui !) la délégation de concevoir, de réaliser et de livrer le produit. Evidemment, il est également garant des intérêts des utilisateurs puisqu’il n’y a pas de Client qui puisse porter cette responsabilité.
Prenons une image ! J’aime bien le café. Cela tombe bien : quelqu’un quelque part me demande de faire le café pour, mettons, des visiteurs. Je réfléchis bien à la demande, pose quelques questions à leur arrivée. Je prépare le café et aussitôt dit, aussitôt fait ! Le voilà d’ailleurs déjà servi dans de magnifiques mugs au logotype de mon organisation ! Bien sûr, ils sont tous contents car mon café est toujours excellent. Même quand il imbuvable. En toute mauvaise foi…
Même si je ne remets jamais en question l’intégrité des Chefs de projet, je doute toujours de la mienne. Et je me pose la question de savoir à partir de quand un conflit d’intérêt fait vaciller cette intégrité.
Il me faut donc un tiers capable de défendre les intérêts de mes utilisateurs, en toute indépendance. Ce tiers, c’est mon Client.
L’idée qu’un Client, ce n’est pas très « moderne », est une imposture qui cache une démission managériale ou alors une ignorance de ce qu’est la gouvernance dans le mode projet classique. Peut-être les deux… ? C’est d’ailleurs toujours étonnant de voir que l’argument ne vaut plus pour les thuriféraires de la modernité lorsqu’il s’agit de confier le projet à un prestataire. Soudain, le Client ressuscite sous l’emprise du contrat passé entre l’organisation et son prestataire.
Mais où trouver le client ?
Car il faut bien répondre à cette question première de ce stagiaire qui cherche à donner un nom à son Client.
Plusieurs questions me viennent à l’esprit :
- Qui a confié ce projet au Chef de projet ?
- Auprès de qui le Chef de projet escalade quand il rencontre un problème bloquant ou lorsqu’il a besoin d’un arbitrage ?
- S’il y a un Comité de Pilotage (COPIL), qui le préside ?
C’est en croisant ces questions que la réponse s’impose d’elle même !
Mon Client assure le niveau de pilotage stratégique de mon projet tandis qu’il m’en délègue le pilotage opérationnelle, sa gestion et son management.
Le RACI à la rescousse !
Nous pourrions invoquer le dieu Râ du RACI. Cet outil anglo-saxon définit qui fait quoi dans un projet. Je le détourne volontiers de son acception originelle pour des facilités de traduction et de compréhension afin d’expliquer la gouvernance du projet.
Je traduis le « Responsible » par « celui qui Réalise » pour appeler le Chef de projet. Il est d’usage de dire qu’il réalise le projet bien qu’il s’agisse d’un abus de langage. Le Chef de projet ne peut pas réaliser un projet, mais il est en charge de réaliser le produit. A vrai dire, il ne le réalise même pas puisqu’il est là pour gérer et manager le projet. C’est la raison pour laquelle j’évoque plutôt « celui qui Réalise ou qui Pilote« , ce qui est en cohérence avec le rôle de « pilote » de lot.
Pour la lettre A qui oblitère « Accountable« , je le transcris par « celui qui Approuve« . Nous retrouvons ici le Client du projet qui reçoit délégation de son organisation pour contrôler, réguler et valider ce qui est « réalisé » et livré par le Chef de projet.
Je sais qu’originellement, le Responsible évoque en réalité celui qui approuve et l’Accountable, celui qui réalise. Je prête toujours attention au sens donné par l’organisation projet qui utilise cet outil et m’adapte en conséquence. Toutefois, nombre d’entreprises en France utilisent le RACI selon l’acception que j’en donne. Absolvo me !
Ce qui distingue enfin la gouvernance en mode projet classique de celle des activités courantes dans l’organisation, c’est cette distinction exclusive entre la personne qui réalise et celle qui approuve. A contrario, dans un processus par exemple, un expert peut heureusement à la fois réaliser et valider ce qu’il fait. Dans un projet, cela n’est tout simplement pas possible, du moins pour des livrables attendus par le Client.
Client et Chef de projet, le binôme infernal du projet
Vous êtes Chef de projet. Votre projet nécessite un Client.
Il est également judicieux d’identifier le partage de responsabilités entre le niveau de pilotage stratégique du projet qui est sous la responsabilité de votre Client et votre niveau de pilotage opérationnel. Quelles sont les missions de chacune des parties ?
Il est vertueux d’adopter la 3ème valeur du Manifeste Agile : la collaboration avec les Clients plus que la négociation contractuelle. A noter que le terme Clients est au pluriel. J’y retrouve et mes utilisateurs et mon Client Project Owner bien sûr !
Laisser un commentaire