→ Le chiffrage de projet informatique : troisième partie, principes et idées-clés ★ Chef de Projet Malin

Le chiffrage de projet informatique : crédibilité, principes et idées-clés

Beaucoup de choses à dire sur le chiffrage de projets, l’estimation des coûts dépendant de nombreux facteurs et leur suivi encore plus ..

Nous avons vu comment chiffrer un projet à partir d’un cahier des charges, nous avons vu comment chiffrer la gestion de projet, la documentation, une équipe near-shore, voici maintenant un petit récapitulatif – en vrac – des principes et idées-clés.

Quelle crédibilité accorder à un chiffrage ?

N’importe qui peut chiffrer une ou plusieurs tâches, je peux demander à ma grand-mère de me sortir un chiffrage. La qualité d’un chiffrage est donc très relative, et ne pourra être évaluée réellement qu’à la fin de la réalisation de la tâche .. D’ailleurs, le meilleur chiffrage (et encore … voir plus loin), c’est de réaliser la tâche et de voir combien de temps on y a passé .. Rares sont ceux qui vont se challenger par rapport au chiffrage initial et une fois le projet en feu, on a d’autres préoccupations que de faire un bilan ..  Donc tout le monde va avoir son mot à dire pour un chiffrage, y compris ceux qui n’interviendront aucunement dans le delivery (la réalisation des livrables), donc méfiance …

Mais alors comment avoir un chiffrage de qualité ?

La qualité d’un chiffrage dépend du contexte et de l’engagement qui lui est associé : si je m’engage à faire une tâche en 2 jours et que si je dépasse cette charge, je ne suis pas payé, je suis beaucoup plus engagé que si j’annonce 2 jours mais que si je dépasse je serai payé de la charge et du dépassement. La motivation n’est pas la même et le risque non plus. Un chiffrage sans notion d’engagement n’a donc pas de valeur. La SNCF annonce un délai de 2h02 pour faire Paris-Lyon mais finalement ne s’engage à payer une compensation réduite qu’à partir de 30 minutes de retard si le retard est imputable à la SNCF … l’engagement est modéré. Il est donc facile de faire un chiffrage « bas » pour vendre un projet avec peu d’engagement.

Bien évidemment, un niveau de confiance peut déjà exister entre le demandeur et le réalisateur, le chiffrage sert à ce moment-là d’indication plus ou moins fiable pour évaluer le délai de réalisation et/ou le budget associé. Dans ce cas, une évaluation du chiffrage initial en regard du chiffrage réel peut permettre de mesurer régulièrement la fiabilité.

Voir également l’article : Perdre toute crédibilité en 3 minutes en phase d’avant-vente projet

Un chiffrage n’a d’intérêt que s’il est piloté !

Le chiffrage doit être accompagné d’un pilotage : si j’ai 2 jours pour peindre 4 murs, si personne ne vérifie au bout d’une journée que j’en ai bien peint 2, le risque de dépasser les 2 jours augmente .. Il ne s’agit pas de « fliquer » les personnes de l’équipe mais de vérifier qu’elles n’ont pas rencontré une difficulté technique ou fonctionnelle non détectée au préalable ou traîné sur facebook toute la journée … Cela permet de réagir avant la fin du délai : informer à l’avance le client d’un potentiel retard, renforcer l’équipe (si possible), recadrer une personne de l’équipe, faire intervenir un expert, …

L’idéal est de faire chiffrer la tâche par la personne qui va l’exécuter et de lui demander de s’engager dessus (ce qui ne marche qu’avec ceux qui comprennent la valeur de l’engagement). Mais en pratique, le chiffrage est déjà fait .. c’est donc à vocation pédagogique.

Attention, quand la personne qui chiffre est différente de la personne qui pilote le projet ou le réalise, la qualité du chiffrage est également très relative car l’engagement n’est pas le même .. C’est souvent le problème entre les équipes avant-vente et les équipes de réalisation ..

Attention aux règles et abaques de chiffrage

Attention aux abaques et règles de chiffrages toutes faites : appliquer du générique à du spécifique est source d’erreur, plus vous vous projeterez dans la future application, plus votre chiffrage sera réaliste. Et vous perdrez moins de temps à réfléchir si l’écran A est simple, complexe, hors norme, … Faites-vous vos propres règles et/ou tâchez de bien comprendre celles que vous utilisez.

Challenger une répartition de charges selon des pourcentages est donc peu judicieux. On entend souvent la gestion de projet c’est 15% du projet, les spécifications 20% de la réalisation (valeurs à adapter selon les cultures). Si les deux premières parties de ce thème ne vous ont pas convaincus, les points suivants devraient finir de vous expliquer pourquoi les règles absolues comme celles-ci ne sont pas gages d’un bon chiffrage. En effet, celui-ci dépend :

du contexte : s’agit-il de vendre ce chiffrage auprès d’un client dans un contexte d’appel d’offres ? souvent, plus il est petit, mieux c’est pour le client. On peut également être contraint de rentrer dans des grilles de chiffrage imposées avec une répartition spécifique, on peut donc être amené à chiffrer pour l’avant-vente et avoir un chiffrage différent dans le détail pour le suivi projet en interne.

de la personne qui va réaliser : si la personne de l’équipe a déjà exécuté ce type de tâche 20 fois, elle mettra moins de temps qu’une personne qui n’a jamais rencontré ce type de tâche. L’affectation va beaucoup jouer (et beaucoup changer ..).

de la tâche en elle-même bien évidemment : difficulté technique, difficulté fonctionnelle, difficulté à recetter, …

Comprenez ce que vous chiffrez !

Chiffrez sans connaître le budget !

Commercialement, c’est évidemment important d’avoir le budget pour que la proposition commerciale soit dans la cible. Mais en tant que chef de projet, on ne chiffre pas en fonction du budget d’un client : s’il a le budget pour une Clio, on ne peut pas lui fabriquer une Rolls Royce même si c’est ce qu’il souhaite. Après, c’est un effort commercial, mais il ne faut jamais diminuer la charge d’un projet, il faut diminuer le prix de vente. Il faudra toujours 2h02 pour faire Paris-Lyon mais la SNCF peut vous faire une remise de 30% sur le prix du billet (ou pas ..).

Et si le chef de projet connaît le budget ?

Inconsciemment, il va viser ce budget. Connaissant les tarifs journaliers généralement appliqué, il sait au fur et à mesure du chiffrage s’il va dépasser ou non et risque d’influencer les estimations restantes. Cela s’observe souvent chez les chefs de projet débutant qui considère que le budget du client correspond plus ou moins au chiffrage et du coup tâchent de faire rentrer le chiffrage dans le budget.  C’est seulement une question de confiance dans leur chiffrage. Bien sûr, avec l’expérience la confiance augmente et le fait de connaître le budget se fait moins ressentir.

Idées-clés pour un meilleur chiffrage : conclusions .. en vrac !

Un chiffrage doit s’expliquer, un chef de projet doit pouvoir le défendre devant un client : démontrer comment vous chiffrez va rassurer (ou non !) votre client, vous pouvez lui montrer ainsi que vous maîtrisez votre (futur) projet. Par ailleurs, expliquer votre chiffrage va peut-être permettre à votre client de comprendre que le chiffrage de votre concurrent a été fait à la louche ..

– Un chiffrage doit être à un niveau de granularité pertinent ou avec un découpage assez fin : que penser d’une tâche chiffrée à 80 jours ? Je suis client, je vois ça, je questionne mon fournisseur : « Et comment avez-vous évalué ces 80 jours ? qu’est-ce que vous allez faire pendant ces 80 jours ? » ou dit autrement « Où va passer mon argent ? »

– Un chiffrage doit être détaillé fonctionnellement : le chiffrage servira à cadrer le périmètre du projet. Par définition, une tâche non chiffrée ne fait pas partie du périmètre. Le pilotage projet pendant la phase de spécification permettra ensuite de gérer les petits aléas de périmètre.

– Vous pouvez avoir très bien chiffré, vous pouvez malgré tout avoir du dépassement si vous ne pilotez pas correctement votre projet : j’ai fini mon tout premier projet à 91 jours au lieu de 22 jours ! bon, quelqu’un d’autre avait chiffré et le client était de mauvaise foi (si si ! 😉 ) mais quand même .. Je vous raconte tout ici !

– Vous pouvez avoir très mal chiffré et finir à peu près dans les clous si vous pilotez votre projet de manière serrée pour ne pas dire agressive ! avec le risque que le client ne veuille plus travailler avec vous ensuite ..

L’apprentissage du chiffrage se fait surtout par la pratique en comparant l’estimé et le consommé, c’est comme ça que vous saurez où vous avez fait des erreurs et où vous pouvez progresser au prochain chiffrage.

– Gardez un oeil sur le budget, une journée de travail ne coûte pas la même chose selon la personne qui l’effectue. Faire développer toute votre application par un expert va vous coûter cher même si vous irez plus vite. Si les coûts sont homogènes, parlez en jour-homme ne pose pas de problème, s’il y a des disparités importantes, il est bon de suivre le budget plus que le chiffrage.

Ne chiffrez pas coûte que coûte : si vous n’avez pas assez de temps, si vous n’avez pas assez d’éléments pour chiffrer, si techniquement vos équipes ne sont pas compétentes, mieux vaut ne pas y aller ! Vous avez le droit de dire No-Go !

 

L’étape suivante après le chiffrage c’est le planning projet, je traite le sujet ici ! Vous pouvez également jeter un oeil à cet article sur comment cadrer un client avec un chiffrage.

Ce n’est pas transposable à tous les projets, ce n’est pas exhaustif, ce n’est pas la vérité absolue, cela ne fera pas de vous un chef de projet hors pair mais ça a vocation à faire réfléchir ..

Et vous ? quels problèmes liés au chiffrage avez-vous rencontrés ?

 

Cet article a été posté dans Gestion de projet.

12 réponses à Le chiffrage de projet informatique : crédibilité, principes et idées-clés

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Pour vérifier que vous allez mettre un commentaire humainement intelligent : * Time limit is exhausted. Please reload CAPTCHA.