La collecte efficace des besoins client
Rédacteur : Vincent Drecq
I. Introduction
L'ensemble des participants à la table ronde s'accorde à dire que le
processus de collecte des besoins/exigences est un processus fondamental pour le management de projet.
Cela consiste à :
1. Comprendre ce que le client souhaite et qui va utiliser le livrable du projet 2. Analyser les besoins et identifier ce qui est le plus important pour fixer des priorités pour atteindre l'objectif poursuivi
3. Vérifier la faisabilité 4. Négocier les solutions 5. Spécifier les ambiguïtés 6. Gérer les changements
Cependant, il ressort que les organisations ressentent des lacunes à outiller et industrialiser ce processus.
Vous trouverez dans les lignes qui suivent des éléments vous permettant d'identifier les problèmes majeurs rencontrés dans la collecte des
exigences, mais aussi des solutions pour vous permettre de mieux réussir vos projets.
II. Qui se charge en général de collecter les besoins client?
Les positions divergent selon les entreprises mais surtout selon les types de projets : industriels, informatiques, ...
Dans tous les cas de figure, le chef de projet est le garant de faire respecter et suivre les besoins métier.
Dans certains cas, la collecte des besoins est confiée à des chargés d'affaires qui répondent au cahier des charges durant la phase amont du projet : l'appel d'offres. Ensuite quand l'offre est soumise et l'affaire gagnée, le chargé d'affaire passe le relais au chef de projet. Charge à lui ensuite de travailler avec le client pour définir les besoins dans les
moindres détails.
Dans d'autres cas, essentiellement des projets en génie civile et en
informatique, c'est la maîtrise d'ouvrage (qui représente le métier) qui se charge de constituer le besoin client.
Dans des projets d'innovation traitant de gros volumes de données, ce seront le chef de projet accompagné du data scientist qui auront la charge de la définition des besoins. En tout cas, sur ce type de projet, il est
difficile de trouver celui ou celle qui possède le vrai besoin.
Le juridique est aussi une source pour les besoins dans le cadre de projets fortement réglementés.
III. A quel moment, la collecte des données intervient?
La collecte des besoins est un processus itératif qui débute parfois bien avant le démarrage officiel du projet :
1. Les documents issus des phases d'émergence sont sources d'informations 2. La phase de réponse à l'appel d'offre est aussi un moment pour collecter les besoins
3. Une phase de diagnostic permet aussi de définir les besoins macro, puis le CDP va collecter les besoins dans le détail au démarrage du projet.
En tout cas, au démarrage du projet, il est nécessaire de se mettre d'accord sur ce qui va être réalisé et sur les besoins à couvrir. Cela peut poser des problèmes notamment pour des projets d'innovation où le besoin est vaguement défini. Il est nécessaire parfois de rencontrer un maximum de personnes pour se forger une idée du besoin à couvrir.
Sur des projets "interne", lors de la demande du métier, le CDP clarifie le besoin avec le métier pour permettre de cadrer le projet (le but est de pouvoir estimer le projet et le planifier pour le présenter à une instance de décision GO/NOGO du projet).
Enfin, tout au long du cycle de vie du projet, il est nécessaire d'avoir défini une organisation pour collecter les nouveaux besoins ou simplement gérer les demandes de changements.
IV. Comment collecte-t-on les besoins client?
Il semble que ce processus, bien qu'étant considéré comme primordial, ne soit pas nécessaire bien formalisé et homogénéisé en termes de pratiques au sein des entreprises. Cela dépend du chef de projet et de son vécu, son expérience.
Une analyse des documents permet de recueillir un bon nombre
d'exigences : il s'agira de fouiller dans le cahier des charges, dans l'offre, dans l'étude d'opportunité (si elle existe), ...
Il est préférable de réaliser des prototypes, des maquettes ou POC (Proof Of Concept) pour permettre au métier de se faire une conviction sur ce qu'il faudrait faire et clarifier le besoin final. Cela limite les dépenses inutiles même si cela fait prendre un peu plus de temps.
Dans l'innovation, le besoin est difficilement explicité. Il faut alors rencontrer de nombreuses personnes.
La personne qui collecte le besoin se doit de reformuler avec ses propres mots ce qui a été dit par le métier.
Souvent des spécifications sont écrites pour mettre à plat le besoin exprimé.
On utilisera aussi dans les projets informatiques des outils comme les cas d'usage, les personae, ...
Pour fixer des priorités, on utilisera la technique de MoSCoW, ou la matrice effort de réalisation/bénéfices.
Sinon, l'utilisation d'une matrice de traçabilité permet de collecter et suivre les évolutions des exigences et des besoins.
Il est à noter qu'il faut privilégier les interactions avec le client pour bien comprendre son besoin. L'utilisation de schémas est fortement préconisée pour faire émerger le besoin et limiter les risques dans la réalisation à venir. Donc, mener des ateliers pour collecter le besoin client est une bonne pratique. Mais il faut surtout préparer les ateliers pour éviter d'avoir des loupés : manque d'un document, absence de la bonne personne à l'atelier.
Parfois, il peut être utile de s'associer à un cabinet externe qui va vulgariser le besoin dans le but de se faire comprendre par les professionnels en charge de la réalisation.
Fixer des priorités et lotir les réalisations pour faciliter la prise de décisions.
Mettre en place une trame de questions types à poser au client.
Avoir un Retour d'expérience d'experts.
Mettre en place un contrôle pour s'assurer que rien n'est oublié au niveau de la couverture du besoin.
V. Quels sont les problèmes majeurs rencontrés dans l’activité ?
La lecture d'un besoin rédigé dans un document, peut quand même mener à différentes interprétations, donc méfiance. La rencontre avec le client pour s'assurer de la bonne compréhension est essentielle.
Le métier ne sait parfois plus comment on fait et on doit faire de la rétro spécification sur ce qui existe pour comprendre!!
Difficulté à fixer des priorités sur les besoins : pourtant cela est à réaliser dès le départ.
Parfois on constate un manque d'engagement des parties prenantes.
Les aspects réglementaires sont importants mais pas toujours bien décrits et connus du client.
Les besoins peuvent arriver tardivement, c'est une catastrophe pour le projet (respect budget et délais!).
Les besoins peuvent changer durant le projet et il est parfois difficile de prendre en compte ces changements.
La réglementation peut changer en cours de route du projet, une activité de veille est à planifier durant le projet pour prise en compte de ces aspects qui peuvent être un risque mais aussi une opportunité!
Le besoin n'est pas harmonisé correctement entre les parties prenantes, il y a des contradictions.
Le client ne sait pas toujours ce qu'il veut, il faut alors l'aider dans la définition de son besoin.
La collecte n'est pas homogène en fonction des CDP, on a seulement exigé de collecter les spécifications mais pas encore la façon de collecter et
suivre ces besoins.
Il est parfois difficile de cibler la personne qui possède la connaissance exacte du besoin à réaliser, qui permettra d'obtenir les exigences à mettre en œuvre.
Le contexte client est très important à maîtriser pour bien comprendre le besoin et notamment identifier les exigences implicites (qui ne sont jamais écrites par le client car tellement évidentes pour lui!).
Une analyse d'impact est nécessaire pour prendre en compte les
demandes de changements. Une gestion de configuration est à mettre en place sur le projet mais cela n'est pas toujours réalisé de manière formelle.
Rester vigilant tout au long du processus de collecte des besoins en se méfiant des choses évidentes (qui parfois cachent des besoins plus complexes qu'il n'y paraît).
VI. Quelles sont les recommandations clefs?
Voici, les recommandations que le groupe propose :
1. Fixer des priorités sur les besoins : pour garantir le respect du budget et le timing du projet,
2. Mettre en place des prototypes/maquettes/POC pour clarifier le besoin le plus tôt possible et faire valider le besoin par le client,
3. Rencontrer le client avant de répondre à l'appel d'offre pour s'assurer que le besoin écrit dans le cahier des charges est réellement le besoin du client,
4. Il est primordial de définir le périmètre des besoins :
Prendre en compte plus que les besoins du client
Pour réaliser telle ou telle chose, il est nécessaire d'avoir des requis qui ne sont pas nécessairement dictées par le client (la réglementation par exemple)
5. Réaliser des schémas et prototypes avec le métier,
6. Reformuler point par point le besoin qui a été collecté en exprimant autrement ce que le client a dit ainsi on peut ouvrir le débat.
