View
5.605
Download
4
Category
Preview:
DESCRIPTION
La mise en place d'un projet d'amélioration continue ne garantie pas un succès dans cent pout cent des cas. L'expérience permet aujourd'hui de pouvoir identifier, anticiper et réduire ces risques pour maximiser les chances de succès. Je propose de décrire quelques unes de ces bonnes pratiques afin de justifier et d'illustrer le plan proposé.
Citation preview
Risques liés aux projets d'amélioration
continue… et des solutions
François SALAZAR
Francois.salazar@free.fr
Décembre, 2007
La mise en place d'un projet d'amélioration continue ne garantie pas un succès dans cent pout cent
des cas. L'expérience permet aujourd'hui de pouvoir identifier, anticiper et réduire ces risques pour
maximiser les chances de succès. Je propose de décrire quelques unes de ces bonnes pratiques afin
de justifier et d'illustrer le plan proposé.
Des solutions
Etablir et identifier les motivations
Pourquoi se lance-t-on dans un programme d'amélioration ? Ceci doit être dit, écrit et clairement
communiqué à tous les acteurs de l'organisation. Qu'est ce qui est le plus important ? Qu'est ce qu'y
gagnera l'organisation, qu'y gagneront les employés, les cadres. Il est crucial que ce type de projet
amène les acteurs à adhérer aux initiatives qui suivront.
Avoir une approche progressive et pragmatique
Se lancer dans des démarches d'amélioration requiert des investissements humains, temporels et
financiers. Il est prudent d'avoir une approche graduée afin de pouvoir mesurer régulièrement la
valeur ajoutée des initiatives, visualiser les progrès et créer la motivation pour une nouvelle 'boucle'
d'amélioration. Voici un exemple qui permet d'illustrer ce concept.
Une division d'une grande entreprise désire améliorer la gestion des exigences. A ce jour, les
exigences, quand elles existent, sont gérées dans des fichiers Word, éparpillées sur des disques
réseaux, modifiées et transmises par tout un chacun… Inutile de dire que les projets souffrent de
retards dus aux malentendus et aux conflits entre acteurs…
Deux approches sont possibles:
a) L'approche "Big-bang" consiste à réunir un groupe d'expert pour définir le processus détaillé, les outils et les formations pendant 6 mois, former tous les acteurs pendant 2 mois, acheter des licences d'outils pour 50 000 euros et décider que les procédures et outils sont applicables… Le coût est élevé et la probabilité de succès est extrêmement faible : processus sur-contraints, outil non opérationnel car implémentant un processus idéal, manque d'adaptabilité, incohérences. Dans l'exemple suivant, la direction impose à ses employés d'utiliser le nouveau système et impose aux équipes de transférer manuellement leurs documents dans un outil complexe, mal connu, imparfait alors que personne ne comprend vraiment pourquoi il faut faire cela … Devant les contestations et les retard réels engendrés sur les des projets, la direction annule le projet.
Temps
Capacité à
réaliser un
système ou du
logiciel
Début du
programme
objectif ‘processus perfection’
Phase 1
Définition de la
solution parfaite
Phase 2
Déploiement forcé
‘Choc Thermique’ Retour aux
anciennes
méthodes
Arrêt du projet(retour en arrière)
Figure 1 : Illustration de l'approche Big-bang
b) L'approche itérative consiste à constituer des groupes de travail avec les acteurs de projets (chefs de projets, ingénieurs application, ingénieurs de test ou de qualification, utilisateurs finaux des produits…), guidés par des experts et de graduer les améliorations. Premièrement, mettre en place des améliorations simples et efficaces sur les problèmes majeurs. Dans l'exemple suivant, on pourra par exemple définir avec le groupe de travail les responsabilités, les livrables, une méthode de stockage centralisé des données (un serveur central et une règle de nommage claire pour les versions par exemple). Les résultats rapides permettent de a) démontrer qu'il est possible de changer les choses et que tout le monde y gagne (impact positif sur la motivation) et b) sécuriser les projets en résolvant les problèmes majeurs. Le rapport investissement-temps / gain est fort et incite à d'autres améliorations. Le groupe de travail pourra prévoir une phase suivante afin d'étudier la mise en place d'un outil pour lier les exigences et les éléments de conception logicielle afin de réduire les délais de conception.
Temps
Capacité à
réaliser un
système ou du
logiciel
objectif 1
Début du
programme
objectif 2
Itération 1
Améliorations
simples à forte
valeur ajoutée
Itération 2
Améliorations lourdes
à très forte valeur
ajoutée
Itération 3
Optimisations
Figure 2 : Illustration de l'approche itérative
L'approche progressive, permet aussi de répartir dans le temps les efforts de formation, les temps
d'adaptation qui 'perturbent' toujours plus ou moins le déroulement des projets et que l'on nomme
'la courbe d'apprentissage' (Learning curve). Un exemple factuel et mesurable est le temps des
formations (sensibilisation, procédures, outillage, méthodes…) des acteurs à ces nouvelles pratiques
qui devront être prises sur le temps des projets (pour un niveau CMMi 2, cela peut représenter une
centaine d'heures pour les chefs de projet).
Ecouter les acteurs du quotidien
Les problèmes réels sont connus des acteurs du quotidien, ils sont une source d'information cruciale
et doivent être impliqués pour trois raisons majeures. Premièrement parce qu'ils sont aussi une
source d'idées et de solutions et qu'ils sauront faire et évaluer des propositions d'amélioration en
restant pragmatique. Ensuite parce qu'il est important qu'une partie des acteurs s'approprie les
changements afin de réduire les résistances au changement et soient volontaires pour les phases
pilotes. Enfin, il faut prendre en compte les aspects psychologiques dus aux changements, en
particulier si ils impliquent une redéfinition des responsabilités, des habitudes… Il est envisageable
dans certains cas de faire appel à des cabinets spécialisés pour une intervention ponctuelle avec
succès. Juste pour l'exemple, certaines personnes acceptent très mal que leur travail soit mesuré par
un indicateur par peur d'être jugées en tant que personne.
Cycle de vie du programme
Cycle long
Afin de couvrir les risques cités en partie 1, un cycle de vie à deux niveaux est recommandé. Un
premier niveau dit 'Boucle longue' qui se déroulera typiquement sur une durée de 12 à 18 mois de
type IDEAL (méthode recommandée par le SEI pour l'amélioration continue - voir détails en
ANNEXE X), adaptée au contexte. Ce cycle à pour objectif de piloter le processus global au niveau
de l'organisation et donne lieu à des revues régulière en présence de la direction et des responsables
du projet d'amélioration. La fin d'un cycle préparera le début du cycle suivant.
Ce cycle se déroulera en 5 phases majeures:
• Phase initiale « Initiating » Cette phase permet entre autre chose d’identifier l’engagement d’amélioration et les ressources
requises pour le lancement. C’est lors de cette phase qu’est établie l’infrastructure d’amélioration
initiale ainsi que ses rôles et responsabilités. Cette phase pourtant primordiale est trop souvent
oubliée. Elle est pourtant une protection contre quelques risques majeurs liés à tout projet
d’amélioration de processus.
• Phase de diagnostic « Diagnosing » Cette phase sert à établir les fondements des prochaines étapes du cycle. Durant cette phase, des
activités d'évaluation sont effectuées afin d'établir l'état réel des pratiques actuelles de l'organisation
et ainsi en déduire les axes d'améliorations. Des recommandations et les objectifs visés par la boucle
d’amélioration sont les livrables principaux de cette phase.
• Phase d’établissement « Establishing » Cette phase permet de déterminer les axes prioritaires d'amélioration (sans donner les solutions à ce
stade) et de définir la feuille de route des phases suivantes.
• Phase d’exécution « Acting » Cette phase consiste à élaborer les solutions de processus à proprement parlé. Une fois décrits les
processus ou autre livrables sont utilisés dans le cadre de projets pilotes. Après avoir été raffinés si
nécessaire, les produits sont diffusés à l’organisation et institutionnalisés.
Cette phase comporte plusieurs cycles dits 'boucle courte' (décrite plus bas) en série ou en parallèle
comme défini dans la feuille de route. Des revues régulières permettent de recadrer si nécessaire le
déroulement de la feuille de route et éventuellement de re-planifier ou re-prioritiser la suite du
projet.
• Phase de bilan « Learning »
Durant cette phase, les produits de processus, le déroulement de la boucle IDEAL globale, et les
démarches utilisées sont évalués afin d’ajuster les pratiques pour la prochaine 'Boucle Longue'.
Description des cycles courts
Le second type de cycle de vie sera un ensemble cycle plus court, typiquement de 1 à 3 mois qui a
pour objectif de mettre en place une amélioration pour un domaine donné. Cette amélioration sera
déployée sur un projet pilote afin d'être validée. Chaque boucle courte doit apporter une
amélioration réelle et préparer le terrain pour les boucles suivantes. Ces boucles sont gérées comme
des mini-projets.
Par exemple une série de boucles sur la gestion des faits techniques (changements de spécifications
ou défauts dans le produit):
Boucle 1 : Définir le processus haut niveau (qui, quoi, quand…) et mettre en place les gabarits
standards et des outils peu onéreux (comme "Microsoft Excel", "OpenOffice Calc" ou "BugZilla" par
exemple). Mettre en place sur un projet pilote et déployer sur les autres projets (selon applicabilité).
L'objectif est la rationalisation du processus.
Boucle 2 : Evaluer des outils de gestion des faits techniques avancés, en choisir un, l'adapter aux
besoins et le mettre en place sur un projet donné. Mettre en place des mesures de base. L'objectif
est l'outillage afin d'améliorer l'efficacité et réduire les erreurs humaines.
Boucle 3 : Mettre en place des mesures et des méthodes de prédiction d'arrivée des défauts et
d'anticipation de la qualité produit. L'objectif est l'optimisation du contrôle du projet (temps de cycle,
qualité produit, gestion des risques …)
Initiale Diagnostique Etablissement Bilan - Prioritisation Boucles courtes (1 case = 1 mois) Accompagnement continu des projets
Gestion de projet
Gestion de la sous-traitance
Gestion des exigences
Gestion de configuration & Faits Techniques - Objectifs futurs
Assurance Qualité processus et produit
Gestion de la Vérification & Validation
Programme de metriques
Etc …
Codes couleur
Rationalisation
Amélioration
Optimisation
- Evaluation des
progrès
- Retours
d'expériences
- Evaluation des
pratiques
- Objectifs de la
boucle longue - Planification des
boucles courtes
- Engagement de
l'organisation
- Définition des
objectifs stratégiques
- Communication et
Motivation
Execution
Exemple de cycle projet.
La partie Execution est déterminée pendant la phase Etalissement
Les durées sont données à titre indicatif et non contractuel
- Definition des
groupes de travail
Indicateurs et mesures
Vision La mise en place d’indicateurs de mesures dans une organisation est une activité essentielle pour
garantir un niveau de maturité, le maintenir ou l’améliorer. L'expérience m'a amené à développer une
vision très pragmatique de la mise en place de mesures et de toujours clarifier l’objectif ultime d’une
métrique.
Méthode La mise en place d’indicateurs comporte des risques d’échecs liés à la définition, au calcul et à
l’utilisation d’une métrique. C’est pourquoi il est recommandé de mise en place d’un projet de
métriques sur le long terme et l’utilisation de méthodes éprouvées telle que la méthode « Objectif-
Question-Métrique » résumée ci-dessous.
Objectif-Question-Métrique
Il s’agit d’éviter de définir une métrique en définissant les éléments mesurés et les équations mais de
d’abord prendre en compte les objectifs des projets ou de l’organisation.
Objectif
Question 1 Question 2 Question 3
Métrique A
Métrique B
Un exemple très simple pour illustrer :
Objectif Organisation : Satisfaire ses clients par la qualité des logiciels et la ponctualité des livraisons
Objectif projet : Livrer à temps (plus ou moins 5 jours) avec 80% des fonctionnalités requises.
Question 1 : Livre-t-on à temps (plus ou moins 5 jours) ?
Question 2 : Livre-t-on les fonctionnalités requises (quel pourcentage) ?
Question 3 : Combien de défauts majeurs sont constatés après chaque livraison ?
Question 4 : Quel pourcentage de livraison respecte les critères donnés ?
Il serait très complexe de répondre à toutes ces questions dans une seule métrique (elle deviendrait
illisible) et il est recommandé d’après nos expériences de ne pas créer d’indicateur qui répond à plus
de 2 questions à la fois.
Il est possible de répondre aux questions 1 & 2 dans un même graphique (donné à titre d’exemple)
Losanges Bleus : Pourcentage des fonctionnalités attendues livrées et validées. Doit être supérieur ou égal à la ligne verte
Barres rouges : Nombre de jours de retard. Doit rester inférieur à 5 (axe de gauche)
Ligne bleue pointillée : Nombre de fonctionalités à livrer (pas d'objectif sur ce graphe)
Date de livraison Fonctionalités attenduesDate réelle Fonctionnalités validées% Fonctionalités validées Objectif Fonctionalités
01/01/2008 5 03/01/2008 5 100 Livraison 1
01/02/2008 10 01/02/2008 8 80 Livraison 2
01/03/2008 20 12/03/2008 12 60 Livraison 3
01/04/2008 40 01/04/2008 35 88 Livraison 4
01/05/2008 60 01/05/2008 35 58 Livraison 5
01/06/2008 80 01/06/2008 80 100 Livraison 6
01/07/2008 100 01/07/2008 95 95 Livraison 7
01/08/2008 100 12/08/2008 100 100 Livraison 8
01/09/2008 105 01/09/2008 100 95 Livraison 9
01/10/2008 105 01/10/2008 100 95 Livraison 10
Performance des projets
0
20
40
60
80
100
120
0
20
40
60
80
100
120
Retard Livraison (jours) Fonctionalités attendues
% Fonctionalités validées Objectif Fonctionalités
Il faut aussi bien séparer la mesure qui répond à la question et la métrique qui répond à « Pourquoi
nous n’avons pas atteint l’objectif ». L’une mesure une performance, l’autre permet d’analyser les
causes d’échecs.
Dans l'exemple suivant, on pourrait accoler un objectif : ‘Améliorer la performance des projets’
(Question : Pourquoi le projet n’atteint pas l’objectif) ou ‘Améliorer l’efficience’ (Ou sont
consommés le temps et les efforts).
Enfin, une bonne métrique est une métrique qui
• Est influencée par les décisions et actions des acteurs projets
• Donne une information factuelle qui peut influencer les décisions et actions des acteurs
ActionDemande
d’augmentation de
vitesse
MesureLa vitesse est
insuffisante
La vitesse
augmente
Mesure:La vitesse est
correcte
La mesure influence
les décisions et
actions
Les décisions et
actions influencent
la mesure
Si ces propriétés ne sont pas respectées, la métrique aura peu de chances de devenir crédible et
significatif pour les équipes. Il m'est arrivé de demander à modifier une métrique de ‘performance
équipe’ qui dans 50% des cas réagissaient à des décisions et actions d’une autre équipe.
Définition et déploiement
La mise en place d’une métrique requiert 4 phases qui peuvent être de courtes durées (une à deux
semaines) ou plus longues (plusieurs mois).
• Spécification de la métrique par la méthode Objectif-Question-Métrique
• Rédaction d’un « manuel utilisateur », prototypage
• Communication à l’organisation sur base du prototype, explication
• Validation, mise en œuvre et cycles de révisions
Utilisation des métriques
La mise en place d’un programme de mesure n’est jamais simple et doit prendre en compte la
maturité de l’organisation (employés, ingénieurs, cadres et direction) afin d’éviter les écueils les plus
fréquents. Il faudra porter une attention particulière à ne pas transformer (et faire percevoir aux
acteurs projets) les métriques en outil de pression ou outil de sanction. La direction et l’encadrement
doivent être amenés à comprendre une métrique défavorable comme un symptôme de
dysfonctionnement et à « poser des questions » plutôt que de requérir le redressement de la
métrique. Dans le premier cas, la direction demande pourquoi l’objectif n’est pas atteint et peut
requérir un plan de rattrapage et d’y apporter son soutient alors qu’une demandé péremptoire de
redressement risque de pousser les équipes à tricher sur la mesure (en donnant de faux
renseignements dans les formulaires par exemple).
Indicateurs proposés
Indicateurs de performances de projets
Afin de mesurer les améliorations réelles induites par le projet d’amélioration, il est intéressant de
mesurer les performances projets en termes de ‘Coût – Qualité – Délai’.
Côut doit être compris comme la somme, des couts financiers et des efforts (en homme-jours)
déployés pendant un certain temps (Délai) afin d’obtenir un produit de travail. Ce produit de travail
sera évalué en termes de Qualité (rempli les fonctions attendues).
Il n’est pas possible de fournir dans ce document une définition de mesure pour ces critères mais il
est possible de réutiliser l’exemple cité plus haut :
Losanges Bleus : Pourcentage des fonctionnalités attendues livrées et validées. Doit être supérieur ou égal à la ligne verte
Barres rouges : Nombre de jours de retard. Doit rester inférieur à 5 (axe de gauche)
Ligne bleue pointillée : Nombre de fonctionalités à livrer (pas d'objectif sur ce graphe)
Date de livraison Fonctionalités attenduesDate réelle Fonctionnalités validées% Fonctionalités validées Objectif Fonctionalités
01/01/2008 5 03/01/2008 5 100 Livraison 1
01/02/2008 10 01/02/2008 8 80 Livraison 2
01/03/2008 20 12/03/2008 12 60 Livraison 3
01/04/2008 40 01/04/2008 35 88 Livraison 4
01/05/2008 60 01/05/2008 35 58 Livraison 5
01/06/2008 80 01/06/2008 80 100 Livraison 6
01/07/2008 100 01/07/2008 95 95 Livraison 7
01/08/2008 100 12/08/2008 100 100 Livraison 8
01/09/2008 105 01/09/2008 100 95 Livraison 9
01/10/2008 105 01/10/2008 100 95 Livraison 10
Performance des projets
0
20
40
60
80
100
120
0
20
40
60
80
100
120
Retard Livraison (jours) Fonctionalités attendues
% Fonctionalités validées Objectif Fonctionalités
Losanges Bleus : Pourcentage des fonctionnalités attendues livrées et validées. Doit être supérieur ou égal à la ligne verte
Barres rouges : Nombre de jours de retard. Doit rester inférieur à 5 (axe de gauche)
Ligne bleue pointillée : Nombre de fonctionalités à livrer (pas d'objectif sur ce graphe)
Date de livraison Fonctionalités attenduesDate réelle Fonctionnalités validées% Fonctionalités validées Objectif Fonctionalités
01/01/2008 5 03/01/2008 5 100 Livraison 1
01/02/2008 10 01/02/2008 8 80 Livraison 2
01/03/2008 20 12/03/2008 12 60 Livraison 3
01/04/2008 40 01/04/2008 35 88 Livraison 4
01/05/2008 60 01/05/2008 35 58 Livraison 5
01/06/2008 80 01/06/2008 80 100 Livraison 6
01/07/2008 100 01/07/2008 95 95 Livraison 7
01/08/2008 100 12/08/2008 100 100 Livraison 8
01/09/2008 105 01/09/2008 100 95 Livraison 9
01/10/2008 105 01/10/2008 100 95 Livraison 10
Performance des projets
0
20
40
60
80
100
120
0
20
40
60
80
100
120
Retard Livraison (jours) Fonctionalités attendues
% Fonctionalités validées Objectif Fonctionalités
Idéalement, il faudrait ajouter une mesure des défauts trouvés après livraison afin de mesurer la
qualité du produit.
Le rapport ‘Cout-Qualité-Délai » est conditionné par l’efficience (ou productivité) de l’organisation.
Dans la plupart des projets d’amélioration, il est possible dès le début de mesure les pertes
d’efficiences en considérant que chaque défaut trouvé (dans les spécifications, la conception ou la
réalisation) engendre des pertes de temps et d’énergie. Mesurer la capacité de l’organisation à
détecter les défauts au plus tôt (Mesure du « Phase Containment ») permet de déterminer les phases
du projet sur lesquelles il faut agir. Le suivi dans le temps permettra de constater les améliorations
liées aux actions d’amélioration continue. En général, il faudra mettre en place progressivement, un
politique de mesure du coût de la qualité (et du coût de la non qualité).
Indicateurs de performances des processus
Chaque processus doit être mesurable afin de s’assurer que le processus est en place et appliqué et
qu’il permet d’atteindre les objectifs. Il y a beaucoup de mesures possibles sur chacun des processus
et la plupart des organisations effectuent des contrôles réguliers (effectués par des ingénieurs qualité)
mais il est conseillé de mettre en place des indicateurs de base. Voici quelques exemples typiques :
• Processus de gestion de projet
o Etat des contrats, Etat du planning, Etat des finances. Cela est le plus souvent mesuré
par audit peut être représenté sous forme d’un tableau et d’un code couleur.
• Processus d’ingénierie
o L’état des documents d’ingénierie permettra de constater si les spécifications, la
conception et les plans de tests sont bien centralisés, revus et approuvés. Cela peut
être fait par audit ou requête dans un système documentaire électronique pour
produire un tableau de bord visuel (code couleur ou quantités à atteindre)
o Le nombre d’erreur d’ingénierie (défauts trouvés pendant les phases d’ingénierie ou
après la livraison)
o Les matrices de traçabilité et les taux de couvertures pour la conception et les tests
donnent des informations sur la capacité de la conception à couvrir les exigences et
des tests à couvrir les exigences. Par exemple, on peut constater sur le processus de
conception n’est pas terminé ou s’est mal déroulé si des exigences n’ont pas été liées
à des éléments de conception.
o La « Volatilité » des exigences et de la conception permettra de ‘lire’ l’état de
maturité de la définition du projet. La mesure consiste à compter le nombre
d’exigences modifiées (ajoutées ou retirées). Ce nombre peut être élevé en début du
projet mais doit décroitre au fur et à mesure de l’engagement des ressources. En
général, chaque type de projet peut être associé à un profil de volatilité qui doit être
surveillé. Voir l’exemple ci-dessous sur les exigences.
% d’exigences
Modifiées
Objectif
Mesure
Temps et
phases
projetEtude
De Marché Spécification Conception Réalisation
2%
8%
4%
6%
10%
Le processus sera efficace s’il permet de figer rapidement les exigences comme le recommande la
ligne verte pointillée.
o La quantité d’artefacts produits (des lignes de code, des tables de base de donnée ou
des écrans de saisie) produits
o Le nombre de tests préparés et leur faculté à couvrir toutes les exigences
o Le nombre de tests passés avec succès
Indicateurs de déploiement des améliorations
Les projets d’améliorations doivent être gérés comme des projets avec des objectifs finaux et
intermédiaires. Afin de mesurer le déploiement d’améliorations, deux indicateurs peuvent être mis
en place.
• Pour chaque amélioration, il est possible de gérer un tableau de bord qui représente les
progrès de l’amélioration
Tableau de bord Premier Semestre 2008
Définition
processus
Gabarits et
modèles Outillage
Approbation
processus
Guide
Utilisateur
Formation
acteurs
Projet
Pilote
Gestion de projet Terminé Terminé Terminé En Cours avr-08 juin-08 avr-08
Planification Terminé Risque
Optimisation Gestion de
configuration En Cours En Cours
Outillage Gestion des exigences Terminé Terminé En Cours Risque
…
• Pour chaque amélioration, dans une fenêtre de temps de un à trois mois, on pourra
constater une amélioration des indicateurs de performance processus (voir chapitre
précédent)
• Enfin, d’une façon globale, il est possible de mettre en place une mesure du cout de la qualité.
Cela consiste à définir les tâches de travail ‘produit’ (tâches de création), le tâches de
‘prévention’ (revues, tests) et de ‘réparation’ (correction des erreurs et de leurs
conséquences) et de mesurer les efforts passés par catégorie.
Cout de la Qualité et de la non Qualité en 2008
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Réparation
Prévention
Produit
Culture d’amélioration continue
Un dernier indicateur pourra être utilisé pour ce programme afin de mesurer l’engagement de tous
les acteurs de l’organisation. Ce point est important car il permet de savoir si le projet a uniquement
modifié des comportements superficiels ou s'il y a vraiment un changement de mentalité dans
l’organisation.
Une méthode consiste à effectuer des sondages anonymes (une à deux fois par an) parmi les acteurs
afin de capturer leur vision du projet d’amélioration, des impacts positifs sur leur travail, sur les
projets, sur leur connaissance des processus. Certaines compagnies ont même démontré une
corrélation forte entre le niveau de culture qualité mesurée par ce type de questionnaire et la
performance des projets (cout – qualité – délai).
Il est aussi possible de mesurer la quantité d’efforts alloué à l’amélioration continue (nombre
d’heures ‘investies’ dans des groupes de travail), nombre de formations, nombre d’ingénieur qualité
et leurs niveau d’expertise…
Recommended