haber

Ucuz Uçak Biletleri

Estimer et intégrer le coût du changement

Computer Science - Méthodes

Written by Vincent MARTIN

There are no translations available.

Le changement est une des grandes difficultés de la conduite de projet : en ne le prenant pas en compte, on prend le risque de livrer un produit qui ne répond pas au besoin du client ; dans le cas contraire, on prend le risque d’inciter le client à changer d’avis tous les quatre matins. Voici quelques pistes pour calculer et intégrer le coût du changement à la conduite de vos projets.

La prise en compte du changement est permise et favorisée par les cycles de développement itératifs et par les méthodes agiles, qui en font, à juste titre, un argument de vente face aux cycles de développement classiques que sont les cycles en cascade ou « en V ».

Cette situation engendre malheureusement pas mal de malentendus, au rang desquels le droit, pour le client, de changer d’avis fréquemment ou même de se contredire. Résultat : je rencontre des chefs de projets qui rejettent les développements itératifs au prétexte que ceux-ci sont la porte ouverte au « n’importe quoi » et constituent un risque majeur pour la réussite du projet.

Le mythe du client roi

La première attitude, face à un client qui n’hésite pas à se contredire, est la négociation. Le chef de projet, l’équipe projet ont le droit de faire remarquer au client que sa demande est mal venue, qu’elle est contraire à ce qui avait été convenu auparavant, ou qu’elle remet en cause beaucoup de choses.

Contrairement à un dicton (malheureusement) bien connu, non, le client n’a pas tous les droits. Et la liberté de demander des changements motivés par des évolutions réglementaires ou législatives, des évolutions métier ou l’émergence de solutions non encore envisagées ne permet pas de demander tout et son contraire.

La nature de l’engagement

Si la négociation échoue et que le client maintient sa demande de changement, cette demande doit être satisfaite. Pour que son coût puisse être pris en compte dans la conduite du projet, l’engagement doit porter sur le rendement, et non sur le fonctionnel.

Si l’équipe projet s’engage sur le fonctionnel, c'est-à-dire sur un certain nombre de fonctionnalités, ces fonctionnalités devront être implémentées, quels que soient les changements dont elles auront été l’objet. Dans un engagement sur le fonctionnel, c’est l’équipe projet qui supporte le coût du changement.

En revanche, si l’engagement porte sur le rendement, par exemple un certain volume fonctionnel par jour, et si les coûts des changements sont estimés, ces coûts seront consommés par la prise en compte des changements, au détriment du budget de l’itération, donc du fonctionnel du produit final.

De manière illustrée, soit un projet sur lequel l’équipe projet se soit engagée à la réalisation de 20 points par jour - c’est une mesure qui n’a de sens que dans le cadre du projet : elle veut juste dire que la réalisation journalière est vingt, dix ou quatre fois plus importante qu’une réalisation estimée à 1, 2 ou 5 points, et qui a été choisie comme la grandeur de référence. L’itération en cours a été chiffrée à 300 points. Le client formule une demande de changement que l’équipe projet estime à 30 points, soit un jour et demi de travail selon le rendement adopté pour le projet.

Si cette demande de changement est réalisée dans le jour et demi prévu, le rendement de 20 points par jour est respecté : l’équipe projet remplit ses engagements et le client voit sa demande de changement prise en compte. En revanche, le volume fonctionnel de l’itération aura été augmenté de 30 points. L’alternative est alors la suivante : soit l’itération se termine à la date prévue, et pour cela il faudra faire le « sacrifice » de 30 points pris ailleurs dans le fonctionnel de l’itération ; soit l’itération conserve le même fonctionnel, mais elle sera livrée avec un jour et demi de retard sur le jalon prévu.

Dans les deux cas, le coût du changement est supporté par le client, soit par une baisse du volume fonctionnel, soit par un surcoût de réalisation. Et, dans les deux cas, l’engagement de rendement pris par l’équipe projet a été respecté.

Prendre en compte le changement dans la conduite d’un projet est indispensable pour livrer un produit en adéquation avec les besoins de ses utilisateurs. Calculer et intégrer son coût est aussi – et surtout – une façon de faire prendre conscience aux clients qu'une demande de changement n'est pas gratuite et qu’elle doit donc être exprimées de façon motivée et mesurée.

Computurellement vôtre.

Retrouvez tous nos articles sur www.computure.net et nos articles informatiques sur www.computure.net/fr/informatique.

Egalement dans la rubrique « Méthodes » :