Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

Relation client

  • Le match le plus long

    Chamster-tennis.jpge 23 juin 2010, a eut lieu un match de tennis à Wimbldeon incroyable ! Plus de 10 heures sur le terrain, des joueurs à bout, un record d'échanges, un record d'ace,...

    Mais analysons les résultats. Jusqu'au quatrième set tout est normal, mais au cinquième set, la boucle infinie ! Le train qui s'emballe ! C'est comme un satelite. Tu mets la gomme au demarrage, et arrivé en orbite à sa vitesse de croisière le "machin" tourne tout seul. Les mecs sont montés jusqu'à 59 à 59 en fin de deuxième jour. Cela a posé un gros problème inattendu. Figurez vous que le programme des panneaux d'affichage n'était pas prévu pour plus de 50 jeux ! Le bug ! Heureusement l'arbitre à siffler la fin de la deuxième journée car le français arrivait plus à voir la balle.
    Enfin au troisième jour, les mollets en guimove le français a craqué.

    Pourquoi racontais-je tout ça ?

    Ah oui, refaisons le match. J'atterri juste d'un projet "béton"... armé jusqu'aux dents. Au début tout se passait bien, on avait l'impression de faire une promenade de santé ! Les maquettes sont lancés en conception et s'en suit quelques échanges de balles. Au bout du 8eme jeu le client remporte le premier set. Loyal et fair play on raccroche le téléphone pour la suite du match.

    Le 2ème jeu début bizarrement par un ace, une demande d'astreinte pendant 10 jours de 7h à 23h week end inclus. "vous comprenez on veut se donner la possibilité de faire des modifications de dernière minute !". C'est louche parcequ'en l'astreinte c'est pour gérer les impondérables ! On borde une propal bien cadrée et là on gagne le set, serré.

    Le bras de fer continu lors du développement : une affaire de cryptage à caractère exotique qui passent pas sous BlackBerry et ie6. Le set est pour le client. Lassant !

    L'intégration commence. Tout va bien. On cale tous les pixels à leur place, sauf un.

    Les heures se sont accumulées, la fatigue aussi. "Qu'on abrège la recette !" On se serait cru devant l'échafaud de Louis XVI le 21 janvier 1793 ! Installation du VPN du client pour simuler être chez lui. Développement en parallèle, intégration, modification, remodification, reremodification, rereremodification, rererereremodification, ... Au bout de centaines d'échanges interminables, un mois de recette, un lundi à 23h50, ouverture officielle. Ouf c'est la délivrance.

    Au final, ni gagnants ni vainqueurs ... Même si on peut compter les points il y a bien un vainqueur pour le match mais combien même on sorte victorieux de ce dernier, quand est-il du tournoi ? Ah oui ! L'américain Isner a gagné, mais le match d'après est forcément perdu. De même les retards de livraison sur ce projet entraine des retards sur les projets suivants. L'équation est cornélienne !

  • Les relations clients et la loi du Talion

    mayonnaise.jpgJe me trouvais il y a quelques années a déjeuné fortuitement avec un décisionnaire d'un groupe industriel de fabriquant de composant électrique et un responsable chez Cap Gemini juste après la signature du contrat d'externalisation de la gestion tout son parc informatique de ce premier. Chacun se gaussait que sa société avait rondement mené les négociations. Intelligemment, nous avons fini par conclure que c'était un bon contrat puisqu'il satisfaisait les deux parties.

    La transaction commerciale se solde toujours par un accord bipartite où l'une et l'autre sont d'accord avec les termes du contrat. En gros le client est sur d'avoir fait une bonne affaire et le prestataire ou fournisseur, lui, est sur d'avoir remporté un contrat juteux.

    Quand on passe a l'exécution du contrat, les choses changent. Le client va chercher à avoir le maximum, le prestataire va chercher à se couvrir par la rédaction d'un cahier des charges et spécifications techniques, ... Il n'est pas rare qu'un petit "rien" chez le client provoque une poussée de fièvre : d'un coup la planète entière est en copie, des tensions apparaissent et chacun tire la couverture vers soit.

    Quand on gère un projet, qui nous semble maîtrisé, c'est toujours frustrant de voir la savonnette vous glisser entre les mains. Il est très difficile de garder son calme face client accusateur quand on fait tout pour défendre son projet en interne et que le seul "remerciement" est un email bien acide pour dénoncer une situation qui n'est pas forcément de votre fait.

    Quels sont ces petits riens prétextes a toutes les empoignades ?

    • Le chef de projet du client manque d'autonomie et met systématiquement le chef en copie. A chaque fois qu'un bug surviendra, ce chef de projet relèvera le manquement pour justifier qu'il fait correctement auprès de sa hiérarchie et se dédoine du problème. Parfois ça frise la mauvaise fois car on ne vous a pas transmis tous les éléments !
    • Le manque de communication. Le client a besoin d'être rassuré et de voir les choses avancer. Sur des technologies qu'il ne maitrise pas il peut "flipper" pour "mettre un coup de pression" et s'assurer que les délais seront tenus. Il va mettre en avant des problème de délais, reprocher de ne pas être clair, ...
    • La peur du risque. Il n'est pas rare qu'avec les grosses entreprises, un "détail" juridique, le niveau de sécurité informatique, ou même la peur d'engager la réputation de sa société est un frein et prétexte à ralentir le projet par une escalade hiérarchique. Le manque de confiance dans le projet ou un boulversement des habitudes de travail peut induire des ostilités envers le projet.
    • Enfin des tensions internes chez le client ne sont pas à négliger. Difficile de déceler des conflits d'interêt interne, et les bâtons dans les roues déposés par un rival chez le client !

    Tous ces petits riens sont comme des boomrangs qui reviennent en pleine figure du chef de projet.

    Quelle est l'attitude à adopter ?
    Il est difficile de repérer quand la situation bascule et difficile de diagnostiquer la cause du réélle du problème. Le client nous fourni un symptôme, au chef de projet à connaître la cause réélle pour livrer le projet. La situation peut se dégrader très vite, il ne faut absolument pas froisser le client sous peine d'envenimer la situation. Il ne faut pas s'isoler et avoir recours à une discussion avec le commercial qui a conclus la vente et essayer de comprendre les raisons exactes de ce revirement de situation.

    A éviter : faire monter la mayonnaise en mettant soit même en copie toute sa planète avec ses suppérieurs sans s'être concerté. Donc pas de loi du Talion ! Il faut savoir reconnaître que certaines situation nous dépasse, le dialogue posé est toujours la meilleure solution.

  • L'histoire du con qui dit "non"

    Dominique84124605287775_gros.jpg

    - Vous connaissez l'histoire du con qui dit "non" ?

    - Non !

    Et voilà le piège s'est refermé.

    Attention : l'humour de cette introduction est là pour présenter le côté délicat de certaine situation de gestion de projet pour lequel il est nécessaire de flairer le chausse trappe... pour ne pas passer pour un con. Quant à l'illustration, j'aime beaucoup Geluck et son chat !

    En tand que fournisseur de service web, vous avez déjà travaillé comme prestataire d'une webagency elle-même missionnée par une agence de communication sous-traitante d'une agence de relation publique qui répond à l'appel d'offre du client final ?

    Ca aussi c'est un peu une histoire à la con, mais quand on gère un tel projet, il y a plusieurs dificultés :

    1. L'accès au besoin du client final est difficile. Au moins un des acteurs de la chaîne doit trancher pour le client car il a pas l'info, ou qu'elle n'est pas remontée jusqu'à lui. Bref la communication avec autant d'intervenants c'est pas simple.
    2. Le client remonte des infos, mais il a l'impression de ne pas être entendu. Le prestataire final ne reçoit aucun signal, il a l'impression d'avoir des fourmies dans les jambes, juqu'à ce que le client se mette à râler à force de ne pas se faire entendre.
    3. Il est difficile de voir le périmètre de la webagency et celui du prestataire, fournisseur de service. En général, le fournisseur de service réalise peu de travaux spécifiques mais est tributaire de la réalisation de la webagency qui elle s'occupe du projet spécifique. Si la webagency ou le fournisseur de service se "plante", le client ne sera pas content.
    4. C'est un projet qui prendra plus de temps qu'un projet où le client est en contact direct. La récolte des "entrées" nécessaires au démarage du projet doit passer et être validée par toutes les mains. Les conf call avec la webagency qui ne maîtrise pas le produit que vous commercialisez gaspillera du temps à l'équipe technique qui devra assurer le débug de l'application de la webagncy.
    5. Si un maillon de la chaine coule, c'est tout le monde qui plonge, chacun rejetant la faute sur l'autre.

    Pour maîtriser un tel projet :

    1. Essayer d'avoir accès à un contact chez le client final pour recueillir son sentiment tout au long de la mise en place du projet.
    2. Travailler avec une webagency avec qui on a déjà travaillé est un plus. On a pas toujours le choix, mais parfois il peut être orienté par "copinage", pourquoi s'en privé.
    3. Une attention partculière doit être fourni par le chef de projet qui doit analyser le moindre signal. Un chef de projet sénior n'est pas un luxe.
    4. Le prestataire de service maîtrisant son produit se doit d'apporter un conseil en intégration irréprochable auprès de la webagency. Mieux vaut se froisser avec l'équipe technique de votre partenaire, en la bousculant un peu, plutôt que gérer un client mécontent. Mais il faut être filou pour ne pas se faire taxer d'ingérence !
    5. Une documentation complète, des procédures claires et un formalisme rigoureux assureront vos arrières ! En pratique, valider les conf call par un compte rendu envoyé par mail ou la rédaction d'un rétroplanning avec les éléments attendus montrera que vous maîtrisez le projet et les délais, que vous êtes sérieux et irréprochable.

    Ne le regrettons pas, ce sont ces situations périlleuses qui font la joies de l'entreprise et du web !

  • Le know-how plus important que le produit

    savoir-faire.jpgAvoir un produit high-tech, avec plein de fonctionnalités pour satisfaire le besoin de l'utilisateur, c'est génial. Cependant, et spécialement avec les logiciels, il est rare qu'un soft soit utilisé à 100% de ses capacités. Prenez MS Word. Qui utilise plus de 20% de ses capacités ? Quasiment personne !

    Dans la plupart des cas, on s'aperçoit que le client ne connaît pas telles ou telles fonctionnalités ou possibilités offertes par le produit. Quand on travaille en B2B, il est concevable d'apporter ce savoir faire sous forme de service, mais certains clients n'ont pas forcement le temps de s'occuper de l'art et la manière d'utiliser leur produit.

    Disposer d'une base de connaissance solide, de documentations techniques orientées client, d'exemples d'utilisation est un plus incontournable. La liste des fonctionnalités ne suffit pas ! Et la diffusion de plus en plus large d'API (webservices) pour relier les applications nécessite d'ouvrir également sa documentation pour tirer le maximum de profit du produit.