15 avantages que vous apporte le management de projet (7 à 9)

Le management de projet offre de considérables avantages et bénéfices aux organisations qui ont besoin de livrer des solutions.

Benefits of Project Management par Leigh Espy

#7 – Gestion de la portée du projet

Bien qu’il soit important d’avoir une portée de projet clairement définie au début du projet, il est tout aussi important de gérer les dérives de la portée au fur et à mesure que le projet progresse.

Les clients demandent souvent des changements de contenu.

Le/la manager de projet peut aider à montrer comment cela affecte le projet. Si des changements de portée sont effectivement nécessaires, le/la manager de projet peut gérer les impacts sur le planning et le budget du projet.

#8 – Management des risques

Le management des risques comprend l’identification des risques dès le début du processus et leur traitement avant qu’ils ne causent des problèmes. Cela implique également de gérer le changement tout au long du projet en suivant les changements et en les communiquant efficacement.

Le/la manager de projet identifie les risques potentiels au début du projet. Il/Elle travaille avec l’équipe pour manager activement les risques tout au long de la vie du projet.

Grâce à cela, le projet peut aller de l’avant même s’il y a des menaces sur le plan de projet.

Ressource : Comment créer une matrice de management des risques projet (avec modèle)

#9 – Qualité de la solution

Le/la manager de projet travaille avec l’équipe pour intégrer la qualité dans le projet dès le début.

Il/Elle projet s’assure que l’équipe suit les processus appropriés, tels que la collecte des exigences et les tests, le cas échéant. L’équipe peut avoir besoin de suivre les directives de conformité ou les considérations contractuelles. Tout au long de la vie du projet, le/la manager de projet coordonne de multiples activités pour aborder la qualité

 

Etes-vous un ingénieur QA, ingénieur QC ou testeur de logiciel ? pa Fidaa Berrjeb

Les gens pensent souvent que l’assurance qualité et le contrôle qualité sont identiques.

De plus, ils utilisent souvent l’expression Quality Assurance (QA) pour désigner les tests, mais ce n’est pas exact. Ces expressions sont liées, et il est peut être très déroutant d’essayer de clairement différencier l’assurance qualité (QA), le contrôle de la qualité (QC) et les tests et d’identifier chacune de leurs activités.

Même les gens de ce domaine s’interrogent parfois sur leur intitulé de poste : « Suis-je un testeur de logiciels, un ingénieur QA ou un ingénieur QC ? »

Dans cet article, nous définirons chaque terme et la différence entre eux, et à la fin de celui-ci, vous pourrez aisément répondre à cette question.

Avant de définir ces termes, convenons de la définition de la qualité.

D’après wikipédia :

Au sens large, la qualité est la « manière d’être », bonne ou mauvaise, d’une chose ou d’une personne. Dans le langage courant, la qualité tend à désigner ce qui rend quelque chose supérieur à la moyenne.

Le QA , le QC et les tests sont liés dans un concept plus large appelé gestion de la qualité.

La gestion de la qualité comprend toutes les activités qui dirigent et contrôlent une organisation en matière de qualité. Entre autres activités, la gestion de la qualité comprend à la fois l’assurance de la qualité et le contrôle de la qualité ISTQB CFTL.

  • L’assurance qualité englobe toutes les activités de votre stratégie visant à garantir que les exigences de qualité que vous avez planifiées seront satisfaites au fur et à mesure de la fabrication du produit. Elle intervient à chaque étape du développement logiciel, de la création du cahier des charges à la sortie du produit. L’assurance qualité est la méthode orientée processus et se concentre sur la prévention des défauts.

 

  • Le contrôle de la qualité est la phase d’inspection de l’assurance qualité. Dans le processus de développement logiciel, le QC intervient généralement à la dernière étape. Cela commence une fois qu’un produit est déjà construit. Il s’agit d’une série de procédures de test utilisées pour vérifier qu’un produit est sûr et efficace après la production de masse. C’est une méthode orientée produit qui garantit que le résultat final est le résultat attendu ou que le produit final fonctionne comme prévu.

 

  • Les tests sont un sous-ensemble du QC. C’est l’activité de détection et de résolution des problèmes techniques dans le logiciel. C’est le processus d’examen du logiciel pour détecter d’éventuelles failles. L’idée de base consiste à exécuter le programme ou le logiciel et à observer le comportement ou le résultat. Il peut fournir un niveau de confiance quant à la convivialité, les performances, la sécurité et la compatibilité du produit.

 

Expression Assurance qualité (QA) Contrôle de la qualité (QC) Test
Positionnement Sous-ensemble de SDLC Sous-ensemble de QA Sous-ensemble de QC
Orientation Processus Produit Produit
Qui ? L’équipe projet L’équipe de test L’équipe de test
Quand ? Tout au long du projet Au stade du test Au stade du test
Type de

Processus

Prévention Vérification Détection
Partenaire de DantotsuPM, visitez le site pour toutes les formations certifiantes proposées

Voici déjà le cinquième billet de Fidaa sur le domaine des tests.

(Re)Découvrez ses 4 premiers billets
Fidaa Berrjeb est Agile QA analyst certifiée ISTQB et Scrum Master.
  1. « La bonne compréhension et l’utilisation des valeurs du manifeste agile et du manifeste du test vous garantit être un bon testeur agile »
  2. Si on vous demandait d’écrire un scénario de test, sauriez-vous quoi faire ?
  3. Le rôle et les compétences d’un testeur dans une équipe agile
  4. Quelle est la différence entre un plan de test et une stratégie de test ?

 

Quelle est la différence entre un plan de test et une stratégie de test ? Quand utiliser l’un ou l’autre ? par Fidaa Berrjeb

Voici déjà le quatrième billet de Fidaa pour vous aider à mieux différencier stratégie et plan de test et quand les utiliser.

Redécouvrez les 3 premiers billets Fidaa Berrjeb :
Fidaa Berrjeb est Agile QA analyst certifiée ISTQB et Scrum Master.
  1. « La bonne compréhension et l’utilisation des valeurs du manifeste agile et du manifeste du test vous garantit être un bon testeur agile »
  2. Si on vous demandait d’écrire un scénario de test, sauriez-vous quoi faire ?
  3. Le rôle et les compétences d’un testeur dans une équipe agile

En ce qui concerne les tests de logiciels, deux termes importants entrent en jeu. Ce sont « Plan de test » et « Stratégie de test ».

Bien que les deux soient des éléments essentiels du processus de QA, ces termes risquent souvent être mal interprétés et utilisés de manière interchangeable.

Alors, quelle est la différence entre un plan de test et une stratégie de test ? Quand devez-vous utiliser un plan et quand est-il préférable d’utiliser une stratégie ?

Plan de test

Un plan de test est un document formel dérivé des documents d’exigences.

  • Ce document décrit les différentes actions qui seront effectuées dans le processus de test.
  • Il définit l’approche, l’estimation, les attentes, les actifs et le calendrier des activités de test planifiées.
  • Il identifie la portée et l’objectif du processus de test logiciel, les différentes fonctionnalités qui doivent être testées, les techniques utilisées pour concevoir les tests et bien plus encore.

Fondamentalement, il enregistre l’ensemble du processus de planification des tests à effectuer sur le produit.

Stratégie de test

Une stratégie de test est un document de haut niveau décrivant la manière dont les tests seront effectués dans une organisation.

  • Elle contient un ensemble d’instructions, de lignes directrices ou de principes qui déterminent la conception du test et la manière dont le processus de test sera effectué.
  • Elle vise essentiellement à fournir une approche systématique du processus de test de logiciels afin d’assurer la qualité, la traçabilité, la fiabilité et une meilleure planification.

Les documents tels que les plans de test tirent leur contenu du document de stratégie de test.

Différence entre plan de test et stratégie de test

Une stratégie de test définit la norme générale pour les activités de test. Un plan de test, d’autre part, définit les détails spécifiques des responsabilités et du processus de QA.

5 façons d’améliorer la qualité des projets

Une grande partie de la réussite d’un projet consiste à atteindre les objectifs business. La qualité d’un projet est la mesure du degré avec lequel un projet atteint ses objectifs.

5 Ways to Increase Project Quality

http://www.bonniebiafore.com/5-ways-to-increase-project-quality/ par Bonnie Biafore

Voici cinq conseils pour assurer la qualité des résultats de votre projet.

#1 – Ne sautez pas à la solution trop rapidement.

La base de la qualité est de s’assurer que votre projet résout le problème ou soutient l’opportunité ciblée. Pour vous assurer de fournir une solution de qualité, prenez le temps de rechercher les outils, les processus, les forces et les faiblesses actuels dans votre secteur d’activité.

Malheureusement, les projets sont souvent lancés avec une solution spécifique à l’esprit. Par exemple, si votre organisation exécute un projet de mise en œuvre d’un nouveau logiciel financier alors que le manque de contrôle financier est dû à de mauvais processus de contrôle, le projet est une perte de temps et d’argent. Faites vos recherches pour identifier le problème et sa cause racine avant de lancer un projet.

#2 – Renforcez l’engagement client dès le début du projet.

Ecoutez les clients

Vous avez besoin de l’apport des bonnes personnes pour fournir une solution qui répond aux besoins des parties prenantes. Il vous faut non seulement des personnes bien informées mais aussi des personnes de chaque groupe de parties prenantes concerné.

Consultez ces personnes lorsque vous rassemblez les exigences et ne supposez pas que vous comprenez les besoins des parties prenantes. Sinon, les livrables de votre projet pourraient rester inutilisés si les parties prenantes insatisfaites les déclarent inadaptés pour l’entreprise.

#3 – Ne court-circuitez pas les tests.

Les tests sont souvent planifiés à la fin du projet. À mesure que les dates cibles approchent, les tests sont souvent réduits pour tenir les calendriers de livraison.

Bien que cette approche puisse livrer dans les temps, la probabilité de problèmes avec les livrables est élevée. Pour garantir des résultats de projet de qualité, sacralisez le temps de test et incorporez les activités de test tout au long du cycle de vie de votre projet.

Relisez ce billet

Par exemple, des revues de livrables papier, de modèles d’ingénierie, de simulations de procédures commerciales et de prototypes de logiciels vous permettront d’économiser du temps et de l’argent dans le long terme.

#4 – Concentrez-vous sur les processus business.

Deux activités liées aux processus sont cruciales, mais souvent négligées.

Tout d’abord, assurez-vous de capturer les processus actuels afin que votre projet ne néglige pas les activités business qu’il doit prendre en charge.  Deuxièmement, mettre à jour les processus opérationnels à mesure que les livrables sont créés et que les modifications sont prises en compte.

Si vous ne le faites pas, la formation du personnel ne couvrira pas les changements apportés, ce qui pourrait entraîner des malentendus sur ce que votre produit peut et ne peut pas faire. Pour obtenir des résultats opérationnels, mettez en œuvre des activités de projet standard pour capturer et documenter les processus opérationnels tels qu’ils existent au départ et ceux à venir.

Au fur et à mesure que l’équipe produit des livrables, elle doit également créer et documenter les processus métier nouveaux ou modifiés correspondants.

#5 – Tenez compte des facteurs humains.

Les gens ne résistent pas au changement. Ils résistent à être changés. Peter M. Senge

La qualité perçue de vos livrables dépend de votre capacité à accompagner vos parties prenantes dans le voyage du changement de votre projet. Impliquez vos parties prenantes dès le début, tenez-les informées au fur et à mesure que vous progressez, en particulier lorsque des changements sont réalisés.

Ce faisant, vous augmenterez vos chances que vos résultats satisfassent les objectifs de l’entreprise.

Pour en savoir plus sur la qualité des projets, consultez le cours Project Management Foundations: Quality de Daniel Stanton.
QRP est partenaire de DantotsuPM, visitez cette page pour en apprendre davantage

De l’importance de ne jamais confondre investissement et dépense !

L’un prend de la valeur, l’autre non. L’un crée de la valeur au fil du temps, l’autre non.

Investments and expenses

https://seths.blog/2021/04/investments-and-expenses/ par Seth Godin

L’un prend de la valeur, l’autre non. L’un crée de la valeur au fil du temps, l’autre non.

Il est amusant d’imaginer que nos dépenses sont des investissements, mais si c’était le cas, nous les appellerions des investissements.

Nos outils peuvent être réutilisés, et nos biens ont de la valeur pour nous et pour les autres. Les compétences peuvent être un investissement, qui prend de la valeur quand elles augmentent. Les dépenses, en revanche, perdent de la valeur.


Il en va de même dans votre projet si vous êtes manager ou sponsor de projet ou membre de l’équipe projet.

Certains coûts sont pleinement justifiés et contribuent à construire un livrable de grande valeur pour votre organisation et vos clients. D’autres tout aussi justifiés permettent de faire grandir les personnes qui travaillent sur le projet, de leur donner les moyens d’évoluer et devenir meilleurs.

D’autres coûts sont bien moins justifiables comme de devoir refaire une tâche parce qu’elle a été mal exécutée la première fois. Il faut alors parfois beaucoup dépenser pour déconstruire avant de reconstruire. Cela coûte en argent mais aussi en confiance chez vos commanditaires et parties prenantes.

Parfois des fonctionnalités que vous avez développé avec l’équipe à grands frais seront inutilisées… d’où les approches hybrides qui essaient de prendre le meilleur de l’agilité en particulier pour ce qui est de développer les éléments de plus grande valeur pour les clients en premier.

Le rôle et les compétences d’un testeur dans une équipe agile par Fidaa Berrjeb

Voici le troisième billet de Fidaa pour préciser le rôle du testeur dans les projets Agiles.

Les 2 premiers billets Fidaa Berrjeb que vous souhaiterez peut-être relire :
  1. Fidaa Berrjeb est Agile QA analyst certifiée ISTQB et Scrum Master.

    « La bonne compréhension et l’utilisation des valeurs du manifeste agile et du manifeste du test vous garantit être un bon testeur agile »

  2. Si on vous demandait d’écrire un scénario de test, sauriez-vous quoi faire ?

Contrairement aux méthodes de gestion de projet traditionnelles, le rôle de testeur dans les projets Agiles dépasse être  simplement un exécuteur. Il comprend des activités qui génèrent et fournissent des retours (feedback) non seulement sur l’état du test, la progression du test et la qualité du produit, mais également sur la qualité du processus en collaborant de façon rapprochée avec toute l’équipe et ses parties prenantes.

En plus de compétences techniques reconnues (les tests d’acceptation, boîte blanche, boîte noire, les automatisations de test …), un testeur agile doit avoir de bonnes compétences interpersonnelles.

CSP est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.

Ayez une attitude constructive et une approche communicative

Une grande partie des problèmes se résument  à un manque de communication. En tant que testeur, impliqué du concept au produit final, il est important de communiquer de manière ouverte et honnête. Il est également important de considérer la façon dont nous disons les choses. Il est préférable de dire  « Je ne pense pas que cela fonctionne comme il se doit, il manque la fonctionnalité X » au lieu de « Cela ne fonctionne pas ».

Une discussion en face à face est souvent plus efficace.

En outre, il est important de déterminer quand utiliser des outils digitaux pour communiquer ou quand une bonne conversation en face à face est nécessaire.

Coachez les autres membres de l’équipe sur les aspects pertinents du test .

En partageant les connaissances de test avec l’équipe, vous leur montrez que, non seulement vous êtes un apprenant passionné, mais vous voulez les aider à apprendre et à améliorer le travail de l’équipe.

L’objectif d’un testeur n’est pas de trouver plus de bugs mais de construire un produit de valeur et de qualité.

Collaborez avec les développeurs,  le Product Owner et  les stakeholders  pour clarifier les exigences, spécialement en termes de testabilité, consistance et complétude.

Le travail d’équipe rend les choses meilleures. Pour les testeurs de logiciels, travailler seul peut devenir la situation par défaut même si vous faites partie d’une équipe. N’oubliez pas que vous n’êtes jamais seul sur un projet.

Les testeurs doivent être impliqués dans les sessions de Pré-planification et de  user stories  grooming (analyse détaillée des besoins des utilisateurs) en ajoutant de la valeur lors de la :

  • Définition des user stories et des critères d’acceptation
  • Participation aux analyses de risques et de qualité de projet
  • Création de tests d’acceptation pour les user stories

Participez pro-activement aux rétrospectives d’équipe, suggérez et implémentez des améliorations .

Soyez impliqué, proactif, coopératif et soyez le membre de l’équipe avec qui vous aimeriez travailler. Soyez un modèle de bon membre d’équipe et, espérons-le, les membres de votre équipe le reconnaîtront et travailleront ensemble, avec vous, pour développer des pratiques de travail d’équipe.

Les testeurs Agile doivent ajouter de la valeur à chaque étape de la livraison du logiciel dans un projet agile.

Reportez les défauts et travaillez avec l’équipe pour les résoudre.

Au sein d’une équipe Agile, chaque membre de l’équipe est responsable de la qualité du produit et joue un rôle dans l’exécution des tâches liées aux tests. Le retour d’information dès que possible vers l’équipe en cas de problème économise  temps et budget.

Si on vous demandait d’écrire un scénario de test, sauriez-vous quoi faire ? par Fidaa Berrjeb

Suite à son premier billet sur ce blog « La bonne compréhension et l’utilisation des valeurs du manifeste agile et du manifeste du test vous garantit être un bon testeur agile » Fidaa Berrjeb a reçu des questions sur « le test scénario et le test case ».

  • Si on vous demandait d’écrire un scénario de test, sauriez-vous quoi faire ?
  • Qu’en est-il d’un cas de test ou d’un scénario de test ?
Fidaa Berrjeb est Agile QA analyst certifiée ISTQB et Scrum Master.

La première étape consiste à bien définir ces termes.

Chacun de ces termes implique un niveau de détail différent.

Une fois qu’un testeur sait ce que chacun de ces termes signifie, il peut comprendre comment les utiliser pour décrire le travail de test qui est effectué quotidiennement.

C’est quoi un scénario de test ?

Un scénario de test est essentiellement une documentation d’un cas d’utilisation. En d’autres termes, il décrit la fonctionnalité de l’application à tester. Il est utilisé pour tester de bout en bout une fonctionnalité.

Un même scénario de test nécessitera un ou plusieurs cas de test pour s’assurer que le scénario a été couvert de manière satisfaisante. Par conséquent, un scénario de test a une relation un-à-plusieurs avec les cas de test.

À titre d’exemple, considérons un scénario de test

« Vérifiez que l’utilisateur ne peut pas se connecter avec des informations d’identification incorrectes »

Maintenant, ce scénario de test peut être encore décomposé en plusieurs cas de test comme :

  1. Vérifier qu’un utilisateur avec le bon nom d’utilisateur et le mauvais mot de passe ne soit pas autorisé à se connecter.
  2. Vérifier qu’un utilisateur avec un nom d’utilisateur incorrect et un mot de passe correct ne soit pas autorisé à se connecter.
  3. Vérifier que les utilisateurs avec des noms d’utilisateur et des mots de passe incorrects ne soient pas autorisés à se connecter.

Qu’est-ce qu’un cas de test ?

Le cas de test est un ensemble d’actions exécutées pour vérifier une caractéristique ou une fonctionnalité particulière de votre application logicielle.

Il inclut toutes les entrées possibles positives comme négatives, ainsi que des données de test, des préconditions et des postconditions développées pour un scénario de test spécifique afin de vérifier toute exigence.

À l’aide de ces variables et conditions, le testeur peut comparer les résultats réels aux résultats attendus pour déterminer si un produit logiciel fonctionne conformément aux exigences du client.

Scénario de test VS cas de test

QRP est partenaire de DantotsuPM, visitez leur site et leur blog

 

plan do check act

Rappel de ce qu’est le « Plan Do Check Act », Cycle PDCA pour l’amélioration continue.

Le Cycle PDCA est une approche compréhensible, répétable pour travailler vers une amélioration continue.

PDCA Cycle for Continuous Improvement

https://projectbliss.net/plan-do-check-act-pdca-cycle/ par  Leigh Espy
plan do check act
Relisez l’article de Jean-Baptiste Jourdant : cultivez vos talents – Projet et qualité, de nombreux points communs !

Les équipes et des organisations s’efforcent constamment de trouver les meilleures façons de travailler. Bien des organisations doivent faire plus avec moins, moins de personnes ou moins d’argent. Et les organisations veulent toujours trouver des façons d’économiser de l’argent, de gagner en efficacité et rendre l’environnement de travail meilleur. Mais souvent la demande par la gestion pour faire ainsi peut sembler accablante.

Mais si vous saviez qu’il existe une approche structurée pour essayer des améliorations possibles, obtenir des retours rapidement et le faire d’une façon qui vous permette d’apprendre dans un environnement contrôlé et de construire sur vos succès, vous seriez probablement intéressés, non ?

Et bien cette approche existe ! Et c’est quelque chose que vous pouvez facilement apprendre et enseigner à votre entourage.

Faites un pas de plus et donnez-lui une chance. Et si vous trouvez une façon d’économiser à votre société de l’argent ou du temps, vous pourriez bien en obtenir un agréable bonus!

Plan Do Check Act – Cycle PDCA

Le Plan Do Check Act – Cycle PDCA est une méthode en 4 étapes utilisée dans le processus d’amélioration continue.

Le livre de Deming sur Amazon

PDCA est aussi connu sous le nom de Cycle de Deming. Dans les années 1920, Walter Shewhart a créé le concept Plan – Do – See (Planifier – Faire – Observer) connu comme le Cycle Shewhart. Edwards Deming l’a ensuite adapté. Une autre variation que vous pouvez rencontrer est le Cycle PDSA : Plan-Do-Study-Act, Planifier-Faire-Etudier-Agir

Mais ils mènent tous à la même chose…

Toutes ces approches s’est concentré sur l’amélioration continue. Et chacun des quatre composants joue un rôle spécifique dans ce processus d’amélioration continue.

Le Plan Do Check Act – Cycle PDCA est une méthode à 4 étapes fréquemment utilisée dans le processus d’amélioration continue. Chacun des quatre composants joue un rôle spécifique dans ce processus d’amélioration continue.

Plan – Préparer, Planifier

Relisez ce billet: Diagramme D’Ishikawa (Fishbone) pour aller chercher la source des problèmes.

En déterminant comment réaliser des améliorations, il est important de comprendre le problème. Vous ne pouvez pas mettre en œuvre des activités d’amélioration si vous ne comprenez pas d’abord le problème. Vous devez comprendre la cause première, dite cause racine, ses impacts et toute autre information appropriée sur le problème.

C’est ce que vous faites pendant cette phase de préparation.

Une fois que vous avez une meilleure compréhension du problème, vous développez alors un plan pour développer des améliorations.

Pour obtenir une approche plus normative de ces activités, les étapes 1 à 5 du papier 7 Problem-Solving approach  peuvent vous être utiles. Elles vous montrent pas à pas comment vous assurer que vous avez une pleine compréhension de la situation, définissez le problème correctement et choisissez la meilleure solution pour la situation. Vous développerez alors un plan pour développer la solution.

Une partie de la planification est comprendre votre ligne de base de départ et savoir quelle métrique utiliser pour mesurer vos progrès. C’est la seule façon pour vous de savoir si vous avez fait des améliorations adéquates.

Avant de passer à l’exécution de votre plan, identifiez clairement à quoi ressemblera le succès et comment vous saurez si votre approche était réussie. Vous devez être capables d’identifier des résultats quantitatifs ou qualitatifs pour savoir si vous avez été gagnants.

Do – Développer, réaliser, mettre en œuvre

Jusqu’ici, vous et votre équipe avez acquis une bonne compréhension du problème et vous avez développé un plan pour l’adresser.

Vous savez quelles sont vos bases de départ et ce que signifie la réussite. 

Maintenant vous exécutez votre plan. Vous pouvez le faire de deux manières différentes.

  • Vous pouvez mettre en œuvre votre plan sur un pilote, testant les réalisations avec un petit groupe avant de dérouler le plan pour tous.
  • Ou vous pouvez exécuter votre plan avec un plus grand groupe, mais vous assurer que le test est contrôlé.

Que vous choisissiez l’une ou l’autre de ces approches, mettez en œuvre les activités que vous avez identifiées pour atteindre des améliorations.

Check – Contrôler, vérifier

Après un délai prédéterminé, mesurez les résultats des changements effectués. Validez si les changements atteignent vos attentes.

Vérifiez par rapport aux mesures de vos lignes de base du départ. Utilisez la métrique que vous avez identifiée avant le lancement.

Vous voulez voir si votre plan a fonctionné et si vous avez obtenu des résultats positifs.

Vous identifierez aussi où vous pouvez encore améliorer le plan. Vous pouvez devoir tordre certaines choses ou modifier le plan en vous vasant sur ce que vous avez appris.

Vérifiez des résultats par rapport à votre ligne de base et voyez si votre plan a marché comme prévu. Vous pouvez vous devoir l’adapter. C’est un cycle apprenant.

Act (ou Adjust) – Agir, ajuster, réagir

Maintenant que vous savez si vos actions ont apporté une amélioration ou pas, exécutez les étapes suivantes appropriées.

Amélioration continue…

Si vous avez mis en œuvre votre amélioration sur un petit groupe pilote avec des résultats positifs, vous pouvez être prêts à lancer les changements sur un plus grand groupe.

Si vous avez exécuté ces changements sur le plus grand environnement et que tout est bon, vous standardiserez alors les changements pour qu’ils deviennent les nouveaux normaux dans l’environnement.

Alternativement, si les changements réalisés n’ont pas fourni les résultats attendus, ajustez le plan.

Et même si vous avez obtenu des améliorations, vous pouvez trouver en avançant que de nouvelles améliorations sont nécessaires. Dans ce cas vous pouvez répéter le cycle.

C’est l’objectif de l’amélioration continue.

Repeat – Répéter

Le Cycle PDCA n’est pas une activité isolée. Les équipes exécutent le cycle à plusieurs reprises pour continuer à améliorer les processus et construire sur des améliorations précédentes.

Votre équipe et environnement se sont améliorés, mais il y a probablement toujours une marge d’amélioration à exploiter.

De nouvelles connaissances, technologies ou approches peuvent survenir qui pourront aider l’équipe à performer encore mieux.

Ou votre nouvelle ligne de base peut vous donner une compréhension sur la façon de s’améliorer encore de différentes façons.

Ou vous pouvez être si inspirés que vous voulez essayer le cycle PDCA sur un autre processus de votre environnement.

Vous n’êtes pas limités sur combien de fois vous pouvez utiliser le cycle PDCA pour continuer à vous améliorer.

Les bénéfices du Cycle PDCA

Il y a de multiples bénéfices au Cycle PDCA :

Boucle de retours continue

PDCA vous donne une grande boucle de retours du terrain pour apprendre rapidement si votre plan fonctionne ou si vous deviez essayer une approche différente.

Perturbation limitée des processus business.

Vous pouvez essayer des solutions potentielles d’abord à une petite échelle avec un groupe pilote. Cela vous permet d’en apprendre davantage sans perturber l’organisation toute entière.

Gagner l’implication d’autres personnes.

Il faut souvent que beaucoup de membres de votre équipe s’engagent et participent dans la résolution de problèmes. S’ils contribuent à travailler vers des améliorations, cela peut les inspirer et les aider à voir le lieu de travail sous un nouveau jour. Ils peuvent même commencer à contribuer davantage à la résolution de problèmes et à l’amélioration continue.

Créer une culture d’amélioration continue.

Vous pouvez créer une culture d’amélioration continue et construire continuellement sur des succès.

Soyez conscients de ces défis

Ce cycle si simple a de super pouvoirs.

Quand vous utilisez le cycle PDCA, il y a plusieurs considérations à prendre en compte :

  • Il faut du temps. Le Cycle PDCA n’est pas une approche qui peut être utilisée sur des problèmes qui doivent être résolus rapidement.
  • Il faut de la discipline. Pour effectuer le cycle de ces activités, vous devez comprendre votre ligne de base, ce que signifie réussir et comment vous mesurerez ce succès.
  • Il faut un environnement contrôlé. Pour savoir si ce sont bien vos activités qui ont apporté le succès, vous devez être capables de contrôler l’environnement en effectuant votre pilote. Sinon, cela pourrait être simplement une corrélation d’autres événements et pas la cause de la réussite. Si c’est le cas, déployer ces changements à l’organisation toute entière pourrait ne pas avoir les résultats positifs vous attendez.

En bref

Vous voici prêts avec votre organisation à aller décrocher une étoile.

Le Cycle PDCA ne saurait être une réparation rapide, mais sa structure est facile à comprendre et à communiquer. Il peut être utilisé dans beaucoup de situations différentes et vous permettre de créer une véritable culture d’amélioration continue.

Et une fois que vous l’avez utilisé pour faire des changements réussis dans un secteur, vous chercherez probablement autre part où l’appliquer pour encore plus d’améliorations !

Kaizen = amélioration continue

Le livre de Mike Rother Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results

Voici le kata en bref

Livres sur Amazon
  1. Évaluez ce que vous faites et identifiez un but à long terme pour votre amélioration.
  2. Trouvez une étape intermédiaire, quelque chose que vous pouvez réellement accomplir à court terme pour vous déplacer en direction de votre amélioration (pas y parvenir, juste vous déplacer un peu).
  3. Identifiez 3 choses pratiques que vous pouvez faire tout de suite pour atteindre cet emplacement intermédiaire.
  4. Faites-les.
  5. Répéter à tout jamais.

Affichez la liste d’actions concrètes sur un tableau physique et ajoutez une action à chaque fois que vous en retirez une. L’idée est d’entretenir un flux continu de petites améliorations vous déplaçant vers un plus grand objectif.

CSP est partenaire de DantotsuPM

Centre de contrôle : règles 60 à 65 des 100 pour les managers de projet de la NASA: le matériel, les ordinateurs et logiciels

Voici les règles sur le matériel, les ordinateurs et logiciels

Règles précédentes: le rôle du manager de projet, les aspects communications et l’humain, les revues et rapports de projet, les sous-traitants, Ingénieurs et Scientifiques.

Matériel

La règle #60 : Dans le domaine spatial, il n’y a rien de tel que du matériel ayant précédemment volé. Les gens qui construisent l’unité suivante n’ont probablement jamais vu l’unité précédente. Il y a probablement des changements mineurs (peut-être même des changements majeurs); l’environnement opérationnel a probablement changé; les gens qui vérifient l’unité dans la plupart des cas ne comprendront ni l’unité ni l’équipement de test.

La règle #61 : La majorité des équipements fonctionnent comme construits, pas comme le concepteur l’avait prévu. Ceci est dû à la représentation du design, une faible compréhension de la part du designer ou des spécifications des composants.

Ordinateurs et Logiciels

La règle #62 : La non utilisation de techniques modernes, comme des systèmes informatiques, est une grande erreur, mais oublier que l’ordinateur simule la pensée est une erreur encore plus grande.

La règle #63 : Le logiciel a maintenant repris tous les paramètres du matériel (c’est-à-dire, dérive des exigences, fort pourcentage du coût de la mission de vol, besoin de contrôle de qualité, besoin de procédures de validation, etc.). Il a la caractéristique supplémentaire qu’il est difficile de s’assurer qu’il n’est pas bogué. Faites d’abord marcher le système de base et ajoutez ensuite les options. Ne jetez jamais une version qui marche même si vous avez la plus grande confiance au monde que la version plus récente fonctionne. Il est nécessaire d’avoir des plans de contingence pour le logiciel.

La règle #64 : La connaissance est souvent revisitée avec des simulations ou la mise à l’épreuve, mais des modèles informatiques ont des défauts cachés dont le moindre n’est pas de mauvaises données d’entrée.

La règle #65 : Autrefois, les ingénieurs avaient l’expérience du terrain, les techniciens comprenaient comment l’électronique fonctionnait et ce qu’elle pouvait réaliser et les techniciens au sol le savaient aussi, mais aujourd’hui seul l’ordinateur sait à coup sûr et il ne parle pas.

Méta Projets Management est partenaire de DantotsuPM

Liste complète en anglais sur Geekboss par Matthieu Stibbe