Catégorie: Méthodologie & pratiques


On entend souvent dire que le client a toujours raison.  Or, tout le monde sait que le client n’a pas toujours raison (on a tous déjà été de très mauvais clients un jour); le problème, c’est souvent de lui faire comprendre.

En tant que bon consultant en systèmes d’information web, mon rôle est de les convaincre que la solution proposée est la meilleure (après tout, le client fait affaire avec nous pour notre expertise).  Par contre, ce n’est pas toujours aussi simple que ça en a l’air, en partie parce qu’en tant que consultant, on n’a pas la connaissance parfaite de tous les aspects de l’environnement du client.

Donc, comment convaincre notre client qu’il a tort et qu’on a raison?  Sam Barnes de SmashingMagazine.com donne d’excellentes pistes à ce sujet, que je résume ici:

  • Proposer des alternatives | Dans le cas où le client tient mordicus à une idée peu optimale et n’aime pas notre proposition initiale, lui proposer des alternatives qui tiennent compte de son idée, tout en l’enrichissant de notre expertise.  De part sa connaissance de son environnement, le client peut avoir des idées pas si bêtes que ça.
  • Mettre en évidence les bénéfices d’affaires | Pour appuyer vos propositions, toujours les appuyer par des bénéfices d’affaires tangibles.  Dire « cette idée est la meilleure » par rapport à « cette idée est la meilleure car elle permettra de réduire de 25% les erreurs » dégage une image totalement différente du consultant par rapport au client.  À long terme, votre crédibilité face au client n’en sera qu’améliorée.
  • Rester professionnel | Toujours dans l’objectif d’augmenter sa crédibilité.
  • Citer des clients connus | Encore une fois avec l’objectif d’augmenter sa crédibilité.
  • Appuyer ses idées de points de vue extérieurs | Études variées, blogues, citations d’experts sont tous des moyens qui peuvent venir appuyer vos idées, dans les cas où votre crédibilité ne serait pas déjà établie.
  • Admettre la défaite et la transformer en opportunité | Malgré l’utilisation de tous les trucs précédents, il se peut que votre client tienne à son idée et que vous n’arriviez pas à le faire changer d’idée.  Dans un tel cas, essayez de voir comment vous pouvez transformer la situation en une opportunité gagnante pour vous et votre client (Barnes donne un très bon exemple dans son article).

L’important dans de telles situations est d’établir un vrai dialogue, afin d’identifier la meilleure solution pour tout le monde.

Comme mes collègues le savent déjà, je crois fermement que les deux rôles, essentiels sur tout projet de par leur complémentarité, doivent demeurer des rôles distincts.  Rien n’empêche une personne de faire les deux sur des projets différents, mais sur un même projet, les priorités de chaque rôle rendent difficile l’atteinte des objectifs visés par l’analyste et le chargé de projet.

J’étais donc bien heureux de tomber sur cet article du Business Analyst Times qui résume bien le fond de ma pensée!  Voici quelques citations, mais je vous invite à le lire en entier.

The project objectives help the organization meet its business goals and objectives. The PM focuses on the former; the BA on the latter.

The PM typically focuses on the project-creating baselines and managing project constraints, communications about the project, resolving issues about the project, getting the resources working on activities and tasks. The BA typically focuses on the end product.

Project managers want to deliver the end product on time and within budget. Business analysts want to ensure that customers can actually use the end product once it has been implemented

When we wear multiple hats, which voice do we listen to?

Comme tout bon analyste doit bien comprendre le contexte dans lequel il travaille, en introduire un sur un projet est un défi en soi, encore plus si ce projet est déjà en cours.  Pour avoir eu à le faire à 3 reprises sur un projet majeur que je viens de compléter, je peux vous dire qu’il s’agit d’un travail de longue haleine, qui est néanmoins bénéfique.  L’un d’entre eux a d’ailleurs bien illustré la transition avec le principe du 30-30-30 (comme l’engrais :-) ):

  • 30 jours pour apprendre
  • 30 jours pour comprendre
  • 30 jours pour assimiler

Ce qui n’est pas très loin de la réalité!

Pour assurer une belle intégration, j’aime bien les grands principes identifiés par Laura Brandau sur son blog (très intéressant en passant), qui permettent de bien structurer toute la connaissance à transférer d’une personne à l’autre.  Ça ressemble pas mal aux points que j’avais abordé dans le passé sur mon projet, mais l’avantage, c’est que c’est structuré :

  • Connaissances – domaines d’affaires et applicatifs
  • Parties prenantes – affaires et TI
  • Partage d’information sur les problématiques courantes
  • Rôle et responsabilités de l’analyste sur le projet (devoirs & attentes)
EricProvost.net est hébergé par Servage sur Wordpress | Thème: Motion by 85ideas.