Comment j’ai récupéré 5000 euros avec le mot « Super » dans un compte rendu de projet

Le compte rendu c’est l’arme suprême du chef de projet : il est plus fort que le planning, plus fort que le suivi des charges, plus fort que les spécifications, plus fort que la proposition commerciale. C’est un véritable filet de sécurité pour votre projet et un outil puissant de pilotage.

Le compte rendu est un bouclier pour protéger votre équipe, votre budget, votre planning, vos engagements contre les changements d’avis, les retours sur validation, les montées en pression, les désaccords de manière générale avec vos fournisseurs, vos clients, ..

C’est un peu comme une assurance, quand tout va bien, cela ne sert pas à grand chose, quand ça se gâte, on est bien content de l’avoir ! Pour peu que ça nous couvre comme il faut ..

Vous maîtrisez le compte rendu, vous maîtrisez le projet ou presque … C’est d’ailleurs LA question à poser en entretien de recrutement : quel est l’outil principal du chef de projet ? La réponse doit être .. le compte rendu !

Je vois certains sceptiques dans le fond, rien ne vaut donc un petit exemple pratique.

Un projet se passe toujours bien .. au début

Au début d’un projet, tout le monde est beau, tout le monde est gentil, on s’est embarqué sur un bateau vers une belle aventure et on regarde tous le soleil couchant à l’horizon en souriant confiant à l’avenir.

La phase d’avant-vente se passe bien, on remporte l’appel d’offres et le projet démarre tranquillement.

La phase de spécifications avance correctement, on travaille sur une maquette de charte graphique pour afficher un tableau de bord avec tout un tas d’indicateurs visuels. Quelques allers-retours ont lieu entre le client et le designer pour finalement arriver au résultat final.

J’organise donc une démonstration au client de la maquette finale pendant un comité de suivi :

Client : « Wow, c’est super bien ! »

Chef de projet : « C’est vrai ? je peux marquer ça dans le compte rendu ? :-) »

Client : « Oui oui, si tu veux ! »

Ni une, ni deux, c’est noté ! A titre d’exemple, le compte rendu contenait donc le paragraphe suivant :

a) Maquette
La mise à jour de la maquette (version 1.7) de la partie affichage a été montrée par [nous] à
[client] pour commentaires. Mises à part quelques modifications désormais mineures, [client]
valide cette version et trouve la maquette « super bien ».

A ce moment-là, nous sommes bien d’accord, s’arrêter à « valide cette version » aurait été suffisant mais j’avoue que ça m’amusait d’y inclure cette fin de phrase d’autant que ça ajoutait un certain poids à la validation. Sans savoir que ça allait ressortir plus tard … Le compte rendu est validé sous 48h par le client.

Le même projet, quelques mois plus tard …

Sans rentrer dans les détailscar il y aurait beaucoup à dire et à retenir – le projet suit son cours tant bien que mal avec une équipe de développement en near-shore. Arrive le moment de la recette.

Les tests sont fastidieux, les jeux de test compliqués à mettre en oeuvre, les règles de gestion doivent être constamment vérifiées par rapport aux spécifications. Les bugs sont difficiles à reproduire et pourtant présents, bref ça chahute un peu, ça n’avance pas vite, la motivation baisse et je me dis que le désespoir nous guette quand le client me laisse le simple message suivant sur le répondeur « Au secours, Jean-Philippe, au secours ».

Les éternels débats de recette commencent : anomalie ou évolution ? chacun a sa compréhension des spécifications, le cas n’est pas mentionné, les modifications sont plus ou moins couteuses … Les attentes client sont toujours élevées à juste titre, le budget commence à passer au orange, malgré une bonne entente et une bonne volonté de part et d’autre, les tensions montent.

Un certain nombre d’évolutions sont tout de même validées comme telles et sont mises en oeuvre. L’avenant au contrat associé sera envoyé à la fin de la recette pour éviter d’en refaire 15 et de multiplier la paperasse pour chaque évolution.

Fin de la recette, ouf ! l’application est stabilisée, la phase de garantie commence, il est donc temps de régulariser les évolutions validées sous forme d’avenant. Il y en a pour plusieurs milliers d’euros. Le document est envoyé au client.

Et là, coup de tonnerre, le responsable de l’interlocuteur client nous fait savoir par email, au directeur de projet et moi-même, qu’il n’est pas prêt à payer l’avenant notamment car ils ne sont pas satisfaits du résultat graphiquement.

Fin du projet : Surprise, surprise !

Le projet résumé en quelques paragraphes dans cet article montre bien l’incohérence de discours du client entre le début et la fin de projet. Mais pour remettre les choses dans leur contexte, presque trois mois se sont écoulés entre le compte rendu décrit ci-dessus et de nombreux rebondissements ont eu lieu pendant cette période sur différents sujets.

Et pourtant, ma toute première réaction a bien été : « QUOI ?! » :-)

J’appelle directement mon interlocuteur client pour voir de quoi il retourne avec son responsable mais n’en tire pas grand chose. Il faut donc répondre à cet email de manière argumentée dans l’objectif de récupérer cet avenant.

Je pense que vous voyez où je veux en venir ?

« Chefs de projets : sortez les comptes rendus ! »

Bien sûr, ma réponse ne s’est pas limitée à « Mais vous avez dit il y a 3 mois que c’était -super bien- ! »  et d’autres arguments ont été pris en compte. C’est typiquement le genre de réponse qui peut prendre quelques heures à rédiger proprement en se basant sur les comptes rendus de réunion du projet et une analyse de l’historique.

Néanmoins, mentionner ce passage précis de compte rendu a contribué à fortement appuyer le discours et nous avons fini par récupérer le montant de l’avenant tout en conservant une relation client saine.

En relisant cette réponse détaillée pour préparer cet article, j’y trouve encore des choses à améliorer, cela n’était pas parfait dans la forme et c’est pourtant très important.

L’objection du client peut paraître caricaturale dans cet exemple, car je l’ai mise en évidence et j’ai enlevé tout le contexte ou presque. Mais il a pu réagir de cette manière pour diverses raisons : changement d’avis, évolution du besoin, manque de budget, oubli de prévenir son responsable qu’il faudrait une rallonge, tensions de la phase de recette, …

La pression et les tensions font parfois faire réagir les personnes de manière inattendue. Il faut donc s’en prémunir de manière factuelle et le compte rendu est pour cela, s’il est bien utilisé, un outil redoutable.

Et vous ? avez-vous des exemples où le compte rendu vous a sorti de situations difficiles ?

Mots-clés recherchés :

  • 300 bouclier
  • shield 300
  • recette expressions superchef
  • j\ai besoins de 5000€
  • j ai pesoin de 5000
  • idee projet de 5000 euro
  • dashboard EAI
Cet article a été posté dans Gestion de projet.

13 réponses à Comment j’ai récupéré 5000 euros avec le mot « Super » dans un compte rendu de projet

  1. Belle démonstration !

    Je note l’idée de reprendre mot pour mot l’expression du client, ça donne beaucoup plus de force à l’argument quand il est réutilisé plus tard.

    Merci, voilà un article fort pertinent.

    Je comptais justement relancer un ancien client qui dit partout autour de lui qu’il a été content de ma prestation (réalisée depuis 6 mois) pour qu’il me fasse un retour écrit.

    Cet article me motive encore plus à écrire ce mail rapidement. :-)

  2. Effectivement, de l’art de l’écrit qui reste:

    Idem pour ma propre expériencce; 61 000 Euros gagnés ou pas perdus sur une simple signature!

    Cela se passe en l’an 2001: je suis jeune chef de projets et prends en charge un projet au forfait récupéré suite au rachat d’une société pour de la croissance externe d emon ancienne société.

    De suite je constate que le projet est considérablement avancé sans aucune spécification écrite et signée par le client.

    Ni une ni deux je m’affole et cherche à savoir le pourquoi du comment. On m’explique dans la société rachetée qu’il y a un climat de confiance en tre le client et cette dite société.

    Je viste le client et constate que ce n’est pas le cas du tout.

    Le projet est vendu à l’époque à 1 200 000 Francs!

    Je m’atelle immédiatement à la rédaction d’un cahier de spécifications (qui n’est pas un CRR mais sur le principe c’est la même chose!).

    Je mets un mois à faire signer le client qui se demande pourquoi il faut un cahier de spécifications alors que ce qu’il demandé oralement lui paraît totalement clair.

    Je lui explique en long et en large que ce qu’il ademandé oralement fait l’objet d’un contrat qui doit se reporter à des spécifications validées. Il acquiesce que moyennement et signe sans lire le CDS en me disant qu’il me fait confiance. Je lui dis qu’il ne devrait pas car je ne sais pas si ce qu’il ya écrit est vraiment ce qu’il demande. Il a atre chose à faire et n’a pas l’habitude de gérer de tels projets.

    On s’en tient là.

    Le jour de la livraison de la recette, la démo du produit fini ne dure pas 15 minutes sur deux heures prévues. Le client est abasourdi en disant que ce qui est présenté (pourtant de qualité) n’est pas du tout ce qu’iol veut.

    On part du coup sur un conflit qui dépasse l’opérationnel et remonte aux deux directions.

    Ma société à l’époque comptait 1200 personnes.
    Le client gérait lui des Personnes VIPs à grosse fortune.

    Mon dirceteur, un jour m’appelle personnellemnt et me demande le cahier des charges signé.

    chose faite dans la seconde qui suivait.

    1 mois plus tard ma société obtenait gain de causes après confrontations des parties vie Avocats Internationaux interposés.

    Le document pesant dans la balance était ce fameux CDS SIGNE!

    La négociation a abouti à un achat du projet par le client en l’état pour une valeur de 800 000 francs soit le coût approximatif du projet pour ma société. Une valeur de 122 137 euros!

    Voilà non seulement l’écrit à son importance, y compris pour des choses simples, mais en plus un écrit SIGNE!

    Ne l’oubliez pas et pensez que derrière tout cela des avocats guettent…..

    PS: cela va sans dire que le client ne s’est absolument pas intéressé au déroulement du projet malgré mes multiples invitations au comité de pilotage.

    L’effet tunnel à jouer plein pot!

    • JP dit:

      Merci Christophe pour ce retour ! on oublie souvent que les documents projets sont contractuels et qu’en cas de crise majeure (genre un procès), ils peuvent devenir des éléments de la plus haute importance. Chaque validation ou signature est donc à mesurer ..

  3. Sig dit:

    ;) je suis d’accord & la démonstration est … très bien – A refaire, donc !!

  4. Arnaud dit:

    Pareil ici !
    On se demande à quelle école j’ai été pour raisonner rigoureusement de la même façon ;-)

    Dans mon cas, c’est un peu différent cependant : nous traitons principalement de projets R&D il n’est donc pas toujours très simple de dépasser les spécifications fonctionnelles. Il y a aussi un autre facteur qui entre en jeux : les sujets sur lesquels nous intervenons étant tellement pointus que souvent plusieurs acteurs se partage le travail (typiquement nous pour la partie Linux embarqué/Android et un acteur moins expert pour le backend).
    Dans ce cas, il arrive fréquemment des choses désagréables notamment si le chef de projet client ne parvient pas à tenir les 2 bouts du projet. Dans notre cas, les formats d’échanges des données ont changés unilatéralement à l’initiative de « ceux d’en face » sans prévenir le client ni nous… J’aime mon client (beaucoup car leurs projets sont fun) mais pas a point de réduire la marge ! Donc, rappel des spécs, CR de copil et hop : avenant pour les développements en sus de notre côté.

    J’ajouterais que contrairement aux idées reçues, un chef de projet « béni oui-oui » ne sera pas plus apprécié par le client qu’un chef de projet plus musclé. Les clients aiment que les projets restent dans les clous et ils vous serons fréquemment reconnaissant d’avoir participé au succès d’une aventure. Même si ce succès a été entaché de période de durcissement du ton.

    Super article (ex-)Chef ;-)

  5. Nadege Tchuindem dit:

    Superbe article ! Belle démonstration. Merci de nous faire partager vos expériences.
    Pour ma part, j ajouterai que le compte rendu est l outil indispensable du jeune chef de projet.
    il montre sa capacité de synthèse et permet d entériner les décisions prises par les différents acteurs du projet.

  6. Isabelle Belledant dit:

    Bonjour à tous!
    Je vais mettre un peu les pieds dans le plat de cette belle unanimité en jouant la mouche du coche… Le Client n’est-il pas Roi? ;-)

    Quand un client n’est pas content de ce que vous avez fait, vous lui faites avaler quand même, contrat ou compte-rendu à l’appui?
    Et vous gardez le client derrière ou vous faites une croix dessus?

    • JP dit:

      Bonjour Isabelle,

      merci pour votre commentaire, le client est roi … s’il a le budget qui va avec le train de vie ;-)

      Imaginons que vous choisissiez une couleur pour repeindre vos murs et que vous embauchiez un peintre pour effectuer le travail. Une fois que c’est fait, le rendu général sur vos murs ne vous plaît pas, est-ce que vous dites du coup au peintre que vous n’allez pas le payer car vous n’êtes pas satisfaite ?

  7. Gilles Brunel dit:

    Bonjour à tous,

    Merci pour cette belle démonstration.

    A mon sens il faut rapidement évacuer l’idée que nous sommes face à des clients de « mauvaise foi », même s’ils existent : nous sommes face à une « mécanique » récurrente et c’est contre cette mécanique que nous devons nous battre.

    Il faut savoir dire non :

    - Non au client qui ne s’implique pas dans son projet et qui nous demande de le porter tout seul, car provoquant immanquablement l’effet tunnel.
    - Non aux spécifications, même indolores, demandées en cours de route et non présentes dans le CDS.

    Pour savoir dire oui :

    - Oui aux évolutions futures lorsque cette mission sera terminée (écrit)
    - Oui je suis garant du succès et je vous sollicite tout le temps (écrit)
    - Oui cette spécification a été oubliée et nous l’implémentons immédiatement, avec nos excuses (écrit).

    Pensez aussi aux recettes intermédiaires, sous forme de questionnaire avec cases à cocher :

    - Création/modification/suppression d’un contact =
    * Satisfaisant
    * Non satisfaisant (raison détaillée obligatoire)

    Le « satisfaisant » aura une grande probabilité de devenir insatisfaisant lorsqu’on vous reprochera de ne pas avoir interdit la suppression des contacts de type « XDFGHT », acronyme inconnu de vous et du CDS jusqu’à présent !

    Gilles

  8. Clémence dit:

    Super :) bonne démonstration. Merci pour ce récit très intéressant

  9. Vraiment une très bonne analyse de ce document qui est pourtant souvent oublié ou sinon vite fait. C’est effectivement la base avec laquelle on est en mesure de discuter avec le client. L’idéal est que tout doit être écrit et catalogué. Il m’arrive fréquemment que les courriels d’un projet, je les classe par projet bien sur et en plus en sous catégorie (plante, félicitation, explication, changement demandé …) pour avoir encore plus rapidement certains passages écrits du client. Surtout les confirmations écrites ou des félicitations. Même en début de projet, il faut toujours se garder ça sous la main.

    Même les demandes de changement sont une bonne chose à se garder sous la manche. Quand un projet va mal, réussir à démontrer à un client qu’il change d’idée et qu’il se contredit est une bonne solution pour le ramener à la table de négociation.

    Un bon gestionnaire doit aussi être en mesure de discuter avec le client de façon le plus diplomate possible, même quand le client est sur les nerfs.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


× 4 = vingt

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>