Archives de Tag: quality

5 actions qui vous aideront à vendre ce projet si compliqué

15 mar

5 Actions That Will Help You Sell That Complicated Project

http://www.pmhut.com/5-actions-that-will-help-you-sell-that-complicated-project par Michael Greer

7 traits de personnalité des meilleurs commerciaux

relisez ce billet sur les 7 traits de personnalité des meilleurs commerciaux

Reconnaissons-le. Vous ne seriez pas chef de projet si vous vous étiez imaginé en personnel commercial. En effet, la plupart des chefs de projet, particulièrement ceux qui sortent des rangs des équipes projet et des experts techniques, détestent tout le "cinéma" qu’implique la partie vente de leurs projets.

Mais la vérité est il n’y a simplement personne que vous qui soit dans une meilleure position de mettre en évidence les capacités techniques étonnantes de votre équipe et la valeur qu’elle apporte à votre organisation à travers votre projet. Qui plus est, comme votre projet progresse, vous allez avoir besoin du support enthousiaste de la direction pour vous aider à obtenir les fonds, les personnels, les installations, l’équipement et la participation des experts métier qui amèneront au succès. Donc c’est à vous et aux actions spécifiques que vous entreprenez de construire cette vente et de générer cet enthousiasme si nécessaire du management.

Alors, par où commencer ? Voici 5 actions qui peuvent vous aider à vendre votre projet à la direction :

1. Prouvez que vous comprenez le problème business qu’adresse votre projet.

cliquer pour lire l'artice de PM Network

cliquer pour lire l’artice de PM Network

Spécifiquement, vous devez expliquer (ou encore mieux, démontrer par la preuve, les chiffres du retour sur investissement, etc) comment vos livrables élimineront une zone de douleur de votre organisation, augmenteront son efficacité, feront économiser de l’argent et auront un impact tangible.

2. Montrez comment chaque livrable ajoutera de la valeur.

Spécifiquement, vous devez faire la connexion entre chaque item que vous créerez et comment il contribue à la valeur de la solution finale. (Et non … vous ne pouvez pas assumer qu’ils peuvent déjà voir ces connexions simplement parce qu’elles vous sont évidentes!). Donc, vous devriez rapidement passer à travers la liste de vos livrables et aider le sponsor à voir comment chacun est essentiel à la qualité de la solution complète. Ceci devrait inclure les livrables de projets intermédiaires comme des graphes de flux, de premiers jets de livrables, etc. Si possible, montrez des modèles, des maquettes, des démonstrations, ou quoi que ce soit qui puisse le matérialiser et produire cette étincelle d’enthousiasme qui gardera votre sponsor à vos côtés dans les jours potentiellement difficiles à venir.

3. Connectez tout le processus de travail à la qualité (y compris les cycles de revue/approbation).

inspecter les livrablesEn langage clair, montrez comment le processus de travail est aussi "Lean" qu’il peut l’être, tout en fournissant les contrôles essentiels (revue d’expert et de management, participation collaborative, etc.) qui garantiront la qualité. Si approprié, montrez comment votre processus de travail est en phase avec les "bonnes pratiques" de l’industrie ou des concurrents.

4. Démontrez comment chaque membre de votre équipe projet fournit une valeur unique.

Eclairez-les sur l’expertise étonnante que vous avez rassemblée et comment chaque membre de votre équipe apportera une contribution unique à la qualité du produit final. Ceci est particulièrement important pour les membres de l’équipe qui demanderont éventuellement au sponsor l’accès à des ressources clés et autre support quand le projet avance. Cela aide vraiment si, quand le membre de l’équipe frappe à cette porte pour demander de l’aide ou un retour d’information, il le fait en tant que membre "pré-valorisé" de l’équipe projet.

5. Distinguez votre projet de projets apparemment similaires, mais moins complexes ou apportant moins de valeur.

approter des différencesQu’est-ce que cela signifie ? Simplement ceci : les Sponsors voient et approuvent des tas de projets. Et, après peu de temps, ils commencent à voir des modèles qui se répètent dans la façon dont ces projets se déroulent. Éventuellement, ils développent des attentes sur les processus de travail et les délais qui amènent à des types semblables de livrables. Étant donné ces attentes, les cadres supérieurs les plus durs et expérimentés voudront presque toujours connaître votre réponse à ce défi : "j’ai vu que des équipes projet semblables créent des résultats similaires en utilisant les processus qui étaient beaucoup moins compliqués. Alors pourquoi vos gars prennent-ils si longtemps et dépensent-ils tant de temps pour réaliser les mêmes sortes de résultats que le Projet XYZ ?". Si vous voulez emporter la vente (et le support enthousiaste de votre sponsor) tout en restant fidèle à vos bonnes pratiques, vous devrez avoir une bonne réponse à cette question!

mais quelles sont les responsabilités principales du PMO ?

25 jan

Key Responsibilities of the PMO

http://www.gantthead.com/article.cfm?ID=267501P par Brad Egeland

Brad Egeland

Brad Egeland

Un bureau de management de projet, Project Management Office (PMO), est une entité organisationnelle d’habitude chargée de centraliser et coordonner la gestion de projets dans une organisation. Un PMO surveille le management des projets et programmes, ou une combinaison des deux. Les projets supportés ou administrés par le PMO peuvent ne pas être reliés les uns aux autres.

Dans beaucoup d’organisations, les projets sont groupés ou rapprochés d’une certaine façon selon la façon dont le PMO coordonnera et gérera ces projets. Le PMO se concentre sur la planification coordonnée, la priorisation et l’exécution des projets et sous-projets qui sont liés à des objectifs fonctionnels de l’organisation parentale (ou du client). Le PMO est aussi responsable de pourvoir en personnel chaque projet avec les bonnes personnes pour donner la meilleure chance de succès au projet.

Les PMOs peuvent fonctionner sur un continuum, depuis fournir des fonctions de support au projet avec des formations, des logiciels, des procédures normalisées, jusqu’au management direct  réel et la responsabilité d’atteindre les objectifs de projet. Un PMO particulier peut recevoir la délégation d’autorité pour agir comme une partie prenante à part entière et un décideur pendant l’étape d’initiation de tout projet, peut avoir l’autorité de faire des recommandations ou peut arrêter des projets pour maintenir des objectifs fonctionnels cohérents. De plus, le PMO peut être impliqué dans la sélection, le management et le redéploiement (si nécessaire) de personnel partagé entre les projets et, possiblement de personnel dédié au projet.

Certaines des responsabilités et des caractéristiques principales de PMO incluent typiquement, mais ne sont pas limitées à :

why-pmosRessources partagées et coordonnées à travers tous les projets.

Le PMO agit comme le groupe centralisé de personnel de projet qui mène tous les projets dans l’organisation. Et, alors que le personnel de projet peut souvent venir de l’extérieur du PMO dans une organisation matricielle, les efforts et les décisions principales sur la dotation en personnel de ces projets, le « qui » et le « quoi », sont coordonnés au sein ou en accord avec la direction du PMO.

Identification et développement de méthodologie de conduite de projet.

Le PMO doit être celui qui définit, contrôle et forme sur la méthodologie de management de projet de l’organisation. Ceci comprend toutes les meilleures pratiques de management de projet qui devraient être utilisées pour implémenter des standards de management de projet et définir comment les projets doivent être gérés et suivis.

tour de controleCentre de commande pour les règles, procédures et modèles de projet.

Le PMO devient l’emplacement centralisé pour toutes les règles et procédures de management de projet et le centre d’acquisition et de développement de tous les modèles de projet, documents de planification et autre documentations. Cela s’applique aussi à la base de connaissance centralisée des leçons apprises et autres Questions/Réponses (Q&A).

Management de configuration centralisé.

Toute la gestion du changement et la gestion de configuration concernant les projets, y compris toutes les demandes de modifications, devraient être produites et gérées depuis le PMO. Cela permet un suivi et sert de référence pour de similaires changements et problèmes de configuration sur les projets futurs.

risque financierEnregistrement et management centralisé des risques.

Souvent, les risques ne varient pas beaucoup de projet en projet, tout du moins pour une grande majorité d’entre eux. Avec le PMO servant de point central pour le management des risques, on aide à diminuer l’effort qui doit être dépensé sur des projets actuels et futurs pour identifier le risque, manager les risques, éviter et réduire les risques.

Le bureau central pour l’opération et le management des outils de projet.

Tout comme la définition, la mise en application et la formation de la société dans son ensemble à la méthodologie de management de projet, il est aussi de la responsabilité du PMO que de choisir les outils de management de projet appropriés. Ceci inclue le logiciel principal de management de projet que le personnel de projet utilisera pour gérer tous les projets. Fournir un standard stable pour tous est important pour la réussite et la collaboration.

Canaux de Communication pendant le Cycle de vie du Projet

Canaux de Communication pendant le Cycle de vie du Projet

Coordination centrale de la communication.

La communication est la responsabilité la plus importante du chef de projet. Le PMO joue aussi un rôle critique dans ce processus. Le PMO est la source primaire de communication et d’annonce sur tous les projets. Cette communication s’adresse autant au personnel interne de la société qu’à ses clients externes, ses prospects et ses fournisseurs (si nécessaire).

Une plate-forme de mentoring pour chefs de projet.

Le PMO est directement responsable de former les chefs de projet et de mettre en œuvre une infrastructure de mentoring appropriée permettant aux chefs de projet moins expérimentés d’apprendre à côté (et avec) des chefs de projet plus expérimentés.

inspecter les livrablesLe contrôle central de tous les échéanciers et budgets des projets du PMO.

Avec un reporting de projet centralisé, le PMO devient un emplacement central pour contrôler les échéanciers et budgets des projets. Cela permet au PMO d’être le guichet unique pour des informations pour tout le management exécutif et les services financiers, plutôt que de charger des chefs de projet individuels avec encore une autre source de diffusion de leurs matériels et rapports de projet.

Coordination des normes de qualité complètes de projet.

Finalement, le PMO défini le standard pour toutes les normes de qualité en termes de management de projet, de leadership et de performance. Il sert aussi de d’intermédiaire entre les chefs de projet et tout personnel de qualité interne ou externe ou l’organisation de gestion des normes.

23 janvier – Paris – Séminaire "Normes et Référentiels… le ticket gagnant pour manager les projets !"

11 jan

Journée entière !

Afitep Dico management de projetISO 21 500, ISO 10 006, PMBoK, ICB, textes normatifs français, allemand, anglais, Prince2, Hermès, etc. les référentiels et les normes relatifs au management de projet sont nombreux et divers !

De quoi rendre perplexe tout chef de projet , responsable Qualité, manager de Bureau des Projets, lorsqu’il faut choisir le ou les cadres de référence les plus adaptés aux besoins de leurs projets. Pourtant, les normes et référentiels peuvent vous faire gagner un temps précieux et améliorer l’efficacité de vos équipes projets, que vous disposiez ou non d’un référentiel de management de projet interne à votre organisme.

Au cours de ce séminaire vous pourrez faire le point sur les normes et référentiels existants, leurs spécificités, complémentarités…et leur probable évolution.

Avec : Martine MINY, Présidente AFITEP, Présidente de la Commission AFNOR « Management de projet » d’octobre 2000 à juin 2012
et Hervé COURTOT, Vice-Président AFITEP en charge des référentiels, Président de la Commission Terminologie

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

19 nov

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

26 sept

"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

21 août

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

23 juil

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

les coûts intangibles de la (non) qualité dans les projets

20 juin

The Intangible Costs of Quality

http://www.pmhut.com/the-intangible-costs-of-quality par Michael Donahoe

"Personne ne s’efforce de faire un mauvais travail. Parfois nous le faisons."

Il y a beaucoup de façons de mesurer le coût de qualité sur vos projets. Il y a les coûts de conformité, soit Coûts préventifs et Coûts d’évaluation. Il y a aussi les mieux connus Les coûts de non-conformité qui se répartissent entre Coûts d’échec internes et Coûts d’échec externes. Tous ces coûts ont très bien été étudiés et il y a beaucoup de livres les concernant. Je voudrais les passer en revue et en vous donnant un éclairage sur une valeur cachée que j’appelle Les coûts intangibles de la qualité.

D’abord discutons le coût de conformité : coûts préventifs et coûts d’évaluation.

Coûts de prévention

risk managementCeux-ci sont des coûts encourus lors des actions de formation, des évaluations de risques et la création de contrôles des systèmes et processus. Ces actions supporte le mantra de la qualité, "Faites le bien dès la première fois et vous n’aurez pas y revenir."

Tout sur les coûts de prévention est relativement intangible à un certain degré. Essentiellement, vous devinez, surtout en faisant des suppositions bien informées, sur comment éviter de faire une erreur. Nous regrettons tous de ne pas avoir de boule de cristal pour prévoir à l’avance les problèmes du projet, mais malheureusement elle n’existe pas.

L’intangible coté prévention est que quoi que ce soit que vous fassiez ici entre dans les frais généraux et faire des suppositions mal informées peut être très coûteux. La meilleure méthode est d’avoir un bon retour d’information en provenance de vos systèmes d’évaluation.

Coûts d’évaluation

inspecter les livrablesC’est principalement le surveiller et contrôler de votre projet. Les coûts d’évaluation sont ces coûts relevant des inspections de projet (comme les vérifications sur le produit et/ou le travail effectué). Ils représentent essentiellement le coût de votre service qualité (l’analyse exécutée pour déterminer si la qualité est réalisée et suivie).

Le coût intangible est ici quand une société devient intelligente sur les centimes et stupide sur les euros par une sur-analyse dans laquelle elle dépense beaucoup trop sur la collecte de données plutôt que mettre place des actions de prévention. La meilleure méthode ici pour les organisations est d’appliquer des méthodes d’échantillonnage afin de découvrir si l’analyse exécutée vaut le temps et les coûts impliqués. Le coût d’évaluation ne devrait jamais dépasser celui des coûts de non-conformité ou des échecs.

Les coûts de non-conformité sont composés tant des coûts d’échec internes, que des coûts d’échec externes.

Coûts d’échec internes

Ils sont typiquement causés par des échecs dans votre processus. Jeter par exemple du matériel pour avoir trop commandé. Refaire une chose déjà faite est ici le grand coupable. Si vous devez refaire quelque chose pour respecter le contenu attendu par le client alors c’est un échec.

Comme je l’ai dit que ceci est l’un des coupables les plus connus des personnes réalisant l’étape de mise en œuvre de tout projet. Je suggérerais que dans la plupart des cas, ce n’est pas en raison des individus exécutant la mise en œuvre au plus bas niveau, mais en raison d’une des choses suivantes : une faible communication, de pauvres spécifications sur que les besoins à satisfaire, un problème de temps ou de budget (qui est souvent le coupable pour la pauvre spécification), ou une prévention inadéquate (la formation, le processus, Etc.). L’intangible est ici que ceux-ci démoralisent les personnes impliquées dans le déploiement de vos projets, s’ensuit un jeu de recherche de qui blâmer, les boîtes de courrier électronique explosent soudainement, des silos départementaux se crééent diminuant les communications, les données pour la prévention et l’évaluation deviennent difficiles à acquérir et une ambiance défavorable est créée, tout ceci accroissant de plus en plus les frais généraux.

La réponse facile est ici de passer du temps en amont sur l’étape de prévention. Mais comme mentionné précédemment, il n’est pas toujours possible de capturer toutes les  éventualités. La clé est de  garder une vue d’ensemble du projet. Comprenez qu’il y a un effet boule de neige et faites fondre cette boule de neige pour atteindre la réelle cause racine. Des outils comme les 5 why’s, les leçons apprises et appliquez ceux-ci à votre prévention pour une meilleure analyse de la globalité afin que vos "suppositions" soient plus précises. Faire cela va automatiquement empêcher des Coûts d’Échec Internes.

Coûts d’échec externes

Ils font plus qu’affecter votre résultat final. Ils amenuisent votre réputation en tant que société, probablement même en tant que personne. Ce sont les défauts qui ont un impact sur le résultat final et vous parviennent de vos clients comme des réclamations. Rappels, Garanties, Mauvais Résultats d’Enquêtes de satisfaction, Etc.

L’intangible est voici la perte potentielle d’opportunités futures d’être retenus en raison de piètre qualité. Ces sortes de coûts n’apparaissent pas sur votre bilan financier, mais ils ont un impact certain sur votre déclaration de revenus.

La meilleure méthode est ici, bien sûr, la prévention pour les empêcher de survenir. Évaluation : s’assurer que ces problèmes n’atteignent pas votre client. Réduisez vos échecs internes afin d’ils ne se transforment pas en échecs externes. L’objectif principal cependant, si vous rencontrez vraiment un échec externe est d’agir vite. J’ai lu un livre une fois qui disait que résoudre un problème pour un client est la meilleure méthode de réaliser un bon service clients et de fidéliser ce client. Il semble étrange que cela soit possible à partir d’une erreur, mais c’est en réalité grâce à la communication directe avec ce client. Cet avantage se réduit avec sa fréquence, trop d’erreurs et cette opportunité est perdue.

Pour conclure

plan do check act

Relisez l’article de Jean-Baptiste Jourdant : cultivez vos talents – Projet et qualité, de nombreux points communs !

Nous avons discuté des coûts de conformité, de prévention et d’évaluation et des coûts de non-conformité, internes et externes ainsi que les coûts intangibles qui se produisent avec chacun. Les coûts intangibles pour la conformité sont causés par trop de sur-analyse, de sur-échantillonnage, aussi bien que l’échantillonnage sans données appropriées (sous-analyse). Le but est de considérer les coûts de réduction d’erreurs en rapport des coûts en temps et ressources pour empêcher ces erreurs. Les coûts intangibles de non-conformité diminuent la valeur de votre société à travers une mauvaise réputation, un personnel démoralisé et une diminution massive d’efficacité. Le remède est ici la prévention et l’évaluation intelligentes en considérant la vue d’ensemble et en faisant une analyse en profondeur des causes premières pour prévenir les futurs problèmes. Ceci est réalisé par une bonne communication et un bon contrôle de processus.

CSP Formation

Partenaire de DantotsuPM

9 Mars – Toulouse – ISO 26000, l’impact de la responsabilité sociétale d’entreprise (RSE) sur le management de projet

10 fév

« ISO 26000, l’impact de la responsabilité sociétale (RSE) sur le management de projet »

Ce cercle de discussion gratuit est réservé aux membres du Chapitre PMI France-sud sur inscription obligatoire dans la limite des places disponibles. Il sera présenté par monsieur Patrice Garcia, Délégué régional Midi-Pyrénées du Groupe AFNOR.

Cet évènement permettra aux certifiés PMP® (qui auront signé la feuille de présence) d’obtenir 2 PDUs

PMO unipersonnel

17 oct

One Person PMO

http://www.pmhut.com/one-person-pmo

Par J. Alex Sherrer

Un Project Management Office (PMO) peut être une source de valeur pour les chefs de projet parce qu’il fournit la direction, la formation, la connaissance, les bonnes pratiques, la priorisation des projets et les processus organisationnels. Bien que de plus en plus de sociétés créent des bureaux de management de projet, les petites et moyennes organisations n’ont pas de PMO.

Mais cela ne signifie pas que nous ne pouvons pas nous transformer en PMO d’une personne. Par petites étapes incrémentales nous pouvons poser les bases de bonnes pratiques dans notre société qui aideront non seulement notre organisation, mais aussi nous-mêmes, en développant des documents de management de projet, des procédures et des pratiques cohérentes. Et il ne doit pas nécessairement prendre beaucoup de temps ou être créé d’un seul coup. Nous pouvons commencer avec les secteurs les plus important dans notre environnement – la clé est juste de commencer et de s’y tenir en réalisant des progrès et des améliorations cohérents.

  1. Bibliothèque d’information : Une bibliothèque pour les fichiers de projet, les modèles et les outils pédagogiques est la nécessaire première étape. Des bonnes pratiques de gestion de l’information sont essentielles parce que si nos documents ne peuvent pas être facilement localisés ou devenir périmés, nos futurs efforts de PMO  seront vains. Une information, indépendamment de sa valeur, qui ne peut pas être trouvée ne vaut pas plus que de n’avoir aucune information du tout.
  2. Modèles de documents de projet : Des modèles de documents de projet peuvent aider à faire gagner du temps et à s’assurer que nous n’oublions pas de choses importantes, mais ils peuvent aussi servir d’outils d’apprentissage pour d’autres qui peuvent avoir seulement de temps en temps à manager des projets. Nous risquons fortement de nous décourager si nous essayons de réaliser trop de modèles immédiatement, donc commençons par les documents les plus cruciaux, en les gardant aussi simples et flexibles que possible. Beaucoup de sites internet de management de projet offrent des modèles de démarrage que nous pouvons personnaliser pour nos propres besoins. De bons candidats pour de premiers modèles sont la charte de projet, la matrice des parties prenantes, le registre des risques, les RACI, le journal des problèmes, le journal des changements et la matrice de traçabilité des besoins.
  3. Processus de leçons apprises : Les leçons apprises font partie intégrales de l’amélioration continue et nous sommes destinés à faire les mêmes erreurs à plusieurs reprises si nous n’apprenons jamais d’elles. Donc nous devrions enraciner le processus des leçons apprises dans tout effort et cela devrait être une partie visible de l’initiation, l’exécution et la clôture de projet.
  4. Processus de clôture de projet : Avec notre bibliothèque en place et le processus des leçons apprises, nous voudrons nous assurer que nous incorporons ces artefacts de projet dans nos étapes de clôture administrative de projet. Chacun, nous compris, tient toujours à passer au projet suivant quand l’un est fini, mais sans vérification, catalogage et classement des informations projet, nos bibliothèques de projet sont incomplètes.
  5. Formation : Webinars et des séminaires sont une excellente façon d’impliquer d’autres personne dans l’apprentissage du management de projet sans les y forçer. Nous pouvons aussi utiliser des discussions autour de l’amélioration des modèles que nous avons créés jusqu’à présent comme des opportunités d’apprendre.
  6. Ventura

    Partenaire de DantotsuPM - Cliquez sur ce logo pour contacter Ventura pour vos besoins en Management de Projet et PMO

  7. Plans subsidiaires : Particulièrement sur des projets grands et complexes, le besoin de modèles pour les plans subsidiaires deviendra vite apparent. Ceux-ci sont les plans de collecte des besoins, de contenu, d’échéancier, de qualité, de management des ressources humaines, de communication et  de management des risques. La nécessité de ces plans peut parfois être dure à comprendre pour des non chefs de projet, donc nous devrions attendre le bon projet pour "dévoiler" ces modèles avec parcimonie afin que leur utilité soit évidente à ceux impliqués dans le projet.
  8. Système de contrôle des changements / système de management de configuration : Un modèle documenté, flexible, standardisé de contrôle des changements du projet sera un outil puissant. Le niveau de rigueur nécessaire pour ce contrôle varie largement d’un projet à l’autre, donc il peut être difficile de créer un guide généralisé.
  9. ROI : Pour beaucoup de nos projets, le processus de sélection est informel ou se produit à l’extérieur de notre périmètre de responsabilités. Cependant, sans métrique explicite de l’impact du livrable, service ou résultat final de notre projet, nous ne pouvons jamais exécuter de revues après-projet objectives. Donc une des bonnes pratiques que nous pouvons établir est de travailler avec le sponsor ou d’autres personnes dans notre organisation pour déterminer cette métrique et la revisiter ensuite après la clôture du projet pour mesurer l’impact.
Suivre

Recevez les nouvelles publications par mail.

Joignez-vous à 386 followers

%d bloggers like this: