www.ITNetwork.fr

Le Blog > Gestion de projets - Avant vente

— Nicolas Lier

Cet article est le premier d’une sĂ©rie de deux articles Ă  propos de notre approche de la gestion de projet. Le lien vers l’article suivant se trouvera ici lorsqu’il sera publiĂ©.

Gestion de projets 1 sur 2 - Avant-vente

Il existe de nombreuses mĂ©thodes de gestion de projets et il convient d’adapter la mĂ©thode selon le projet et son contexte.

NĂ©anmoins, pour les projets de tailles moyennes et dont le pĂ©rimĂštre est relativement bien dĂ©fini, nous fonctionnons gĂ©nĂ©ralement selon le schĂ©ma que nous allons vous prĂ©senter. Il a l’avantage de rassurer le client au niveau des coĂ»ts et des dĂ©lais, donc de rester dans un cadre tout en laissant la place aux ajustements qui apparaĂźtront nĂ©cessairement au cours du dĂ©veloppement.

Notre mĂ©thode est pragmatique mais intĂšgre de maniĂšre forte la composante humaine et la souplesse qui en dĂ©coule. Nous intervenons trĂšs en amont, au niveau de l’avant-vente et de la rĂ©daction de la proposition commerciale.

Il est extrĂȘmement rare de recevoir une expression de besoins suffisamment prĂ©cise pour pouvoir s’engager de suite sur une proposition commerciale. Le client exprime son besoin autour de fonctionnalitĂ©s, plus ou moins dĂ©taillĂ©es. Il s’agit mĂȘme parfois d’intentions dans lesquels les aspects fonctionnels ne sont pas clairement dĂ©finis.

Notre rĂŽle est de transformer cette expression de besoins en un mini cahier des charges fonctionnel dans lequel tout le dĂ©roulement de l’application et les aspects techniques structurels seront prĂ©cisĂ©s. Nous formalisons notre comprĂ©hension du besoin en apportant notre expĂ©rience mĂ©tier, le prĂ©sentons au client et le modifions avec lui pour arriver au document dĂ©finitif. C’est sur la base de ce document que le devis pourra ĂȘtre rĂ©alisĂ©.

Le diable se cache dans les dĂ©tails ! Et c’est dĂ©jĂ  Ă  ce niveau que le chef de projet doit systĂ©matiquement creuser lĂ  oĂč il y a des zones qui lui semblent floues. Il est tentant de se dire qu’à ce stade on peut faire l’impasse sur ces “points de dĂ©tail”, et qu’on verra lors du dĂ©veloppement comment rĂ©gler la chose. Mais c’est alors l’assurance que des problĂšmes plus ou moins importants vont apparaĂźtre au cours du dĂ©veloppement amenant son flot de difficultĂ©s avec effet boule de neige. Dans des cas plus grave, cela peut entraĂźner une remise en cause partielle ou totale de la structure ou du fonctionnement de l’application.

DĂšs qu’il y a questionnement, cela doit tout de suite alerter, et cela doit ĂȘtre clarifiĂ©. Ces questionnements peuvent concerner des aspects purement techniques de faisabilitĂ©. Une solution doit alors ĂȘtre trouvĂ©e et validĂ©e avec l’équipe technique. Il peut s’agir Ă©galement de questionnements fonctionnels, il ne faut alors pas hĂ©siter Ă  revenir vers le client tant que le point n’a pas Ă©tĂ© totalement clarifiĂ©. Être laxiste Ă  ce niveau ne peut que gĂ©nĂ©rer Ă  terme de la frustration chez le client et les Ă©quipes en interne.

Alors oui, on peut avoir l’impression de perdre du temps car le dossier n’est pas encore signĂ©, on a l’impression d’embĂȘter le client. Mais c’est tout le contraire qui se produit au final. Le temps passĂ© Ă  faire ce travail, et c’est rarement trĂšs long, est infiniment moindre que les impacts que peuvent causer une nĂ©gligence ! Et le client voit dans cette dĂ©marche un gage de sĂ©rieux qui le rassure sur notre dĂ©sir de comprendre son besoin et de le formaliser.

Une fois le pĂ©rimĂštre dĂ©fini et les questions Ă©lucidĂ©es, nous formalisons par Ă©crit prĂ©cisĂ©ment ce que nous proposons de rĂ©aliser. C’est sur cette base que nous pouvons nous engager et rĂ©aliser un chiffrage. Le chef de projet Ă©value l’ensemble des fonctionnalitĂ©s en concertation avec l’équipe technique. Il est fondamental d’intĂ©grer les dĂ©veloppeurs/intĂ©grateurs dans cette phase de chiffrage afin de les responsabiliser et qu’ils commencent Ă  s’approprier le projet. Par ailleurs, cela permet de s’assurer qu’il n’y a pas une difficultĂ© technique que le chef de projet n’aurait pas anticipĂ©.

La description du projet et le chiffrage doivent toujours ĂȘtre revus par un collaborateur qui n’a pas participĂ© Ă  leur Ă©laboration. S’il comprend ce qui est Ă©crit sans poser de question, c’est gagnĂ©, et la proposition commerciale peut ĂȘtre envoyĂ©e au client.

Nous parlerons par la suite uniquement du cas oĂč le client a rĂ©pondu favorablement Ă  notre proposition, l’autre cas de figure prĂ©sentant moins d’intĂ©rĂȘt