navigation

Trop de qualité 19 août, 2008

Posté par dailymanager dans : budget,efficacite,objectif , trackback

C’est une critique que j’ai entendu plusieurs fois venant de la direction. Nous ferions « trop de qualité ». Mais peut on reprocher de faire trop de qualité.. au dépend de quoi d’autre ? Tentative de décryptage d’une incompréhension réciproque…

Le B.A.BA de la gestion de projet nous a appris qu’il existe 4 objectifs principaux : le respect du délai, la couverture du périmètre, le contrôle du budget, et le niveau de qualité. Si vous augmentez l’un de ces paramètres, mécaniquement, les 3 autres se dégradent. Souvent, ce principe est illustré par un carré, et le but du chef de projet est de maintenir le curseur du projet au centre de ce carré pour une satisfaction totale de tous les acteurs.

Trop de qualité dans budget projetpqdc

Il y a des représentations alternatives. Un projet au forfait présente la caractéristique d’être un engagement de résultat, et le curseur périmètre étant fixe, il disparait : on représente le triangle des objectif délais-coûts-qualité.

projetqdc dans efficacite

Selon certains points de vue, les délais étant contraints par des pénalités de retards, économiquement, on préfère alors n’avoir qu’un seul segment de marge de manoeuvre qualité/coût.

projetqc dans objectif

Autre cas de figure, sur un projet en mode agile, la qualité n’est pas négociable et c’est elle qui disparait du carré, on préfère alors jouer sur l’axe du périmètre, en rajoutant des itérations pour affiner le produit. Chaque itération est une rallonge sur le budget et sur le délai de livraison finale du produit. Sur un projet agile on évite au maximum le changement de l’équipe. Avec un coût quasi fixe par itération, les coûts deviennent proportionnels aux délais.

projetpdc

Parmi tous ces modèles vous devinez lequel s’applique aux projets au forfait. Il s’agit du plus simple, le segment Qualité/Coûts. On pourrait croire qu’il reste une marge de manoeuvre laissée au chef de projet, celle de se positionner sur ce segment.  Il peut par exemple, faire du quick&durty, efficacité économique absolue. Ou alors faire de la qualité, avec l’engagement de réversibilité.

Ce choix n’est finallement pas de son ressort, mais du contexte commercial. En particulier dans le cadre du groupe dans lequel je travaille, l’activité n’a pas assez de volume en entrée, et les directions commerciales préfèrent donner une bonne image au client, pour pouvoir construire de belles références, et pourquoi pas, récidiver chez le même client. Dès lors, le curseur est explicitement mis vers la qualité dès la réunion de lancement du projet. On parle d’engagement de réversibilité, de niveau de documentation, de qualité du code…

Mais lorsque j’entends qu’on fait « trop de qualité » sur les projets au forfait, c’est un autre discours que j’écoute, celui qu’on n’est pas assez bon en gestion des coûts. Ce discours apparait toujours au moment du bilan économique. Et les dépassements sont majoritairement imputés à la faible productivité ; c’est bien entendu le cas, notamment pour tout projet qui démarre avec une équipe exclusivement de jeunes diplomés.

« Trop de qualité »… Nous passerions donc notre temps à demander et/ou faire des choses à moyen terme, de beaux modèles logiciels qui peuvent tout faire, au lieu de nous prioriser sur le strict besoin immédiatement exprimé. Les opportunités de capitalisation permettront à moyen terme de gagner du temps et de l’argent, mais la réutilisabilité est sans doute une utopie, une perte de temps. Nous devrions nous prioriser sur les réponses immédiates et, pourquoi pas, privilégier le quick&durty. Le php revient parfois sur la table.

En ce qui me concerne, un objectif de rentabilité demandé au plateau est une bonne chose. Car il faut responsabiliser les chefs de projet sur le choix de placer le curseur sur ce segment qualité/coûts. Mais, a contrario, il faut alors que tout le monde assume les conséquences d’une stratégie quick&durty. Or vu le faible niveau d’activité des projets au forfait, il est peut être plus stratégique de se construire de belles références et conserver une image de sérieux et… de qualité.

J’ai parlé d’objectif de rentabilité générale, je n’ai pas parlé d’objectiver les chefs de projet à la rentabilité de leurs projet, qui, par contre, induit beaucoup plus d’effets pervers. En effet, le reflexe de chaque objectivé, serait de ne se préoccuper que de son projet, comme une bulle, et de ne pas investir sur la qualité pour les autres. Mais les projets sont inégaux en difficultés et en criticité, et nous risquerions de soulever des débat stériles sur les injustices d’affectations. Et nous pourrions envisager des conflits nouveaux autour d’une refacturation de composants réutilisables entre projets. Bref, une compétition concurentielle au lieu d’une compétitivité collective. Une idée intéressante serait d’objectiver les chefs de projet sur la rentabilité générale des projets au forfait, répartis ensuite au proratta du temps passé. Cela les inciterait alors à communiquer, à s’informer, et à s’entraider. Ces objectifs collectifs seraient plus efficaces que des objectifs individuels. Selon les opportunités, les chefs de projets pourraient suggérer d’accentuer la qualité sur un projet, ou de faire moins cher sur un autre, dans une stratégie globale et non cloisonnée.

Il existe deux visions de la direction de projet qui semblent s’opposer : une équipe de chefs de projets qui monte en responsabilités, ou un directeur nominatif, qui fait appliquer ses décisions par les chefs de projets. J’ai déjà présentée, dans un précédent article, la définition de ce que j’appelle management2.0 . Les subordonnés sont force de propositions et d’initiatives, et le manager coordonne et assume les choix collectifs. C’est ce manager qui consolide l’ensemble qui est garant de la rentabilité générale, les chefs de projet se redistribuant les curseurs qualité/coûts. Le directeur de projet n’est pas un super-chef-de-projet, il a un autre rôle bien identifié. Finallement, c’est ni plus ni moins que la fusion des deux approches qui tendaient à s’opposer.
« Trop de qualité », cela n’a finallement de sens que si on définit à partir de quand on dépasse le raisonnable.  Si la rentabilité générale définit une taille de gâteau, les projets opportunistes – avenants, réutilisation, … - auraient une petite part, les projets investissants- stratégiques, innovants… – auraient une plus grosse part. Les projets sont tous différents, la définition du seuil « trop de qualité » ne peut se faire qu’au cas par cas.

Commentaires»

pas encore de commentaires

Laisser un commentaire

sitehgeo4 |
"L'arbre qui tombe peut fai... |
Dra. Monica Guia |
Unblog.fr | Créer un blog | Annuaire | Signaler un abus | citoyen
| Petite écologie d'un insect...
| SonyaT