Pendant des années, nos projets finissaient en négociation pénible. Aujourd’hui, nos clients nous remercient pour la transparence. C’est grâce à cet outil :
Avant, c’était toujours la même histoire :
Les modifications de scope étaient partout, à l’oral, dans les tickets… Le client n’avait pas de point de centralisation, pas de rapport direct à l’argent que représente chaque demande.
Il pouvait valider une modification à 4h dans un meeting, et contester à la fin car « ça ne s’était pas si bien passé ».
Résultat : relation tendue, négociation pénible, tout le monde était perdant.
Nous, frustrés de devoir justifier a posteriori un travail éparpillé. Eux, méfiants face à un total de « petits oui » qu’ils n’avaient jamais visualisés globalement.
Alors nous avons changé notre approche en mettant en place le Request for Changes. C’est un outil pour consigner chaque semaine les modifications :
– On fait quelque chose en plus → on facture
– On fait quelque chose à titre gracieux → on le note explicitement (« ça, c’est cadeau, ça représente X jours de dev »)
– On ne fait pas quelque chose du cahier des charges initial → on réoriente le budget sur un autre élément
En formalisant les choses, tout le monde y gagne :
Le client:
• Pas de surprise à la facturation finale
• Un pilotage budgétaire en temps réel
Nous:
• Le client a conscience du lien « demande = budget
• Plus de demandes fantômes : tout est centralisé
Ça fait maintenant 6-7 ans que nous fonctionnons comme ça et ça change tout. Cette transparence renforce la relation client.
Le problème n’était pas le budget mais l’incertitude et le manque de centralisation.
Le Request for Changes ne sert pas à facturer plus. Il sert à rendre la valeur visible.
Et vous, comment gérez-vous les ajustements de scope en cours de projet ?