Tout savoir sur les plans (qualité) projet, Synthèse Synertal

Vincent Iacolare
Vincent Iacolare, Synertal

En matière de plans de projet, chacun y va de sa définition. L’exploration des normes et référentiel en la matière nous éclaire sans forcément  nous donner le Saint-Gall. Mais avec du retour d’expérience terrain, chacun arrive à avoir une vision claire.

C’est le but de ce billet. Peut-être pas juste ou incomplet aux yeux des uns et des autres.. mais qui se tient et pourra constituer  une base de travail, de réflexion et d’échange.

Quels sont tous  les plans  du projet et  les  liens entre eux ?

Il faut d’abord préciser que peu importe le nom et le contenu précis de chaque plan. Ce qui compte c’est que tout y soit pour une bonne maîtrise et mise en œuvre de nos projets.

Pour parler des plans du projet, il faut  prendre conscience de trois mondes :

* le système de management de l’entreprise : organisation, processus, procédures permettant d’atteindre la stratégie et les objectifs de l’entreprise. Selon iso 9000, « ensemble d’éléments corrélés ou interactifs permettant d’établir une politique et des objectifs et d’atteindre ces objectifs »

* le management de projet : ensemble des activités de management permettant la maîtrise du projet  (management  des coûts, management de délais, management des risques…). Ces activités ne consistent pas à réaliser le projet mais à le manager (gérer, maîtriser) Selon ISO10006, « planification, organisation, suivi, maîtrise et compte-rendu de tous les aspects d’un projet  et de la motivation des personnes impliquées pour atteindre les objectifs du projet »

* la mise en œuvre du projet : ensemble des activités du projet visant à atteinte les livrables du projet : faisabilité, définition du contenu du projet, planification du projet, avancement, contrôle et surveillance (définition  et suivi des coûts/ délais/ risques/….)

Votre réussite passe par la performance de vos projets !
Partenaire de DantotsuPM

Listons les différents plans du projet

* Plan projet (monde de la « mise en œuvre du projet » ): contient les références de base pour la mise en œuvre du projet (qualité, contenu, performance, échéancier,  coûts, risques, ressources…) sur toutes ses phases (lancement,  préparation, réalisation et contrôle, clôture)

* Plan de management du projet  (monde du « management de projet » ) : contient les dispositions de management du projet (la manière dont le projet est entrepris, suivi et maîtrisé. Définit les rôles, les responsabilités, l’organisation et les procédures pour chacun des processus de management de projet). Selon ISO 10006, document qui spécifie les éléments nécessaires permettant d’atteindre l’(les) objectif(s) du projet  (Il convient que le plan de management du projet comprenne le plan qualité du projet ou s’y réfère)

* Plan qualité  (entre les deux monde du « système de management » et  du « management de projet » ) : c’est l’application / la déclinaison du système de management qualité à un projet  un produit, un processus ou un contrat particulier. Pour un projet, c’est pour ainsi dire le système de management particulier pour le projet. Selon ISO 10005, ISO 10006, ISO 9000, « document spécifiant quelles procédures et ressources associées doivent être appliquées par qui et quand, pour un projet  un produit, un processus ou un contrat particulier (Ces procédures comprennent généralement celles faisant référence aux processus de management de la qualité et aux processus de réalisation de produits. Un plan qualité fait souvent référence aux parties du manuel qualité ou à des documents de procédure) »

* Plan d’assurance qualité (monde du « management de projet » ) : c’est la partie du plan de management de projet dédié à l’assurance qualité, c’est à dire aux dispositions permettant de donner confiance a priori de la réponse aux exigences du projet. Selon iso 9000, « partie du management de la qualité visant à donner confiance en ce que les exigences pour la qualité seront satisfaites ».

Liens entre les plans

Source : formation « Qualité projet », V. Iacolare, Afnor Compétences (code stage 556)
Source : formation « Qualité projet », V. Iacolare, Afnor Compétences (code stage 556)

Quel est le contenu des plans du projet ?

Chacun des plans ci-après comprend également d’autres plans ou y fait référence (par exemple le plan de management de projet comprend le plan d’assurance qualité).

* Plan projet : présentation du projet (contexte , objectifs, planning directeur & livrables…), organisation du projet, , structure technique du projet (AP, OT …), logique de déroulement du projet (ordonnancement,  jalons, revues …), réseau des contributeurs (SDC, OF, ressources …), coûts et budgets, logique d’avancement du projet, risques (univers , fiche de risques, suivi et capitalisation des risques), documentation de management du projet (liste des documents, état, …), mesure et amélioration de la qualité…

* Plan qualité (selon ISO10005) : Domaine d’application , Éléments d’entrée du plan qualité, Objectifs qualité, Responsabilités de la direction, Maîtrise des documents et des données , Maîtrise des enregistrements , Ressources , Exigences , Communication avec les clients , Conception et développement.,  Achats, Production et préparation du service,  Identification et traçabilité, Propriété du client, Préservation du produit , Maîtrise du produit non conforme, Surveillance et mesures, Audits.

* Plan qualité projet : appliqué à un projet, le plan qualité s’apparente au plan de management de projet s’il décrit les dispositions spécifiques pour un projet donné. Il s’apparente à une procédure du système de management qualité s’il décrit les dispositions génériques applicables à tous les projets.

* Plan de management du projet (selon RG Aero 0040) : dispositions de gestion de l’organigramme des tâches,  l’organisation du programme, la logique de déroulement et suivi de programme,  la maîtrise des coûts et des délais, la configuration, la performance et la sûreté de fonctionnement, le soutien logistique intégré, l’assurance qualité, la documentation,

* Plan d’assurance qualité : Standards / Référentiels du projet, Méthodes et outils à appliquer pour le projet , organisation d’AQ et lien avec l’organisation du projet, actions d’assurance qualité projet (Inspections, contrôles, traçabilité, revues, audits…)    y compris la planification & coûts des actions d’AQ projet, dispositions d’amélioration

Sources :

  • retours d’expérience Synertal.com et beeznet.fr
  • FD ISO 10005 :2005  Systèmes de management de la qualité – Lignes directrices pour les plans qualité
  • ISO 10006:2003  Systèmes de management de la qualité — Lignes directrices pour le management de la    qualité dans les projets
  • ISO 21500 :2012 – Lignes directrices sur le management de projet
  • Formation « Qualité dans les projet », V. Iacolare, Afnor compétences (code stage 556)
Campana & Schott
Partenaire de DantotsuPM

une stratégie simple pour gérer la dette technique

A simple strategy for managing technical debt

http://madebymany.com/blog/a-simple-strategy-for-managing-technical-debt par James Higgs

Auparavant, j’ai essayé d’expliquer le concept de dette technique. Aujourd’hui, j’essayerai de suggérer une façon pratique de la suivre à la trace et de la traiter dans votre projet.

dettes techniquesComme avec une dette dans le monde réel, le truc avec la dette technique est de suivre vos dettes à la trace et de vous assurer que vous avez un plan pour les régler. Autoriser les dettes à croître sans réfléchir à ce que vous faites est une façon épouvantable de diriger vos finances personnelles comme votre projet de développement logiciel.

Tant que vous prenez des décisions informées et délibérées sur quand encourir de la dette et quand la rembourser, vous n’avez pas nécessairement besoin d’un plan pour éliminer totalement votre dette. Vous devriez plutôt aspirer à la garder à un niveau acceptable pour que vous puissiez ajouter de nouvelles fonctionnalités à votre produit relativement facilement et sans trop d’effets secondaires.

tenir un registre

Mon conseil numéro un avec la dette technique est de tenir un registre dans un format simple dans votre bibliothèque de code source et avec celui-ci. Un document « Markdown » est une façon simple et facilement compréhensible de faire ceci.

ajouter les nouvelles dettes

Assurez-vous que chaque développeur de l’équipe connaît et comprend ce registre. Chaque fois que vous ajoutez à la dette, ajoutez une ligne correspondante dans votre registre dans le même « commit » que le code en cause.

Parfois vous réalisez que vous ayez contracté une dette seulement après coup, peut-être parce qu’une bibliothèque que vous utilisez n’est pas aussi puissante que vous l’aviez pensé, ou parce que les besoins changent inopinément (ce que nous appelons ici ‘un changement explosif ‘). C’est OK, ces choses arrivent dans les projets logiciels. La chose importante est d’acquérir une bonne idée de la taille de la dette aussitôt que vous le pouvez et de vous assurer que vous la saisissez dans le registre.

retirer les dettes remboursées

Quand vous réglez à nouveau la dette, enlevez l’entrée correspondante du registre et replacez le registre dans la bibliothèque de code.

Faites une routine de conduire des revues régulières  du registre de dettes et de vous assurer que vous avez un plan actif pour adresser chaque ligne. Une fois par itération est probablement une fréquence raisonnable pour faire cette passe.

paiementPartagez le registre avec votre client et assurez-vous qu’il comprend la raison pour encourir toute nouvelle dette et la taille du remboursement probable. Cela signifie que vous devez les aider à comprendre la motivation d’une mise en œuvre sous-optimale, les effets secondaires qui vont probablement produire, aussi bien que le coût prévu pour perfectionner la solution mise en œuvre quand la dette sera réglée.

Vous le devez à vos clients pour les aider à comprendre l’impact de votre prise de décision collective sur un projet. Pas assez de personnes le comprennent. Tous les systèmes sont une collection de compromis et la dette technique est une des expressions de telles prises de décision. Ceci peut souvent être une conversation difficile si le concept de dette technique est nouveau pour votre client, mais votre honnêteté paiera sur long terme.

La chose la plus importante à comprendre pour des clients est qu’ils doivent avoir un budget pour le développement continu de leur projet. Trop de projets sortent et sont ensuite autorisés à se dégrader et dans des nombreux cas le client n’aura pas été mis au courant des conséquences d’une telle approche. Donc, ils peuvent s’attendre à ce que vous puissiez tout simplement reprendre là où vous vous étiez arrêtés, peu importe combien de temps a passé. Les aider à comprendre comment fonctionne le développement logiciel fait partie de votre travail si vous êtes technique.

« Grade Two debt: Developers making themselves feel more comfortable »

faire la somme des dépensesSi vous traitez avec de la dette de Catégorie 2, une dette de « confort », quand vos développeurs vous disent que vous devez récrire votre système, la meilleure chose à faire pour désamorcer les émotions inhérentes est de leur faire créer un registre de dettes pour vous. Chaque entrée dans le registre devrait être clairement compréhensible par des développeurs et des personnes non techniques également et elles devraient toutes être actionnables.

Demandez-leur d’évaluer l’effort impliqué dans la résolution de chaque ligne du registre dans un jeu de planification et comparez ce coût au coût de reconstruire en repartant de zéro. N’oubliez pas que si vous les laissez reconstruire le système, ils construiront un système qui inclut aussi une nouvelle dette car le système sans dette n’existe pas. Alors, factorisez aussi cela dans le coût de remboursement.

Il est presque certain que vous constaterez qu’il est plus efficace financièrement de modifier le système existant que de le reconstruire.

pour conclure

La dette technique judicieusement encourue et bien gérée peut faire partie d’une approche raisonnable du développement logiciel. Simplement, n’oubliez pas d’avoir un plan de remboursement de la dette avant que les gros bras récupérateurs de créances ne viennent vous voir avec leurs barres de fer et portent in intérêt tout particulier à vos genoux.

le test est mort par Alberto Savoia

« Test is Dead » était le titre provocateur de la présentation d’ouverture à la 6ème Conférence Annuelle d’Automatisation de Test chez Google (GTAC) en 2011 par Alberto Savoia

La façon dont la plupart des logiciels sont conçus, développés et lancés a radicalement changé au cours de la dernière décennie, mais qu’en est-il du test ? Alberto Savoia croit que le test de logiciel tel que nous le connaissions est mort, ou du moins moribond. Sur cette idée directrice, Alberto lapide la vieille mentalité de test et donne son meilleur pour vous faire réfléchir et vous convaincre que, de nos jours la plupart des testeurs devraient adopter une nouvelle mentalité de test. Celle-ci changera leur focus et leur priorité du « construisons-nous bien ? » vers le « construisons-nous la bonne chose ? ».

Le sous-titre de GTAC 2011 était « nuageux avec une chance de tests » («  »cloudy with a chance of tests »), or, si quelqu’un peut rassembler les nuages pour en faire un ouragan c’est Alberto !

Alberto Savoia

Alberto Savoia est le Directeur d’Ingénierie et l’Agitateur d’Innovation à Google (« Director of Engineering and Innovation Agitator at Google »). En plus de supporter plusieurs efforts de développement de produits majeurs (incluant le lancement de Google AdWords), Alberto a été un partisan perpétuel, un champion, un innovateur et un entrepreneur dans le domaine du test et des outils d’automatisation de test. Il est un orateur de talent dont vous apprécierez certainement en autres les formules « Waterfall ou Waterfail? » et « Agile ou FR-Agile » ou encore le concept de prEtotyping. Son travail sur les outils de développement logiciels lui a valu plusieurs récompenses incluant le Technical Innovator Award 2005du Wall Street Journal , la Technologiede l’année chez InfoWorld et pas moins que quatre Award du Magazine de Développement Logiciel Jolt.

Alors appréciez la première demi-heure de sa présentation dont la mise en scène est de nature à capturer immédiatement l’attention du public.

les geek games : la bataille pour la dernière place

CAST Software futur partenaire de DantotsuPM

Il y a une grande différence entre une équipe d’athlètes qui perd et une équipe de développement qui perd : Personne ne se rappelle des athlètes arrivés en dernière position, mais tout le monde se souvient quand l’application délivrée par une équipe logicielle échoue spectaculairement et fait la une des journaux et blogs dans le monde entier.

De même que les athlètes ne gagnent pas de médailles d’or d’un jour à l’autre, les équipes de développement de logiciels très performantes ont besoin d’expertise, de discipline et d’un engagement à l’excellence. CAST a rassemblé certaines de ses meilleures ressources pour vous aider à vous assurer que votre équipe est parmi les meilleures, parcourez leur tout nouveau « infotoon » (illustrations amusantes de plusieurs papiers blancs sur ces sujets) pour aider votre équipe à concourir pour l’or!

« CRASH Report » – Chefs de projets informatiques ne ratez pas cet immanquable rapport gratuit sur la qualité logicielle

Que vous soyez chef de projet informatique ou responsable de tout projet qui comporte une partie d’informatique, ce rapport est à lire pour mieux comprendre certains des challenges liés à la qualité des logiciels applicatifs.

Que nous révèle le CAST Report on Application Software Health (CRASH) ?

Bien que ce ne soit une surprise pour personne je l’espère, le CAST Report on Application Software Health (CRASH) a confirmé que les organisations gaspillent des millions de dollars dans la dette technique en raison de problèmes avec leurs logiciels applicatifs, problèmes qui auraient pu être éliminés pendant la mise en production si les évaluations structurelles techniques appropriées avaient eu lieu.

Bill Curtis
Bill Curtis

Selon le Docteur Bill Curtis, le scientifique en chef chez CAST Software, la plupart des sociétés ne prévoient pas suffisamment de budget pour la maintenance de leurs applications et ceci nuit gravement à leur compétitivité dans leurs marchés.

Cette étude est la plus grande analyse automatisée jamais conduite et utilisée pour mesurer la qualité structurelle de 365 millions de lignes de code dans 745 d’applications informatiques utilisées par 160 sociétés partout dans 10 industries.

La prochaine édition du rapport doublera pratiquement le nombre d’applications analysées.

5 “facteurs de santé” des applications informatiques ont été passés en revue pour déterminer leur bonne santé structurelle : sécurité, performance, robustesse (c’est-à-dire, temps de disponibilité) et la facilité à faire évoluer et à transférer le logiciel. Malgré des estimations conservatrices, telle que les 75 $ de l’heure pour réparer les logiciels qui ne prennent pas en compte le coût business d’indisponibilité des applications et éventuelles pénalités commerciales, les chiffres parlent d’eux-mêmes : une grande partie des applications étudiées excèdent les $3M de dette technique !

Peut-être même plus inquiétant, plus d’un tiers (35 %) des problèmes rencontrés auraient un impact direct sur le business. Ces problèmes se répartissent majoritairement entre les domaines de la performance, la sécurité et la robustesse et fournissent la confirmation que les sociétés doivent prêter une bien plus grande attention à la qualité structurelle des logiciels sous peine de faire face à des aléas très coûteux qui affecteront défavorablement leur réputation.

CRASH - Security Scores per Technology
CRASH – Security Scores per Technology

Points saillants de l’étude:

  • La qualité structurelle est la plus faible pour les applications ayant 6 versions ou plus déployées chaque année (1 version tous les 2 mois)
  • Les applications avec le plus grand nombre d’utilisateurs sont aussi les mieux notées sur l’aspect maintenabilité
  • Les vieilles applications COBOL sont mieux sécurisées que celle en .NET qui ont reçu les plus faibles scores coté sécurité
  • CRASH - Quality onshore vs offshoreLes applications externalisées et développées en interne ne sont pas très différentes quant à la qualité de leur structure. Il en va de même pour les développements Onshore et offshore.
  • Des méthodes de développement bien établies comme agile et « en cascade » obtiennent des résultats significativement meilleur sur la qualité structurelle que les méthodes propriétaires.
  • La méthode développement « en cascade » donne les meilleurs scores de transférabilité et de facilité d’évolution.
  • Coté performance, les applicatifs en Java se situent bien au-dessous des COBOL !
The Crash Report 2011-2012
Téléchargez ce rapport gratuit en cliquant sur cette image

cultivez vos talents – Projet et qualité, de nombreux points communs !

Projet et qualité, de nombreux points communs !

Quand on parle de qualité, il vient rapidement à l’esprit le schéma bien connu du PDCA (Plan, Do, Check, Act) ou roue de Deming.

En détaillant ce schéma, nous voyons qu’il évoque des concepts communs au management de projet :

Management de projet - PDCA (Plan Do Check Act)PLAN : un projet se caractérise par un planning, la définition d’objectifs et une analyse des risques

DO : un projet « produit », des fonctions issues de l’expression de besoins, sous forme de livrables, de solutions, de propositions, etc.

CHECK : un projet se pilote notamment avec des revues de projets, des indicateurs, des audits.

ACT : un projet fait l’objet d’un bilan pour le retour d’expérience et déclencher, si besoin, des actions d’amélioration.

Au final: de nombreuses convergences entre la logique qualité et celle des projets.

Ceci a conduit à des travaux normatifs sur la qualité dans le domaine des projets que nous allons résumer ci-dessous :

•   NORME ISO 10006 de 2003 : lignes directrices pour le management de la qualité dans les projets : cette norme donne des indications pour avoir une démarche qualité dans les projets. Il n’y pas de certification par tierce partie ISO 10006 mais des audits (internes ou externes) peuvent être conduits par rapport à ce référentiel.

•   Projet de NORME ISO 21500 sur la gestion de projet : en cours d’élaboration avec d’âpres discussions. Sa publication est prévue en 2012.Cette norme permettrait une certification par tierce partie comme pour l’ISO 9001.

Des documents AFNOR existent sur le management de projet :

•   FD X 50-115 de 2001 : management de projet : présentation générale

•   FD X 50-116 de 2003 : management de projet : management par projet : présentation et recommandations de mise en œuvre

Des documents spécifiques à certains points du management de projet complètent ces normes générales :

•   ISO/CEI 62198-2002: Gestion des risques liés à un projet : lignes directrices pour l’application

•   Projet FD X 50-047 : expertise de projet

•   FD X 50-117 : management des risques dans les projets

•   FD X 50-118 : recommandations pour le management d’un projet

•   FD X 50-137 : management des coûts

•   FD X 50-138 : management des délais

En conclusion, la gestion de la qualité et des projets ont beaucoup de points communs et peuvent s’aider mutuellement pour garantir et améliorer les performances d’une organisation.

Article écrit par Jean-Baptiste Jourdant, consultant-formateur et Responsable du département Management de projet pour CSP Formation et partenaire de DantotsuPM. Retrouvez cet article sur le blog Management de Projet de CSP Formation à l’adresse suivante : http://management-projet.cultivezvostalents.fr

CSP Formation
Partenaire de DantotsuPM

Cela en vaut-il vraiment la peine ?

Seth Godin's Blog

J’apprécie très souvent les billets de Seth Godin. Ils sont à la fois provocants et pleins d’intelligence, de bon sens et de malice. En bref, ils donnent à réfléchir.

Celui-ci est dans la ligne de pensée de ce blog DantotsuPM et de la recherche de l’excellence pour constamment dépasser les attentes des clients et en faire ainsi de vrais fans de nos produits et/ou services. Des membres de notre tribu comme le dirait Seth. La tribu des chefs de projet qui cherchent en permanence à s’améliorer.

Hardly worth the effort (version originale)

Cela en vaut-il vraiment la peine ?

Dans la plupart des domaines, il y a une quantité terrible de travail mise dans les dix derniers pour cent de qualité.

Amener votre score de golf de 77 à 70 est bien plus difficile que de l’amener de 120 à 113 ou même de 84 à 77.

Répondre au téléphone à la première sonnerie coûte deux fois plus cher que de le laisser entrer dans une file d’attente.

Faire des pâtisseries comme un  excellent restaurant demande beaucoup plus de travail que de faire des gâteaux au chocolat à la maison.

Concevoir la présentation d’une page ou d’une brochure qui ressemble à celle d’un pro demande environ dix fois autant de travail que d’utiliser simplement les modèles gratuits incorporés dans Microsoft, et le message est presque identique…

Sauf qu’il ne l’est pas. Bien sûr que non. Le message n’est pas identique.

Les dix derniers pour cent sont le signal que nous recherchons, la manière dont nous communiquons le soin, l’expertise et le professionnalisme. Si tout que vous faites est de niveau standard, tout ce que vous allez obtenir est une rétribution standard. La partie difficile est dans les dix derniers pour cent, bien sûr, voire même le tout dernier pour cent, mais c’est la partie difficile parce que tout le monde est déjà occupé à faire la partie facile.

Le secret est de rechercher le travail dont la plupart des personnes pensent qu’il ne sera pas valorisé en rapport de l’effort. C’est pour cela que vous êtes payé.

Défendre la qualité quand coûts et délais sont rois

Cet article de James T. Brown, PhD, PE, PMP sur PMI.ORG (original full article in English here) pose un problème que nous rencontrons trop souvent sur le poids de la qualité dans le sacro-saint triptyque des projets: coût, qualité, délais.

Chacun aime prendre de la fierté dans son travail. Cela inclut les chefs de projet et les équipes projet. Souvent cette fierté est mise à mal parce que la pression pour tenir les délais et le coût aboutit à des sacrifices sur la qualité.

Ironiquement cela aboutit fréquemment à des dépenses supplémentaires, des retards de planning importants ou des projets “suite” pour adresser les manques de qualité. Un centre sur la qualité est le bon sens et mieux à long terme.

Malgré cela, c’est un problème organisationnel très commun de renoncer à la qualité pour atteindre des cibles de coût et de planning. Dans l’environnement économique d’aujourd’hui, la pression sur les coûts est énorme. Une fois que quelques leaders commencent à se concentrer sur le coût, cela peut devenir tout ce dont ils se soucient.

Cette attitude, répétée pendant la durée des cycles de projet ou des années, s’enracine. Comme un collègue me l’a récemment fait remarquer, “Nous l’avons fait encore…dans les temps…dans le budget…pauvre qualité.”

En fin de compte, la mauvaise qualité des livrables du projet a ses racines dans un manque de responsabilité pour cet aspect du projet. On juge régulièrement les sponsors de projet sur ce qui est facilement quantifiable, comme les coûts et l’atteinte des cibles planifiées, tandis que la qualité est juste assumée être délivrée. C’est amplifié s’il y a un manque de communication et/ou un lien de responsabilité faible entre utilisateurs ou clients et les sponsors de projet.

Le chef de projet peut faire plusieurs choses pour améliorer la qualité des livrables pour des projets dans des environnements où les coûts et les délais sont rois.

Identifiez les Joueurs Clefs

Pour améliorer la qualité, il est impératif d’identifier qui sont les sponsors de projet et ce qui pilote leur comportement. Qui (ou quoi) fait que le sponsor soit centré sur les coûts et les délais ? Comment le sponsor est-il personnellement impacté par la mauvaise qualité des livrables ? Qui sont les utilisateurs et les clients ?

Le rapport entre l’utilisateur, le client et le sponsor devrait aussi être compris et documenté. Comment l’utilisateur du livrable du projet communique-t-il (ou pourrait-il communiquer) des problèmes de qualité au sponsor ? Les sponsors sont souvent à un tel haut niveau dans l’organisation par rapport aux utilisateurs qu’il n’y a aucun canal de communication.

Rassemblez des Données

Ma définition de geindre est se plaindre sans données. Chaque fois que la qualité n’atteint pas l’objectif défini pour une quelconque raison, l’impact de cette non-conformité doit être documenté.

À la fin d’un projet, les chefs de projet se concentrent souvent rapidement sur le projet suivant. Ils peuvent rater l’occasion d’échanger avec les utilisateurs ou de faire un suivi efficace pour identifier les dépenses dues à une mauvaise qualité sur des livrables précédents du projet. Ces informations sont essentielles pour construire un argument fort de créer à l’avenir un focus sur la qualité.

Souvent, des leaders organisationnels regarderont une livraison de projet qui n’a pas atteint les pré-requis de qualité comme une anomalie ou ils auront le sentiment qu’il y avait des circonstances spéciales sur ce projet. Mais quand vous pouvez présenter des données de plusieurs projets ou celles de tous les projets sur une longue période, cela renforce le fait qu’il faut faire quelque chose.

Exploitez les opportunités

Le chef de projet a maintenant des données sur le coût d’une mauvaise qualité. Lui ou elle doit en faire comprendre l’impact aux sponsors et développer les arguments pour la nécessité de changement.

Le fait que ce problème et cette culture existent dans des organisations indique que c’est au moins en partie de nature politique. Cela signifie qu’il ne suffit pas d’avoir raison. Il ne suffit pas d’avoir des données. Vous devez analyser l’organisation et la politique pour identifier quand et comment faire progresser votre sujet.

Il y a des circonstances et des moments où l’organisation peut être plus réceptive. Quand cette occasion surgit, vous devez être prêts à intervenir avec les données qui montrent l’impact du problème et aussi proposer des solutions.

Mon expérience est qu’un “ papier de position” professionnel, écrit  de manière persuasive, qui encapsule le problème et la solution, est essentiel. Il devrait être écrit dans des termes et dans le contexte qui sont importants pour les joueurs clefs. Une présentation peut accompagner le papier de position, mais le papier de position peut être envoyé aux joueurs clefs que vous avez identifiés et qui sont essentiels pour exécuter un changement.

En surface, le problème de renoncer à la qualité pour atteindre le planning et les cibles de coût semble simple à réparer — mais il ne l’est pas.

Des réparations simples ou rapides ne fonctionnent pas et aboutissent à de la frustration. Si vous voulez être un champion de la qualité dans un environnement centré sur les coûts, acceptez le fait que vous exécuterez un marathon et non pas un sprint et que ce sera une course que vous devrez répéter de nombreuses fois.