SlideShare uma empresa Scribd logo
1 de 88
Baixar para ler offline
GUIDE DES BONNES PRATIQUES
DU
LEAN PROJECT MANAGEMENT
Appliqué à la gestion des projets de transformation
Réalisé par :
Groupe de RĂ©flexion Lean Project Management
Sur les chemins de Grande Randonnée du Management

GBP-LPM – 1
ÈRE
EDITION – Juin 2012
2
PREAMBULE
M o d e d ’ e m p l o i :
Pour favoriser la compréhension des différents sujets traités et vous permettre de mieux apprécier
les termes et concepts contenus dans ce guide, nous avons choisi de faire des liens vers :
- les annexes : Qui developpement certains contextes en rapport direct avec ce guide ;
- le « Lexique Glossaire du Management » qui renvoie vers d’autres, termes et supports.
L e s V e r s i o n s d u G B P - L P M :
Ce document s’intitule « Guide des Bonnes Pratiques du Lean Project Management » (GBP-LPM
) – PremiĂšre Ă©dition. Nous invitons nos lecteurs Ă  nous faire part de leurs apprĂ©ciations positives
et/ou de leurs propositions d'amĂ©lioration de ce Guide, sachant qu’un site Internet sera dĂ©diĂ© Ă  cet
objectif d’interaction et de partage. GrĂące Ă  vos contributions, nous espĂ©rons qu'un GBP-LPM –
DeuxiĂšme Ă©dition pourra ĂȘtre publiĂ© dans un avenir proche.
Ce Guide a Ă©tĂ© rĂ©alisĂ© par un groupe de bĂ©nĂ©voles qui ont ƓuvrĂ© pour en dĂ©livrer cette premiĂšre
édition. Si ce sujet vous intéresse et si vous souhaitez transmettre vos connaissances, n'hésitez pas à
nous contacter via le site Internet. Peut-ĂȘtre pourriez-vous envisager de participer Ă  la prochaine
édition du GBP-LPM, voire de créer, à votre initiative, un nouveau groupe de bénévoles
 ?!
Au plaisir de lire vos appréciations et contributions !
.
Pour plus d’information sur les droits de Creative Commons, suivez le lien Creative Commons
Nous vous demandons d’utiliser ce Guide et de le
diffuser selon les droits de Creative Commons :
- gardez toujours la mention des auteurs de la
premiĂšre Ă©dition ;
- ne modifiez le contenu qu’en respectant la
cohérence avec la premiÚre édition ;
- ne vendez pas ce premier Guide et les futures
Ă©ditions ;
- gardez les mĂȘmes conditions Creative
Commons pour les futures Ă©ditions.
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
3
GenĂšse du GR-LPM (Groupe de RĂ©flexion Lean Project Management)
Le GBP-LPM est l'aboutissement d’une vĂ©ritable dĂ©marche collaborative rĂ©alisĂ©e par des acteurs
bénévoles, motivés, totalement indépendants les uns des autres, pourtant concepteurs et porteurs
de ce projet. Une telle collaboration s'appuie sur un moteur : l’envie de partager en groupe
(GR-LPM) des expériences et des compétences pour les mettre gracieusement à disposition de tous
ceux qui le souhaitent, notamment sous la forme d’un « Guide des Bonnes Pratiques en Lean Project
Management » (GBP–LPM).
Le 30 mars 2010, Ă  l’issue d’une confĂ©rence organisĂ©e par Erick ATHIER, fondateur associĂ© d’IQAR,
Dominique GARRET, soutien de l’évĂšnement en qualitĂ© de reprĂ©sentant du « PMI-Project
Management Institute France-Sud Chapter », propose de créer un groupe de réflexion sur le « Lean
Project Management ». Cette idée rencontre une écoute favorable et de vraies attentes. Les
membres du groupe s'accordent sur une charte du GR-LPM, qui repose sur les deux principes
suivants :
- le partage des connaissances et leur transmission Ă  un plus large public, notamment Ă 
l’occasion d’une confĂ©rence ;
- une équipe de réflexion et de travail constituée de personnes indépendantes, volontaires et
bénévoles, motivées par la pratique du travail collaboratif.
Le Groupe de Réflexion Lean Project Management est constitué :
1. des membres permanents du GR-LPM :
Pendant plus d'un an, les investissements personnels des contributeurs alimentent les travaux du
GR-LPM. Au fil des réunions mensuelles, le croisement des expériences de chacun au travers des
écrits sur les thÚmes retenus permet de construire petit à petit le présent GBP-LPM.
Ont contribué à ces travaux :
Marie-France PORTIER Bruno MOUESCA André CHAVEL
Michaël DUCRET Hervé ROUTON Christian GUERIN
2. du Pilote du GR-LPM et expert en la matiÚre - Intervenant bénévole :
Erick ATHIER
Dirigeant Fondateur et associĂ© d’IQar
MBA – Manager de Projet CertifiĂ© PMPÂź
3. de l’initiateur du GR-LPM et observateur – Soutien bĂ©nĂ©vole :
Dominique GARRET
Dirigeant fondateur d’AXcion
Auteur du «Lexique Glossaire d Management »
Administrateur du PMI Chapitre France-Sud
4. d’organismes parrains :
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
4
AFPI (Association de Formation Professionnelle de
l’Industrie), reprĂ©sentĂ©e par FrĂ©dĂ©ric GAUTHIER,
responsable PĂŽle Formation continue.
Nous remercions L’AFPI pour les locaux mis à disposition à
l’occasion des rĂ©unions physiques et pour la confĂ©rence du
24/11/11.
PMI-Project Management Institute – Branche Rhîne-Alpes,
représenté par Bruno LAUDE, Président de la branche
RhĂŽne-Alpes et VP du Chapitre France-Sud, et par
Bernard AVRIL, Administrateur PMI Chapitre FS, chef de
projet pour la conférence du 24/11/11
REMERCIEMENTS :
Nous tenons à remercier tout particuliÚrement Céline GROSJEAN, transcriptrice libérale
(1 rue LUIZET 69130 Ecully), qui nous a apporté, gracieusement, son savoir-faire pour la mise en
forme du GBP-LPM.
Nous remercions également Liying ZHOU pour la création de plusieurs illustrations du GBP-LPM.
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
5
PĂ©rimĂštre d’application du GBP-LPM
Le « Guide de Bonnes Pratiques du Lean Project Management », désigné sous le vocable GBP-LPM, a
pour objectif principal de représenter un support de référence pour les acteurs de la gestion de
projets souhaitant développer leurs connaissances et leurs compétences du Lean appliqué à la
Gestion des Projets de Transformation Organisationnelle.
Parmi ces différents acteurs, se distinguent :
- les Sponsors (promoteurs, maitres d’ouvrage, bĂ©nĂ©ficiaires) de la dĂ©marche Lean Project
Management (LPM) amenĂ©s Ă  Ă©tudier l’opportunitĂ© d’un projet, Ă  promouvoir ou appuyer la
mise en Ɠuvre du LPM dans son environnement ;
- les Managers et membres des équipes de projets, qui, composés principalement
d’opĂ©rationnels, sont dans l’obligation d’optimiser leur mĂ©thode et outils de gestion de
projets.
Le GBP-LPM aura donc pour but de devenir d’abord un instrument d’acquisition de compĂ©tences,
puis de référence méthodologique dans la conduite des projets.
Le GBP-LPM est dédié aux projets de « Transformations Organisationnelles ».
Un projet de transformation organisationnelle est un projet initiĂ© au sein d’une organisation
(entreprise, association, service public, etc.) pour faire Ă©voluer les pratiques, les processus, les outils,
les rÎles ou les responsabilités, et, au bout du compte, la compétence collective dans le but
d'améliorer ses performances organisationnelles en cohérence avec les objectifs stratégiques fixés.
De tels projets ont en commun les caractéristiques suivantes :
- ils ont Ă  leur tĂȘte un Sponsor (propriĂ©taire du processus Ă  crĂ©er, Ă  supprimer ou Ă 
transformer) clairement identifié ;
- ils contribuent et s’inscrivent dans une dĂ©marche globale d’entreprise ;
- ils intÚgrent nécessairement une part de conduite de changement et modifient
généralement les périmÚtres de responsabilités ;
- ils sont limitĂ©s dans le temps et dotĂ©s de contraintes qui peuvent et doivent ĂȘtre Ă©tablies
relativement tĂŽt dans le processus de gestion du projet.
Plus de détails sont donnés dans les chapitres suivants du GBP-LPM. Voici cependant quelques
exemples de projets de transformations :
- fusion – acquisition – intĂ©gration ;
- mise en place d’un nouvel outil de production, de nouvelles mĂ©thodes de travail ;
- informatisation d’un processus d’affaires ;
- dĂ©ploiement gĂ©ographique d’activitĂ©s de services ou de production ;
- 

GBP-LPM – 1
ÈRE
EDITION – Juin 2012
6
« Selon IBM et dans le cadre du CEO Study (enquĂȘte menĂ©e auprĂšs de 1 130 dirigeants de grandes
entreprises dans le monde et publiĂ©e en mai 2008), l’entreprise de demain sera avide de
changements. Cependant, la plupart des dirigeants interrogés sont peu confiants dans la capacité de
leur entreprise Ă  mettre en Ɠuvre les changements nĂ©cessaires. Le « change gap » (Ă©cart entre les
changements attendus par les dirigeants et leur perception de la capacité de leur entreprise à y faire
face) a quasiment triplé depuis 2006, poussant de nombreux dirigeants à lutter pour maintenir la
croissance et la stabilité de leurs entreprises ».
C’est certain, il y aura de nombreux projets de transformation organisationnelle Ă  rĂ©ussir demain,
peut-ĂȘtre plus qu’aujourd’hui.
Les fondements des principes méthodologiques présentés dans le GBP-LPM concernent la réussite
du changement dans les organisations humaines. Leur cadre d'application est donc plus large que les
projets de transformation organisationnelle. Ces principes se retrouvent par exemple dans l'industrie
à travers la conduite des projets de réduction de coût impliquant de la reconception des produits et
des process. Il appartiendra aux lecteurs de s’en inspirer.
Notre ambition au travers de ce guide est de partager avec les lecteurs et les professionnels de la
conduite du changement notre compréhension de la complémentarité des concepts structurants et
des pratiques de pilotage en mode projet, de la démarche Lean et des méthodes Agile.
Bonne lecture !
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
7
SOMMAIRE
1 - LE LEAN MANUFACTURING 9
1.1 – Historique et dĂ©finition 9
1.2 - Objectifs 10
1.3 – Les facteurs de succùs ou niveaux d’analyse 11
2 – L’AGILE 12
2.1 – La gestion de projets « Agile » 12
2.2 – Les limites et l’ouverture vers le Lean Project Management 14
3 – LEAN PROJECT MANAGEMENT 15
3.1 - Les 10 causes de pertes d’efficacitĂ© en gestion de projets 15
3.2 – L’efficacitĂ© par la maĂźtrise de la valeur 18
4 - LES FACTEURS DE SUCCÈS POUR RÉUSSIR UN PROJET DE TRANSFORMATION 19
5 - FORMALISER L’IDÉE DU PROJET 23
5.1 – Vue d’ensemble de la phase 23
5.2 – Les outils associĂ©s 24
5.3 – RĂŽles et responsabilitĂ©s 24
6 - INNOVER ET S’ENGAGER 25
6.1 - Vue d’ensemble de la phase 25
6.2 - Les outils associés 28
6.3 - RÎles et responsabilités 28
7 - METTRE EN ƒUVRE 30
7.1 - Vue d’ensemble de la phase 30
7.2 - Les outils associés 30
7.3 - RÎles et responsabilités 32
8 - TRANSFÉRER LES RESPONSABILITÉS 33
8.1 - Vue d’ensemble de la phase 33
8.2 - Les outils associés 34
8.3 - RÎles et responsabilités 34
9 – CLÔTURER ET FAIRE LE BILAN 36
9.1 - Vue d’ensemble de la phase 36
9.2 - Les outils associés 37
9.3 - RÎles et responsabilités 37
ANNEXE 1 38
ANNEXES 2 À 7 38
INTRODUCTION AUX ANNEXES-OUTILS (ANNEXES 7 À 23) 38
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
8
APPROPRIATION ET UTILISATION DES OUTILS 38
ANNEXE 1 : MÉTHODOLOGIES DU LEAN MANUFACTURING 39
ANNEXE 7 : MANAGEMENT DE RISQUE (RISK MANAGEMENT) 42
ANNEXE 8 : TDC - THÉORIE DES CONTRAINTES (TOC) 45
ANNEXE 9 : OUTILS DE LA MESURE ET DE L’ANALYSE QUALITÉ 47
ANNEXE 10 : MODELE DE COTATION (SCORING MODEL) 52
ANNEXE 11 : SMART (AIDE À LA DÉFINITION D’UN OBJECTIF OU D’UN INDICATEUR) 54
ANNEXE 12 : QPQQCOC 55
ANNEXE 13 : LE PROCESSUS DE CRÉATIVITÉ 57
ANNEXE 14 : REMUE MÉNINGES (BRAINSTORMING) 58
OUTILS DE PLANNIFICATION & PILOTAGE APPROPRIATION ET UTILISATION DES OUTILS 59
ANNEXE 15 : PLANIFICATION PAR VAGUES (ROLLING WAVE PLANNING) 60
ANNEXE 16 : DERNIER PLANIFICATEUR (LPS - LAST PLANNER SYSTEM) 62
ANNEXE 17 : SDP - STRUCTURE DE DÉCOUPAGE DU PROJET (WBS) 63
ANNEXE 18 : PERT - PROGRAM EVALUATION & REVIEW TECHNIQUE 66
ANNEXE 19 : GANTT 68
ANNEXE 20 : CHAINE CRITIQUE 70
ANNEXE 21 : MVA – MANAGEMENT PAR LA VALEUR ACQUISE (EVM - EARNED VALUE MANAGEMENT) 72
ANNEXE 22 : MODÈLE DE PILOTAGE PROJET SCRUM 75
ANNEXE 23 : ESPACE COLLABORATIF (OBEYA ROOM / WAR ROOM) 77
ANNEXE 24 : PARALLÈLE ENTRE LES SOURCES DE GASPILLAGES DU LEAN ET LES PERTES EN GESTION DE
PROJETS 79
ANNEXE 2 : CYCLE DE VIE, PHASE : « FORMALISER L’IDÉEE DU PROJET » 80
ANNEXE 3 : CYCLE DE VIE, PHASE : « INNOVER ET S’ENGAGER » 81
ANNEXE 4 : CYCLE DE VIE, PHASE : « METTRE EN ƒUVRE » 83
ANNEXE 5 : CYCLE DE VIE, PHASE : « TRANSFÉRER LES RESPONSABILITÉS » 85
ANNEXE 6 : CYCLE DE VIE, PHASE : ‘CLÔTURER, FAIRE LE BILAN’ 87
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
9
1 - LE LEAN MANUFACTURING
1.1 – Historique et dĂ©finition
Toyota a développé, au sortir de la Seconde guerre mondiale, un systÚme de production
remarquablement efficace qui prenait à contre-pied les principes de production de masse utilisés
jusqu’alors (prolongement du Taylorisme). Ce systùme de production, le TPS (Toyota Production
System), repose sur la base de « la stabilité des pratiques » et deux piliers : le « juste à temps »
(produire le juste nĂ©cessaire au moment oĂč le besoin est exprimĂ©) et le « jidoka » = Autonomation
(maßtrise efficace de la qualité).
Le TPS s'articule autour de l'idĂ©e d’identifier le client, la valeur ajoutĂ©e et, par dĂ©duction, d'Ă©liminer
les gaspillages et les pertes. Ce systÚme a évolué et propose de nombreux outils et concepts. Le TPS
s'inspire largement des idées de William Edwards DEMING. (Roue de DEMING/PDCA : Amélioration
continue).
En synthÚse, Le systÚme de production Toyota (TPS) a donné lieu au déploiement de plusieurs outils
et méthodologies spécifiques à la production industrielle (voir annexe 1). Il est généralement
représenté par un « temple » comme celui ci-aprÚs :
Figure 1 – Maison TPS
Source : « graphique original GR LPM » 2012
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
10
Le Lean manufacturing est un terme inventé en 1987 par James P. WOMACK et Daniel T. JONES,
deux chercheurs du MIT (Massaschussetts Institute of Technology). Ces deux chercheurs ont créé la
méthodologie Lean en utilisant le TPS comme exemple de production tout en conceptualisant la
culture Toyota.
Lean signifie littéralement « maigre », « svelte », mais aussi « ajusté » (ex. : une carburation « Lean »,
ni trop riche, ni trop pauvre). Cette derniùre traduction semble plus dans l’esprit du mot que
voulaient exprimer WOMACK et JONES.
1.2 - Objectifs
 Le premier objectif poursuivi par la dĂ©marche de Lean manufacturing est de gĂ©nĂ©rer la valeur
ajoutée maximale au moindre coût et au plus vite.
Pour atteindre un tel objectif, le Lean donne beaucoup d’importance à la formation des personnes et
en particulier à leur aptitude à résoudre des problÚmes (voir TRIZ).
C’est un mode de fonctionnement permettant Ă  l'entreprise d'amĂ©liorer fortement sa productivitĂ© et
sa réactivité par une division des tùches, non pas suivant une logique par nature, mais par un
découpage des produits ou des processus. L'efficacité est la résultante des compétences et des
responsabilités de chacun des acteurs impliqués.
Suivant P. WOMACK et D. JONES (cf « Lean Thinking »), 5 étapes sont nécessaires pour assurer une
démarche Lean :
1. DĂ©terminer la valeur du produit, c’est-Ă -dire spĂ©cifier ce qui crĂ©e de la valeur pour le client.
2. Identifier la chaĂźne de la valeur pour chaque produit : mesurer toutes les Ă©tapes du
processus en termes de performance et identifier les Ă©tapes inutiles.
3. Favoriser l’écoulement du flux : mettre en place des flux continus et assurer le mouvement
continu des produits, des services et des informations tout en Ă©liminant le gaspillage.
4. Passer du flux poussé au flux tiré, c'est-à-dire laisser le client orienter (tirer) la valeur du
produit.
5. Viser la perfection : mettre en Ɠuvre une dynamique d’amĂ©lioration continue pĂ©renne.
 Le second objectif poursuivi par la dĂ©marche de Lean manufacturing est d’éliminer toutes les
sources de gaspillages. « Gaspillages » est la traduction pour muda en japonais. Voici les 7 sources
identifiées :
1. La SURPRODUCTION : fait de produire en avance sans besoin exprimé, qui engendre des
stocks, des surplus de main d’Ɠuvre, machines et marchandises, 

2. L’ATTENTE : arrĂȘts de production

3. Les TRANSPORTS et MANUTENTIONS INUTILES : déplacements et manutentions inutiles des
produits
4. Les MOUVEMENTS INUTILES : tout mouvement n’ajoutant aucune valeur, dĂ©placement
inutiles
5. Les STOCKS : ils engendrent des frais de stockage, avec nĂ©cessitĂ© d’espace de stockage,
d’assurance.
6. Les TÂCHES INUTILES : ces tĂąches incorrectes ou non nĂ©cessaires n’apportent aucune valeur
au produit.
7. La PRODUCTION DEFECTUEUSE (rebus et déchets) : défauts sur des produits fabriqués.
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
11
1.3 – Les facteurs de succùs ou niveaux d’analyse
Les deux objectifs précités de développement de la valeur et de réduction des sources de gaspillages
impliquent les facteurs de succÚs suivants du systÚme de pensée Lean :
1. Formuler une stratĂ©gie Ă  long terme : baser ses dĂ©cisions sur le long terme mĂȘme si cela
peut nuire à l’atteinte de certains objectifs à plus court terme.
2. Développer un schéma productif à travers ces différentes étapes (les bons processus
produiront les bons résultats) :
 mettre en place des processus avec flux continus ;
 mettre en place les flux tirĂ©s pour Ă©viter la surproduction ;
 lisser la charge de travail par une production constante ;
 obtenir la qualitĂ© du premier coup : construire cette culture avec rĂ©solution immĂ©diate
des problĂšmes ;
 standardiser les processus et les activitĂ©s, viser l’amĂ©lioration continue et responsabiliser
les employés ;
 mettre en place le contrĂŽle visuel pour identifier tous les problĂšmes ;
 garantir la robustesse de l’appareil de production au service des employĂ©s.
3. Former des employés et partenaires :
 former des responsables qui connaissent parfaitement le travail pour transmettre la
philosophie et former les Ă©quipes ;
 former des personnes et des Ă©quipes exemplaires qui appliquent cette nouvelle culture ;
 respecter et motiver ses partenaires (leur faire aussi intĂ©grer l’amĂ©lioration continue).
4. IntĂ©grer l’amĂ©lioration opĂ©rationnelle par la rĂ©solution continue de problĂšmes :
 visites de terrain (gemba Walk) ;
 prendre des dĂ©cisions en s’inscrivant dans une dĂ©marche consensuelle et mettre en
Ɠuvre rapidement les plans d’actions choisis ;
 intĂ©grer l’amĂ©lioration continue par des pratiques de type Hansei (auto-rĂ©flexion)
corrective et Kaizen (amélioration permanente)
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
12
2 – L’AGILE
2.1 – La gestion de projets « Agile »
ParallÚlement aux avancées du Lean Manufacturing, les méthodologies de gestion/Management de
projet ont aussi sensiblement Ă©voluĂ© dans les annĂ©es 1990, notamment par l’apport de la gestion de
projet AGILE concernant, dans un premier temps, les projets de développement de logiciels
informatiques.
Il faut cependant attendre les annĂ©es 2000 pour voir l’idĂ©e se structurer autour du « Manifeste
agile » (Agile Manifesto, 2001), qui établit les 12 principes fondamentaux suivants :
1. Notre plus haute priorité est de satisfaire le client en livrant rapidement et réguliÚrement des
fonctionnalitĂ©s‹à grande valeur ajoutĂ©e.
2. Accueillez positivement les changements de besoins, mĂȘme tard dans le projet. Les
processus Agile‹exploitent le changement pour donner un avantage compĂ©titif au client.
3. Livrez frĂ©quemment avec des ‹cycles de quelques semaines Ă  quelques mois et
une‹prĂ©fĂ©rence pour les plus courts.
4. Les utilisateurs ou leurs reprĂ©sentants et les‹contributeurs doivent travailler ensemble
quotidiennement‹tout au long du projet.
5. RĂ©alisez les projets avec des personnes motivĂ©es. Fournissez-leur l’environnement et le
soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
6. La mĂ©thode la plus simple et la plus efficace pour transmettre de l’information Ă  l'Ă©quipe et Ă 
l’intĂ©rieur de celle-ci est le dialogue en face Ă  face.
7. Un rĂ©sultat opĂ©rationnel est la principale mesure d’avancement.
8. Les processus Agile encouragent un rythme de développement soutenable. Ensemble, les
commanditaires, les contributeurs et les utilisateurs devraient ĂȘtre capables de maintenir‹
indéfiniment un rythme constant.
9. Une attention continue Ă  l'excellence technique et Ă  une bonne conception renforce l’AgilitĂ©.
10. La simplicitĂ© - c’est-Ă -dire l’art de minimiser la quantitĂ© de travail inutile - est essentielle.
11. Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-
organisées.
12. À intervalles rĂ©guliers, l'Ă©quipe rĂ©flĂ©chit aux moyens de devenir plus efficace, puis rĂšgle et
modifie son comportement en conséquence.
Le tableau ci-aprĂšs permet d’apprĂ©cier le parallĂšle qui existe entre l’approche « Agile » et les
facteurs de succĂšs du Lean Manufacturing.
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
13
FACTEURS DE SUCCES DU LEAN PRINCIPES AGILE
1. La formulation d’une stratĂ©gie Ă  long terme ou
philosophie Ă  long terme
- Accueillez positivement les changements de besoins, mĂȘme
tard dans le projet. Les processus Agile‹exploitent le
changement pour donner un avantage compétitif au client.
2. Le dĂ©veloppement d’un schĂ©ma productif
caractéristique : les bons processus produiront les
bons résultats
Mise en place de processus avec flux continus.
- Livrez fréquemment avec des cycles de quelques semaines à
quelques mois et une‹prĂ©fĂ©rence pour les plus courts.
Mise en place de flux tirés pour éviter la surproduction.
- Notre plus haute priorité est de satisfaire le client en livrant
rapidement et rĂ©guliĂšrement des fonctionnalitĂ©s‹à grande
valeur ajoutée.
Lisser la charge de travail par une production constante.
- Les processus Agile encouragent un rythme de
dĂ©veloppement ‹soutenable. Ensemble, les commanditaires,
les contributeurs et les utilisateurs devraient ĂȘtre capables de
maintenir‹indĂ©finiment un rythme constant.
Obtenir la qualité du premier coup : construire cette
culture avec résolution immédiate des problÚmes.
- Un résultat opérationnel est la principale mesure
d’avancement.
Standardisation des processus et des activités : base de
l’amĂ©lioration continue et responsabilisation des
employés.
- La simplicitĂ© – c’est-Ă -dire l’art de minimiser la quantitĂ© de
travail inutile – est essentielle.
Mise en place du contrĂŽle visuel pour identifier tous les
problĂšmes.
- Une attention continue Ă  l'excellence technique et Ă  une
bonne conception renforce l’AgilitĂ©.
Robustesse de l’appareil de production au service des
employés.
- Accueillez positivement les changements de besoins, mĂȘme
tard dans le projet. Les processus Agile‹exploitent le
changement pour donner un avantage compétitif au client.
3. Le développement des employés et partenaires :
Former des responsables qui connaissent parfaitement
le travail pour transmettre la philosophie et former les
Ă©quipes.
- Les utilisateurs ou leurs reprĂ©sentants et les‹contributeurs
doivent travailler ensemble quotidiennement‹tout au long
du projet.
- RĂ©alisez les projets avec des personnes
motivĂ©es.‹Fournissez-leur l’environnement et le soutien dont
ils ont besoin et faites-leur confiance pour atteindre les
objectifs fixés
Former des personnes et des Ă©quipes exemplaires qui
appliquent cette nouvelle culture.
Respecter et motiver ses partenaires (leur faire aussi
intĂ©grer l’amĂ©lioration continue).
4. IntĂ©grer l’amĂ©lioration opĂ©rationnelle par la
résolution continue de problÚmes
Aller sur le terrain (Visites de terrain = gemba Walk).
- La méthode la plus simple et la plus efficace pour
‹transmettre de l’information Ă  l'Ă©quipe et Ă  l’intĂ©rieur de
celle-ci est le dialogue en face Ă  face.
Prendre des dĂ©cisions en s’inscrivant dans une
dĂ©marche consensuelle + mettre en Ɠuvre rapidement
les plans d’actions choisis.
- Les meilleures architectures, spĂ©cifications et‹conceptions
émergent d'équipes auto-organisées.
IntĂ©grer l’amĂ©lioration continue : rĂ©flexion et
amélioration en continu (Hansei et Kaizen).
- À intervalles rĂ©guliers, l'Ă©quipe rĂ©flĂ©chit aux moyens‹de
devenir plus efficace, puis rĂšgle et modifie
son‹comportement en consĂ©quence
Figure 2 – Correspondances AGILE – LEAN MANUFACTURING
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
14
DĂšs lors, l’approche « Agile » est considĂ©rĂ©e comme une alternative aux mĂ©thodes de management
de projets dites « PrĂ©dictives » ou « dĂ©finies » plus classiques. Elle s’est avĂ©rĂ©e comme une option
d’adaptation dans la gestion de certains projets, le plus souvent dans les systùmes et technologies de
l’information (IT maintenant dĂ©signĂ© sous le vocable TICC).
C’est en effet dans le domaine de l’informatique que l’Agile a Ă©tĂ© et demeure le plus largement
documentĂ© et mis en Ɠuvre. GARTNER avait mĂȘme prĂ©dit en 2009 que « 80% des projets de
développement des logiciels utiliseraient les méthodes Agile en 2012 ».
Dans ce secteur, la méthode de développement dite «Agile», vise essentiellement à réduire le cycle
de vie du projet de réalisation en accélérant la phase de production. A ce titre, elle rejoint les
objectifs principaux du Lean : augmenter la valeur et diminuer les pertes. En employant la méthode
Agile, le client obtient trÚs vite une premiÚre version mise en production sur le périmÚtre prioritaire.
Ainsi, il est possible d'associer les utilisateurs dÚs le début du projet.
GrĂące Ă  la mise en Ɠuvre d'une mĂ©thodologie de conduite de projet fondĂ©e sur les principes Agile, Ă 
savoir :
 le dĂ©veloppement d’une premiĂšre version avec les fonctionnalitĂ©s prioritaires ;
 l’intĂ©gration des fonctionnalitĂ©s complĂ©mentaires par un processus itĂ©ratif ;
 la rĂ©alisation de tests tout au long des cycles de rĂ©alisation ;
 l’implication forte du client.
Le client d'un projet met trĂšs vite en exploitation un produit partiel pour tester ces performances.
Dans ce processus court, les exploitants sont impliqués dans la définition du produit : dÚs réception
du produit, il est important d’identifier et de transmettre toutes les suggestions à envisager
concernant la version proposée. Les modifications nécessaires sont ainsi intégrées sans remise en
cause de tout ou partie du produit comme ce serait le cas pour un projet piloté en cascade (comme
dans le Développemet Dirigé par les Tests) ou en V (méthodes classiques).
2.2 – Les limites et l’ouverture vers le Lean Project Management
Le domaine d’application de l’Agile, souvent limitĂ© Ă  ce secteur IT, a certainement constituĂ© un frein
Ă  son dĂ©ploiement plus large. La plupart des entreprises qui utilisent l’Agile dĂ©finissent et analysent
des critÚres préalables au choix de la méthode de gestion, à savoir :
 Organisation et gouvernance : avoir la disponibilitĂ© du client dans la gestion des prioritĂ©s et
des changements ainsi que son implication effective dans le quotidien du projet.
 Qualification du projet (pĂ©rimĂštre, dĂ©lais, spĂ©cifications techniques, etc.) : pouvoir
développer par itération la solution visée par le projet.
 Équipe de projet : avoir ou faire Ă©voluer le rĂŽle des acteurs vers un mode Agile (rĂŽles et
responsabilitĂ©s, disponibilitĂ© des acteurs, niveau d’adhĂ©sion Ă  l’Agile, etc.). Certains rĂŽles
sont mĂȘme crĂ©Ă©s (scrum manager). Leur relation Ă  la planification, Ă  la gestion de la valeur, Ă 
la gestion des risques, mais aussi au management de l’équipe Ă©volue trĂšs fortement au
passage d’une mĂ©thode dite prĂ©dictive/conventionnelle Ă  une mĂ©thode dite « Agile ».
 Environnement de travail et production : pouvoir allouer des moyens spĂ©cifiques Ă  l’équipe
de projet (configuration des locaux et de l’équipe, interface avec le systĂšme de production,
etc.).
DĂšs lors, il Ă©tait tentant d’explorer autrement le rapprochement des principes et valeurs de
la gestion de projet « Agile » d’une part, et de ceux du « Lean manufacturing » d’autre part.
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
15
3 – LEAN PROJECT MANAGEMENT
Claude EMOND (http:///www.qualiscope.ca) a été un précurseur de la formalisation de cette
approche de management des projets (qu’ils soient chaordiques ou pas) Ă  travers ses dĂ©marches de
« Change Boxing » qui consistent Ă  appliquer les principes clefs du Lean manufacturing et de l’Agile
aux projets de transformations. Claude EMOND, avec plusieurs consultants, a proposé une
transcription intéressante des 7 sources de gaspillage du Lean manufacturing vers la gestion de
projets en rajoutant 3 autres sources pour dĂ©terminer les 10 causes de pertes d’efficacitĂ© en
conduite de projets.
Ces 10 causes de pertes en management de projets sont orientées par la valeur, donc par le client, et
constituent les fondements du Lean Project Management.
3.1 - Les 10 causes de pertes d’efficacitĂ© en gestion de projets
Ces 10 causes de pertes d’efficacitĂ© du Lean Project Management sont prĂ©sentĂ©es dans le tableau ci-
dessous (figure 3), dont une version plus détaillée est proposée en annexe 24.
Il existe un parallĂšle entre les 7 sources de gaspillage du Lean Manufacturing et les 10 causes de
pertes en projet Ă  partir desquelles le chef de projet et toutes les parties prenantes devront
s’entendre pour optimiser les chances de succùs du projet (figure 3), ainsi que les pratiques à
valoriser (figure 4 et annexe 24).
L’annexe 24 complĂšte finalement ces deux tableaux par un listage des outils les plus appropriĂ©s pour
chacune de ces sources de gaspillage.
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
16
Les GASPILLAGES dans le
LEAN MANUFACTURING
(gestion flux matériel)
Commentaires pour Ă©clairer et
« traduire » vers le mode projets
Source de GASPILLAGE en GESTION
DE PROJETS
SURPRODUCTION
(travail réalisé trop en
avance, engendrant surplus
de main d’Ɠuvre, machines,
marchandises, etc.)
RĂ©aliser des tĂąches qui ne sont pas
forcément demandées (pas de
demande « aval ») et qui risquent fort
de ne plus ĂȘtre nĂ©cessaires. Souvent
lancées pour « occuper » des
ressources (talents) surabondantes.
REALISER LE PROJET DANS UN
MAUVAIS TIMING, REALISER UN
PROJET OU DES LIVRABLES SANS
VALEUR AJOUTEE
ATTENTE
(ArrĂȘts de production, etc.)
L'opérateur attend des piÚces, ou les
piĂšces doivent attendre avant d'ĂȘtre
traitées
ATTENTE DE DONNEES D'ENTREES /
MANQUE D'EFFICACITE DANS
L'EXPLOITATION DES DONNEES DE
SORTIE
TRANSPORTS ET
MANUTENTIONS INUTILES
(déplacements et
manutentions inutiles du fait
du manque de fonctionnalité
de l’espace de travail)
L'objet fabriqué est déplacé
inutilement et doit passer
typiquement Ă  des endroits sans
valeur ajoutée ...
TRANSFERT DEFICIENT DE
L'INFORMATION / PROBLEMES DE
COMMUNICATION (***)
MOUVEMENTS INUTILES
(Tout mouvement qui
n’ajoute aucune valeur)
Celui qui fabrique doit effectuer des
mouvements ou déplacements inutiles
pour effectuer son travail : il n'a pas
tout sous la main.
MOYENS, PROCESSUS ET
DOCUMENTATION IMPARFAITS
STOCKS INUTILES
(engendrant des frais de
stockage, avec nécessité
d’espace de stockage,
assurance, etc.)
Faire des stocks pour optimiser
localement un processus ou parce que
le processus de fabrication n'est pas
assez réactif.
DECISIONS QUI ATTENDENT /
PROCESSUS DE PILOTAGE et
D'ACCEPTATION TROP COMPLEXES
TÂCHES INUTILES
(tñches n’apportant aucune
valeur au produit)
Tñches n’apportant aucune valeur au
produit
REALISATIONS INUTILES (« gold
platting »)
PRODUCTION DEFECTUEUSE
(rebus, déchets et défauts sur
produits fabriqués =>
invendus)
Non Qualité
REALISATIONS NON APPRECIEES PAR
LES CLIENTS
Principes ajoutés par Claude EMOND (*), M. BOBEK (**) et M. HOWELL
MACOMBER (***)
SITUATIONS OU L'ON S'ARRANGE
AVEC LES MOYENS DU BORD
(« Making do »)
RESISTANCE AU CHANGEMENT (**)
NON GESTION DES PERCEPTIONS (*)
Figure 3 – Sources de gaspillage en conduite de projets
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
17
Source de GASPILLAGE en
GESTION DE PROJETS
PRATIQUES et COMPETENCES A VALORISER afin de diminuer les sources de gaspillages
en mode projets
REALISER LE PROJET DANS UN
MAUVAIS TIMING, REALISER UN
PROJET OU DES LIVRABLES SANS
VALEUR AJOUTEE
Vérifier la pertinence de la transformation souhaitée (origine, but, enjeu)
Avoir un Sponsor clairement identifié et impliqué
Evaluer le couple « valeur/risques » du projet, aussi en rapport avec d'autres projets en
cours ou à démarrer
Vérifier le niveau réel de priorité du projet dans le portefeuille
MaĂźtriser parfaitement les hypothĂšses, limites et contraintes du projet
Exprimer le projet en termes de niveau de performance Ă  atteindre
Maßtriser les changements et réévaluer réguliÚrement le couple « valeur/risques »
ATTENTE DE DONNEES
D'ENTREES / MANQUE
D'EFFICACITE DANS
L'EXPLOITATION DES DONNEES
DE SORTIE
Remettre le PERT au centre de la planification
Impliquer les ressources réalisant les tùches ainsi que leurs managers dans la définition
des « entrées/sorties »
Avoir les ressources compétentes et disponibles au bon moment
Savoir anticiper
TRANSFERT DEFICIENT DE
L'INFORMATION / PROBLEMES
DE COMMUNICATION (***)
Communication efficace et directe s'appuyant sur un minimum de relais
Un bon Ă©quilibre entre communications formelles et informelles
Espaces de travail collaboratif, points fréquents et réguliers
Style de management adapté à l'autonomie des équipes (fonction des compétences et de
la motivation)
Valorisation des comportements efficaces pour le fonctionnement de l'Ă©quipe
MOYENS, PROCESSUS ET
DOCUMENTATION IMPARFAITS
Optimiser les processus et la documentation liés à la gestion des projets (documents
autoporteurs)
Optimiser le SI projets
Optimiser le reporting
AccÚs rapide aux ressources (organisation matricielle réelle)
Environnement de travail collaboratif
DECISIONS QUI ATTENDENT /
PROCESSUS DE PILOTAGE et
D'ACCEPTATION TROP
COMPLEXES
Clarifier, optimiser les délais, outils et instances de prise de décision et le systÚme
d'arbitrage
Impliquer le client et le Sponsor, tout comme les experts clefs dans le projet
COPIL opérationnel et ayant le pouvoir de décider
REALISATIONS INUTILES (« gold
platting »)
DĂ©couper le projet en phases et en livrables
Remettre la SDP/WBS au centre de la planification
Exprimer le projet en termes d'exigences et de performances
REALISATIONS NON APPRECIEES
PAR LES CLIENTS
Depuis l'opportunité jusqu'à la clÎture, collaborer étroitement avec le client et le sponsor
du projet
Faire exprimer le projet en termes d'exigences, de niveau de performance Ă  atteindre
Définir une stratégie de test / validation / acceptation avec le client
Viser une livraison par « version »
SITUATIONS OU L'ON S'ARRANGE
AVEC LES MOYENS DU BORD
(« Making do »)
Obtenir les moyens proportionnés aux enjeux du projet
Accepter le changement et le maĂźtriser
Trouver et gérer la compétence et l'expertise
RESISTANCE AU CHANGEMENT
(**)
Communiquer sur l'origine, les enjeux, les objectifs. Relier le projet à la stratégie
Intégrer la gestion du changement à la gestion du projet (activités concrÚtes et réelles)
Etablir des objectifs pour toutes les parties prenantes
NON GESTION DES PERCEPTIONS
(*)
Etablir des limites, des contraintes et des hypothÚses collectivement au démarrage du
projet
S'assurer en permanence des Ă©quilibres entre les exigences, les besoins, les objectifs
Être Ă  l'Ă©coute et communiquer
Intégrer au plus tÎt toutes les parties-prenantes au projet
Figure 4 – Pratiques Ă  valoriser pour diminuer les pertes d’efficacitĂ© en conduite de projets
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
18
3.2 – L’efficacitĂ© par la maĂźtrise de la valeur
Conduire un projet ne peut se rĂ©sumer Ă  minimiser ou Ă©liminer des pertes d’efficacitĂ©.
Par essence, un projet se rĂ©ussit aussi dans l’animation d’un flux de crĂ©ation de valeur. C’est le rĂŽle
du cycle de vie que d’encadrer la crĂ©ation de la valeur dans un projet. Le cycle de vie est
gĂ©nĂ©ralement spĂ©cifique Ă  chacun des projets. Il peut ĂȘtre schĂ©matisĂ©, Ă  trĂšs haut niveau, de la
maniÚre suivante : Lancer, Planifier, Exécuter, ClÎturer (concept IPECC du PMIŸ)
Dans un projet de transformation, les étapes encadrant la création de valeur sont les suivantes :
 formaliser l’idĂ©e (voir dĂ©tails dans chapitre 5)
 innover et s’engager (voir dĂ©tails dans chapitre 6)
 mettre en Ɠuvre (voir dĂ©tails dans chapitre 7)
 transfĂ©rer les responsabilites (voir dĂ©tails dans chapitre 8)
 clĂŽturer, faire le bilan (voir dĂ©tails dans chapitre 9)
Ainsi, aprÚs les bases de réflexion spécifiques aux projets de transformation (voir chapitre 4), les
chapitres subséquents (5 à 9) du GBP-LPM reprennent chacune des étapes du projet en suivant la
démarche ci-dessous :
- comprendre les bénéfices et réalisations attendues à chacune des phases pour créer de la
valeur ;
- repĂ©rer et agir sur les sources de pertes d’efficacitĂ© de la phase ;
- s’appuyer sur des outils spĂ©cifiques permettant de diminuer les risques de pertes d’efficacitĂ© et
d’augmenter la valeur attendue à l’issue de la phase.
=> Efficacité VS Efficience
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
19
4 - LES FACTEURS DE SUCCES POUR REUSSIR UN PROJET DE TRANSFORMATION
Comme dĂ©fini en introduction dans la section « PĂ©rimĂštre d’application du GBP-LPM », les projets de
transformation recouvrent des caractéristiques et conditions de succÚs particuliÚres.
Ce chapitre a pour objectif de dĂ©terminer les Ă©lĂ©ments prĂ©requis (ou Ă  renforcer) dans l’entreprise
pour qu’un projet de transformation puisse atteindre son objectif principal, à savoir :
« Augmenter la capacité à produire de la valeur » (voir figure 5).
Figure 5 : Projets VS opérations courantes
Source : « graphique original société IQar : http://smp2.org et http://iqar-france.fr »
En effet, l’entreprise est un ensemble de ressources, d’opĂ©rations et de stratĂ©gies gĂ©rĂ©es dans
l’optique de Produire de la valeur + Augmenter de maniĂšre continue la capacitĂ© Ă  produire de la
valeur.
Tout systÚme de management efficace prend en compte ces deux aspects, parfois « concurrents »
dans l’utilisation des ressources de l’organisation. La rĂ©alisation d’un projet de transformation
s’inscrit dans ce contexte et vise Ă  augmenter la capacitĂ© de l’entreprise Ă  produire de la valeur en
minimisant les perturbations opérationnelles qui créent cette valeur au quotidien.
Les premiĂšres conditions favorables pour la mise en Ɠuvre de ce type de projet se rĂ©sument
probablement dans la figure 6 suivante, c'est-Ă -dire dans la justification consensuelle du projet que
l’on pourrait rĂ©sumer par « Faire le bon projet et le faire au meilleur moment ».
Figure 6 - Se transformer : Vision, DĂ©cision, Action
Source : « graphique original société IQar : http://smp2.org et http://iqar-france.fr »
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
20
Pour créer le consensus sur la transformation, il faut concrÚtement veiller à :
- Impliquer les utilisateurs : c’est un principe d’habilitation, fondamental dans les « MĂ©thodes
Agile » et du LEAN Manufacturing. Il faut placer l’individu et notamment le client au centre du
dĂ©veloppement. Ceci permet de limiter l’opposition au changement. Il est donc important de
choisir des personnes « clĂ©s » dans l’équipe de projet. L’utilisateur, s’il est partie-prenante
dans l’équipe de projet, ne pourra qu’adhĂ©rer puisqu’il aura participĂ© Ă  l’élaboration collective
des livrables Ă  chaque Ă©tape.
- S’assurer du support de la Direction GĂ©nĂ©rale : son implication est essentielle. C’est elle qui
exprime le besoin de changement d’organisation et qui est à l’origine du projet. Celui-ci ne
peut pas débuter tant que les moyens financiers et humains demandés par le chef de projet ne
sont pas accordés. La Direction nomme le chef de projet et approuve la constitution de
l’équipe projet. Elle approuve Ă©galement le calendrier de rĂ©alisation du projet proposĂ© par
l’équipe projet.
DĂšs qu’elle a avalisĂ© le dĂ©marrage du projet, son soutien doit ĂȘtre sans faille. Elle doit aider le
chef de projet à faire « sauter » les freins en particulier auprÚs de la hiérarchie et des
décideurs à chaque jalon.
- Faire consensus sur la production de valeur avec les acteurs de la transformation, mais aussi
avec les acteurs de sa future gestion rĂ©currente. Quel que soit le domaine d’affaires, la taille
de l’entreprise ou sa culture, il est indĂ©niable qu’il y a une constante dans les projets de
transformations : Ils offrent aux diffĂ©rents acteurs des intĂ©rĂȘts et des opportunitĂ©s
divergents. Chacun accorde en effet Ă  la transformation une valeur ou une contre-valeur qui
détermine largement son implication dans le projet.
MĂȘme quand la transformation semble s’imposer Ă  l’entreprise, le moment choisi pour rĂ©aliser
la transformation est presque systématiquement discutée. La notion de bénéfices doit alors
ĂȘtre mise au centre de toutes les dĂ©cisions pendant le projet.
La gestion de la transformation doit apporter des réponses à long terme (la valeur de la
transformation), mais aussi à plus court terme, c'est-à-dire les bénéfices pour chacun des
acteurs impliquĂ©s en tant qu’expert dans le projet (figure 7).
Figure 7 – Le projet de transformation est un lien entre la stratĂ©gie et les bĂ©nĂ©fices attendus
Source : « graphique original société IQar : http://smp2.org et http://iqar-france.fr »
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
21
Découper le projet en petites étapes cohérentes est donc un des points importants de la
conduite de projet Agile. Le morcĂšlement de la transformation s’avĂšre ĂȘtre gĂ©nĂ©ralement une
excellente stratĂ©gie pour la recherche d’adhĂ©sion au projet. Il s’agit d’obtenir des Ă©tapes
autoportantes et courtes (Sprint), avec une définition claire, comprise et approuvée de tous les
acteurs. Aussi, des livrables sont nécessaires pour avancer sans perte de temps sur le projet. Il
est Ă©galement indispensable que le chef de projet nomme un responsable pour chacune des
tùches élémentaires identifiées.
Ce responsable est le «porteur» de la tùche et la réalise et/ou la coordonne au sein de
l’équipe projet. Ainsi, au-delĂ  du dĂ©coupage de chacune des Ă©tapes de la mise en Ɠuvre, il est
essentiel de remettre le PERT au centre du projet et de sa réalisation.
Plus que dans tout type de projets, les projets de transformation organisationnelle méritent
de viser un maximum de bénéfices en un minimum de temps. Ceci est nécessaire pour ne pas
perdre l’adhĂ©sion de certains acteurs.
D’autres clefs de succĂšs sont garantes de l’optimisation du dĂ©roulement du projet. Elles
concernent naturellement les notions de performance et de compétence.
- Choisir le bon chef de projet : son rĂŽle est essentiel. Il doit maĂźtriser les outils de la conduite
de projet, avoir de grandes qualitĂ©s d’écoute et la capacitĂ© de comprendre et de faire passer
des messages Ă  des publics aussi variĂ©s que la direction gĂ©nĂ©rale, l’encadrement (middle
management), ou l’opĂ©rateur utilisateur ou sachant. Il doit savoir s’imposer auprĂšs de tous par
ses qualitĂ©s et non par la fonction qu’il occupe. Il est le garant du respect du cahier des
charges, du projet et de sa réussite.
- Obtenir le personnel compĂ©tent : cela va sans dire, c’est Ă©vident. En phase d’avant-projet, s’il
est dĂ©jĂ  nommĂ© par la direction gĂ©nĂ©rale, c’est au chef de projet de constituer son Ă©quipe de
projet. Il doit ĂȘtre en mesure d’en choisir les membres en fonction de leurs compĂ©tences
techniques sur le sujet concernant le projet. Il doit pouvoir faire ce choix aux frontiĂšres des
contraintes hiĂ©rarchiques. Cependant, in fine, la validation de la constitution de l’équipe projet
est de la responsabilité de la direction générale.
- Avoir une Ă©quipe autonome dans sa prise de responsabilitĂ© : dans l’item prĂ©cĂ©dent, nous
avons parlĂ© du choix des membres de l’équipe projet en fonction de leurs compĂ©tences eu
Ă©gard au sujet du projet. Le chef de projet doit s’assurer que chaque membre de son Ă©quipe a
la libertĂ© de ses prises de responsabilitĂ© dans le cadre de son dĂ©tachement au sein de l’équipe
projet. Il doit ĂȘtre informĂ© par un membre susceptible de subir des pressions de la part de sa
hiérarchie de nature à changer ses décisions ou ses orientations dans le cadre de la conduite
du projet.
Finalement, il apparait déterminant de rendre la transformation totalement concrÚte dans
l’esprit des personnes qui vont contribuer Ă  la rĂ©aliser ou plus tard Ă  l’opĂ©rer. Les principes
d’intĂ©gration et de rĂ©alitĂ© donneront du corps Ă  la transformation.
- Planifier de maniĂšre rĂ©aliste : entre la phase d’avant-projet et la validation du lancement du
projet par la direction gĂ©nĂ©rale, le chargĂ© de projet doit s’assurer que le planning gĂ©nĂ©ral de
déroulement du projet est cohérent avec les allocations de moyens humains consacrés au
projet. Il ne doit pas céder, a priori, aux pressions de la direction générale tentant de lui
imposer des dĂ©lais non rĂ©alistes. Les dĂ©lais doivent ĂȘtre nĂ©gociables avec les moyens humains
et financiers accordĂ©s au projet. Le rĂŽle du chef de projet, en cours de projet, est d’identifier
les sources de glissement de planning et de proposer des actions correctives. Un reporting
rĂ©gulier doit ĂȘtre fait Ă  la direction gĂ©nĂ©rale. Une approche de la planification par vague
déferlante (voir annexe 15) semble tout à fait appropriée.
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
22
- Prendre en compte tous les facteurs liĂ©s Ă  l’environnement du projet : ce sont des facteurs
qui peuvent ĂȘtre liĂ©s Ă  l’environnement de l’entreprise : taille de l’entreprise, type
d’organisation, modifications majeures affectant l’entreprise en cours de rĂ©alisation du projet,
etc.
La figure 8 ci-aprĂšs rĂ©sume l’ensemble des leviers prĂ©requis Ă  la bonne rĂ©alisation d’un projet de
transformation.
Figure 8 – PrĂ©requis Ă  la rĂ©alisation d’un projet de transformation organisationnelle
Source : « graphique original société IQar : http://smp2.org et http://iqar-france.fr »
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
23
5 - FORMALISER L’IDEE DU PROJET
5.1 – Vue d’ensemble de la phase
C’est la toute premiĂšre phase du projet. Dans certaines organisations, cette phase est prĂ©cĂ©dĂ©e
d’une phase d’opportunitĂ© ou de cotation (scoring) du projet (voir outils en annexe 10), c’est-Ă -dire
de caractérisation de l'apport de valeur versus les contraintes de réalisation entre plusieurs axes de
solutions possibles. Cette hiérarchisation facilite le choix par le sponsor du projet. On parle alors
souvent d’un avant-projet. Lorsqu’une telle phase n’existe pas en tant que tel, l’opportunitĂ© est une
« donnĂ©e de sortie » de la phase « Formaliser l’idĂ©e du projet ».
L’opportunitĂ© du projet permet de faire Ă©tablir, par les principaux acteurs, un consensus sur le
couple « valeur ajoutĂ©e/risques encourus » Ă  s’engager dans le projet. La phase d’opportunitĂ©
dĂ©termine aussi naturellement les objectifs assignĂ©s, tout comme l’existence d’un budget pour
formaliser le projet, les échéances principales, les hypothÚses, les contraintes, les conditions de
réussite et toute autre exigence.
Dans un projet de transformation, les principaux acteurs veilleront Ă  ne pas court-circuiter cette
phase, au risque de voir les ressources consommées se trouver gaspillées par des résultats en fort
Ă©cart avec les attentes. Cette phase a aussi comme objectif de dĂ©terminer le niveau d’engagement
qui doit ĂȘtre partagĂ© et portĂ© par un sponsor (payeur et membre de la direction) et par un client
et/ou des utilisateurs.
Un des piÚges majeurs d'un projet de transformation serait de partir d'emblée dans l'application
d'une solution poussée avec influence et/ou autorité par certains sans en avoir réellement apprécié
l'adéquation avec le rapport « valeurs/risques ».
En résumé, il s'agit à ce stade de s'abstenir de la facilité des solutions toutes faites mises en avant.
Certains acteurs pourraient influencer le choix des solutions à leur avantage spécifique sans
nĂ©cessairement mesurer l‘impact et, surtout, l’effort de mise en Ɠuvre.
La phase « Formaliser l’idĂ©e du projet » vise Ă  poser LA bonne question que le projet tentera
ensuite de rĂ©soudre. L’objectif principal de la phase « Formaliser l’idĂ©e du projet » est donc bien
d’établir la non-performance actuelle et de dĂ©finir l'objectif de performance visĂ©.
A l’issue de la phase « Formaliser l’idĂ©e du projet », les parties prenantes disposent :
- d’un constat objectif sur la non-performance (justification) ;
- d’une analyse des « sachants » Ă  propos des causes, des pistes de solutions (attentes et
exigences) ;
- d’ordre de grandeur pour le projet (coĂ»ts, dĂ©lais, contenu, qualitĂ©, etc.) ;
- d’un plan d'actions prĂ©cis pour la phase suivante.
Cette premiĂšre phase doit ĂȘtre approuvĂ©e formellement par le sponsor et le client dans la charte du
projet.
Pour voir plus en dĂ©tails comment s’appliquent les principes du Lean Project management Ă  cette
phase, voir l’annexe 3 (« Cycle de vie : formaliser l’idĂ©e du projet »).
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
24
5.2 – Les outils associĂ©s
Voir fiches-outils suivantes en annexe :
- Cotation (Scoring) en annexe 10, pour Ă©valuer l’idĂ©e du projet afin de s’engager ou pas dans
le projet ou encore pour prioriser le projet dans la « pile » des projets de l’entreprise.
- Management de risque (Risk-Management) en annexe 7, pour anticiper les principaux
risques et mettre en perspective la valeur du projet avec les risques encourus.
- SDP ou WBS en annexe 17, pour découper le projet en étapes à forte valeur ajoutée.
- SMART en annexe 11, pour la qualité de définition des objectifs à atteindre.
5.3 – RĂŽles et responsabilitĂ©s
La premiĂšre phase d’un projet reprĂ©sente une collaboration entre le sponsor et les clients.
Le chef de projet est nommé durant cette premiÚre phase.
Le sponsor est celui qui a le plus intĂ©rĂȘt Ă  ce que le projet se rĂ©alise. Dans le cadre de projets de
transformation organisationnelle, il est un des membres dirigeant. Il peut ĂȘtre nommĂ©
« commanditaire » ou « propriétaire » du projet. Il donne les moyens au projet de fonctionner et le
reprĂ©sente auprĂšs de la direction. Il est responsable de l’atteinte des objectifs du projet. Il valide les
hypothÚses, les contraintes et les limites à la réalisation de celui-ci lors de la phase « Formaliser
l’idĂ©e du projet ».
La dénomination de « client » est généralement utilisée pour décrire au moins 2 types de clients, le
payeur et l’utilisateur. Dans le cadre des projets de transformation, le client payeur est souvent
interne Ă  l’organisation (reprĂ©sentĂ© par le sponsor). Le client utilisateur doit ĂȘtre, lui aussi,
clairement identifié et impliqué dans toutes les phases, y compris la premiÚre phase de formalisation
de l’idĂ©e du projet. Les utilisateurs doivent exprimer leur besoin en termes d’exigences
fonctionnelles. Une dĂ©rive frĂ©quente rĂ©side dans l’absence d’implication rĂ©elle des clients, alors
simplement représentés par le sponsor.
Le chef de projet est nommĂ© par le sponsor. Il est responsable du « voyage » si l’on considĂšre que la
transformation consistera Ă  aller d’une situation « A » non performante vers une situation « B »
visée. Sa responsabilité au cours de ce « voyage » consiste concrÚtement à :
- identifier tous les acteurs et les impliquer ;
- dĂ©terminer des scĂ©narii de rĂ©alisation et conduire le sponsor et le client Ă  n’en retenir qu’un ;
- prĂ©voir la rĂ©alisation du projet sur l’ensemble des domaines de gestion (coĂ»ts, dĂ©lais,
contenus, risques, RH, communication, qualitĂ©, etc.) et faire approuver les plans d’actions
associés ;
- assurer un suivi du projet pour maßtriser et gérer les écarts, maßtriser et faire approuver les
changements, le cas échéant.
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
25
6 - INNOVER ET S’ENGAGER
6.1 - Vue d’ensemble de la phase
La phase de formalisation terminée, le projet de transformation a pris sens et est devenu opportun.
La nature des performances à changer et les niveaux de gaps (écarts) à combler ont été identifiés et
clairement caractérisés par l'équipe de projet. Le sponsor et le client les ont validés.
L a v i s i o n s y s t Ă© m i q u e p a r t a g Ă© e
Au cours de ce processus de diagnostic approfondi, l'équipe de projet s'est approprié la situation
d'insatisfaction liée à l'existence de ces écarts (gaps) et s'est bùti une culture commune des sujets.
Entre eux, les acteurs partagent, plus que tout autre, une représentation commune de l'écosystÚme
organisationnel concerné, de ses fonctionnalités, de ses limites, de son identité, et probablement de
ses mythes fondateurs et de ses valeurs. En tout cas, s'agissant d'un projet de transformation
organisationnelle, la bonne comprĂ©hension de ces diffĂ©rents aspects peut ĂȘtre recommandĂ©e tant il
est vrai que la mise en Ɠuvre des changements pour atteindre un nouvel Ă©tat de performances
accrues passe par de l'adhésion partagée.
L e l a n g a g e c o m m u n
Ce parcours initiatique se concrétise en particulier dans la construction d'une codification partagée
entre les équipiers projet au premier niveau et, d'une façon moins précise, avec leurs proches dans
leurs réseaux directs. C'est le langage commun du projet.
L a r e c h e r c h e d e s o l u t i o n s
DÚs lors, l'équipe projet dispose de tous les éléments et des atouts pour trouver les solutions
d'amélioration opérationnelles et pragmatiques qui permettront d'atteindre le nouveau palier de
performances organisationnelles visé.
Deux dĂ©marches complĂ©mentaires sont, en gĂ©nĂ©ral, mises en Ɠuvre en parallĂšle.
1. Pour les solutions "préexistantes", repérées lors de la phase de diagnostic : une rapide
évaluation de leurs réels enjeux et des conditions de leur faisabilité est conduite. Si la
pertinence de ces solutions est dĂ©montrĂ©e, la barriĂšre Ă  l'adhĂ©sion et Ă  la mise en Ɠuvre est
moins difficile Ă  franchir. Si les niveaux d'amĂ©lioration sont en dessous du niveau visĂ©, l’équipe
devra commencer une recherche pour de nouvelles solutions.
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
26
2. Pour les axes de progrÚs sans piste de solution identifiée : L'équipe de projet va devoir faire
preuve de créativité opérationnelle. Il existe de nombreuses méthodes de créativité, plus ou
moins complexes Ă  mettre en Ɠuvre. La plus connue est le ‘’Remue mĂ©ninges’’ (brainstorming)
(annexe 14). Simple Ă  mettre en Ɠuvre, c'est la mĂ©thode de rĂ©fĂ©rence et elle convient bien en
particulier dans les projets de transformation organisationnelle Ă  condition de la mettre en
Ɠuvre correctement. L'efficacitĂ© d'un processus de crĂ©ativitĂ© dĂ©pend dans l'ordre de :
a. La qualité de sa préparation
Rappelons-nous "qu'un problÚme bien posé est à moitié résolu". Le processus sera
véritablement créatif s'il se donne la possibilité d'accéder à des solutions réellement
innovantes, en rupture. Pour cela, il est recommandé de reformuler le sujet en termes
fonctionnels. Cette approche méthodologique présente de multiples avantages parmi
lesquels :
- s'extraire du cadre restreint de la solution existante ;
- poser le problÚme à résoudre en termes neutres de besoins et d'objectifs ;
- intégrer facilement des apports et des benchmarks externes.
b. L'organisation et la conduite du processus crĂ©atif. Il s'agit en particulier d'ĂȘtre exigeant
sur :
- le choix des participants ;
- la neutralité et la dynamique de l'animateur ;
- le respect des participants ;
- l'alternance des Ă©tapes de divergence et de convergence ;
- le déroulement en 7 étapes (cf. annexe 14).
c. L'exploitation des idées produites. Il peut sembler curieux que cette étape, qui est
l'aboutissement recherché du processus, soit en dernier par ordre d'importance. Pour
se convaincre de la pertinence de cette façon de voir, il suffit de s'interroger sur la
qualité de solutions construites sur des propositions en décalage par rapport aux
niveaux des enjeux et de la complexité. Sans paraphraser, rappelons certaines phrases
célÚbres d'Einstein :
- « Un problÚme sans solution est un problÚme mal posé » ;
- « Si je disposais d'une heure pour résoudre un problÚme et que ma vie en dépende,
je consacrerais les 55 premiÚres minutes à définir la question appropriée à poser,
car, une fois cela fait, je pourrais résoudre le problÚme en moins de 5 minutes"
L a q u a l i f i c a t i o n d e s s c Ă© n a r i i
Les idées produites par l'équipe de projet en groupe de créativité sont assemblées en scénarii de
solutions sur une base de cohérence et de compatibilité. Chacun des scénarii est évalué en termes de
potentiel sur le référentiel cible construit au départ et en termes de faisabilité. Pour la rapidité et la
qualité de l'évaluation, l'équipe projet doit travailler de façon participative en s'appuyant sur une
implication des acteurs potentiellement fortement impactĂ©s par la mise en Ɠuvre de la solution. La
méthode de cotation (« scoring ») sera partagée. La plus simple est le diagramme 4 carrés, bien
connu, croisant l'axe des bénéfices avec celui de la faisabilité.
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
27
Les paramĂštres de faisabilitĂ© peuvent ĂȘtre multiples, surtout dans le cadre d'un projet de
transformation organisationnelle. En effet, la faisabilitĂ© peut ĂȘtre Ă  dĂ©cliner par exemple sur :
- le délai compatible ou non avec le cadrage du sponsor ;
- les moyens physiques Ă  mettre en Ɠuvre en cohĂ©rence ou non avec le budget prĂ©vu par le
sponsor ;
- les parties prenantes obligatoirement associées au processus de décision comme les
partenaires sociaux et les instances représentatives dans l'entreprise ;
- la capacité d'adhésion des salariés (motivation), la culture d'entreprise, etc. ;
- la remise en cause de processus informels existants, mais stratégiques dans la création de
valeur de l'entreprise ;
- ...
Certains de ces critĂšres peuvent ĂȘtre destructeurs d'une solution. L'Ă©valuation moyenne de faisabilitĂ©
n'est alors pas suffisante. Attention à ne pas prendre ses désirs pour des réalités !
Pour les scénarii aux enjeux les plus forts avec une faisabilité jugée « accessible », une analyse de
risque (cf. annexe 7) est rĂ©alisĂ©e et un prĂ©-planning de mise en Ɠuvre construit sur la base d'un plan
d'action de mise en Ɠuvre et de dĂ©ploiement.
L a v a l i d a t i o n p a r l e s p o n s o r e t l e ( s ) c l i e n t ( s )
Les scénarii qualifiés à la hauteur des enjeux du projet avec une faisabilité suffisante et des risques
clairement identifiés sont alors présentés aux Sponsor et client(s) pour discussion et choix.
L e c o n t r a t d ' o b j e c t i f
Le sponsor dĂ©cide de confier le pilotage de la mise en Ɠuvre de la solution de changement retenue Ă 
l'équipe projet. En fonction de la nature des transformations à réaliser, le choix des membres
constituant cette Ă©quipe peut ĂȘtre adaptĂ©. L'Ă©quipe projet est alors mandatĂ©e par le sponsor dans un
contrat d'objectifs pour déployer le scénario choisi.
La fin de cette phase doit faire l'objet d'un plan de communication officiel. La transparence sur l'objet
de la mission et les clauses de son déroulement ainsi que l'engagement de la direction sont des
conditions nécessaires à la réussite du projet dans les phases suivantes.
Pour plus de dĂ©tails sur cette phase et pour apprĂ©cier les sources d’efficacitĂ© et de gaspillage,
consulter l’annexe 4 (voir aussi les termes : Contrats et management de contrats ; Objectifs )
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
28
6.2 - Les outils associés
Voir fiches outils suivantes en annexe :
- processus de créativité en annexe 13 pour assurer sa cohérence avec le problÚme posé et sa
richesse de production ;
- cotation = scoring en annexe 10 pour évaluer les scénarii ;
- management de risque = risk-management en annexe 7 pour anticiper les principaux
risques, mettre en perspective les conditions de réussite du développement des solutions,
construire un plan d'action et un planning pertinents ;
- GANTT en annexe 19 pour construire le planning prévisionnel du développement et du
déploiement des scénarii qualifiés.
6.3 - RÎles et responsabilités
L e S p o n s o r
L'équipe de projet conduit sa démarche sur la base du mandat que le sponsor lui a confié. Le
référentiel d'appropriation et de mise en situation pour la créativité de l'équipe est validé avec le
sponsor. L'objectif est de s'assurer de la bonne compréhension du périmÚtre du sujet. A l'issue du
processus de créativité et de sélection des scénarii probables sur la base des dossiers argumentés
présentés par le chef de projet et son équipe, le sponsor choisit le scénario à développer. Il contribue
Ă  la construction du plan de communication sur le projet qui va ĂȘtre mis en Ɠuvre, le valide et
apporte officiellement son cautionnement. Il missionne l'Ă©quipe de projet pour la phase de
déploiement et signe les contrats d'objectif.
L e m a n a g e r d e p r o j e t
Avant tout, il est le garant du bon déroulement de la phase et du processus de créativité. Il est acteur
comme ses équipiers de la construction du référentiel de créativité. Il s'assure de sa bonne
comprĂ©hension par chacun des membres de l'Ă©quipe. En fonction de ses compĂ©tences, il peut ĂȘtre
l'animateur des séances de créativité, ou déléguer ce rÎle à une personne plus adaptée.
Pour certains sujets de crĂ©ativitĂ©, il peut ĂȘtre nĂ©cessaire de faire appel Ă  la prĂ©sence de personnes de
l'équipe de projet pour des séances de créativité. Il se charge alors d'obtenir leur disponibilité et leur
explique les raisons de leur implication et l'importance.
Il participe activement et pilote les séances de croisement des idées pour la construction et des
scénarii, ainsi qu'aux séances d'évaluation. Il entérine le choix de son équipe projet concernant les
propositions présentées pour validation au sponsor.
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
29
L ' a n i m a t e u r d e s s Ă© a n c e s d e c r Ă© a t i v i t Ă©
Son rÎle est primordial pour la qualité du travail de production d'idées en séance. Il explique aux
membres de l'Ă©quipe de crĂ©ativitĂ© et s'impose Ă  lui-mĂȘme les attitudes fondamentales nĂ©cessaires Ă 
la créativité :
- écoute de soi pour laisser émerger les éléments préconscients et les livrer spontanément
sans autocensure ;
- disponibilité aux autres pour intégrer ce qui est proposé sans critique ;
- l'expression spontanée et l'expression par les images ;
- la fluidité pour privilégier la quantité à la qualité ;
- la flexibilité de la démarche en fonction des occasions qui se présentent, sans lourdeur.
Dans son rĂŽle, l'animateur assure trois fonctions :
- participer Ă  la production d'idĂ©es au mĂȘme titre que les autres membres ;
- faciliter la tùche de chaque participant (libérer les timides, réguler discrÚtement les bavards,
faire s'exprimer les silencieux, etc.) ;
- réguler le fonctionnement du groupe (resituer, reformuler et positiver, relancer, ré-
impliquer, etc.).
L ' Ă© q u i p e p r o j e t
Le client fait totalement partie de l’équipe et prĂ©cise ses exigences tout au long de la phase
d’innovation et d’engagement. Avec ses exigences, il affine les contraintes, les hypothùses de travail
et les risques. Les membres de l'équipe s'approprient la démarche par leur implication dans la
construction du référentiel préalable aux séances de créativité. Ils font partie de l'équipe de
créativité, de la génération des idées jusqu'à la construction des scénarii et leurs évaluations. En
séance, ils mettent en application les attitudes fondamentales propices à la qualité de production
des séances de créativité. Le croisement des idées et la construction des scénarii est de leur
responsabilitĂ©, de mĂȘme que tous les travaux nĂ©cessaires Ă  l'Ă©valuation de celles-ci.
L e s i n v i t é s « n a ï f s » a u x s é a n c e s d e c r é a t i v i t é
En nombre trÚs limité (1 à 2 personnes), l'association de ce type de profil à une séance de créativité
peut s'avérer trÚs profitable pour accroßtre la richesse des propositions, surtout si les membres de
l'équipe projet sont trÚs imprégnés de l'existant.
De maniÚre générale, les critÚres à retenir pour le choix des profils sont :
- la neutralité par rapport au sujet ;
- une bonne culture générale ;
- une capacité à s'intégrer et à s'exprimer dans un univers nouveau tout en respectant les
rÚgles d'attitude fondamentales pour la créativité ;
- l'apport d'une expérience décalée tout en présentant des parallÚles avec le sujet à traiter.
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
30
7 - METTRE EN ƒUVRE
7.1 - Vue d’ensemble de la phase
La phase « mettre en Ɠuvre » intĂšgre deux sous-ensembles importants, Ă  savoir : planifier et
réaliser.
Elle est spĂ©cifique Ă  chacun des projets, dont la mise en Ɠuvre reste unique. De ce fait, elle se
dĂ©compose en Ă©tapes de crĂ©ation de valeur, chacune d’entre elles Ă©tant jalonĂ©e par des dĂ©cisions
relatives à l’acceptation du plan de management de projet tout d’abord (fin de la planification), puis
des livrables (tout au long de la rĂ©alisation). La phase de mise en Ɠuvre intĂšgre donc nĂ©cessairement
des activitĂ©s de tests et d’acceptation des livrables.
Les Ă©tapes de la phase « Mettre en Ɠuvre » sont gĂ©nĂ©ralement envisagĂ©es Ă  l’issue de la phase
« Innover et s’engager ». En effet, l’engagement se matĂ©rialise Ă  ce moment-lĂ  par le choix d’un
scénario de réalisation qui sera donc découpé en étapes de création de valeur. Les étapes sont
ensuite confirmĂ©es au dĂ©but de la phase « Mettre en Ɠuvre », c’est-Ă -dire Ă  l’issue de l’exercice de
planification.
Pendant la phase « Mettre en Ɠuvre », les enjeux sont donc de prĂ©voir et de maĂźtriser la crĂ©ation
de valeur. Typiquement, au cours de la rĂ©alisation, l’équipe de projet s’attachera Ă  maĂźtriser les
écarts et les dérives potentielles du projet, la gestion des changements étant au centre des
préoccupations des acteurs tout au long de cette phase.
7.2 - Les outils associés
Pour rĂ©aliser la phase « Mettre en Ɠuvre », les acteurs du projet devront s’appuyer sur l’ensemble
des outils proposés en annexe du GBP-LPM.
OUTILS UTILISATION POTENTIELLEMENT RECOMMANDEE
- ANNEXE 7 - OUTILS –
Management de risque =
Risk management
En phase de planification dans l’évaluation, la qualification,
la quantification et le suivi des risques inhérents à la
réalisation de tout projet.
En phase de réalisation si les risques se présentent.
- ANNEXE 8 - OUTILS – ThĂ©orie
des Contraintes = TOC
Essentiellement au moment de la planification, mais aussi
pour le suivi de la mise Ɠuvre et de ses dĂ©lais/ressources, en
particulier.
- ANNEXE 9 - OUTILS –
QUALITÉ
Essentiellement au moment de la planification et de
l’acceptation.
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
31
OUTILS (suite) UTILISATION POTENTIELLEMENT RECOMMANDEE (suite)
- ANNEXE 10 - OUTILS –
ModĂšle de cotation = Scoring
model
Doit ĂȘtre mis Ă  jour au fur et Ă  mesure de l’avancement du
projet (à ses grands jalons de mise en Ɠuvre) afin de
permettre Ă  la direction de prioriser le projet dans le
portefeuille.
- ANNEXE 11 - OUTILS - SMART
(Aide Ă  la dĂ©finition d’un
objectif ou indicateur)
Essentiellement au moment de la planification pour
déterminer les délais, les coûts ou encore le niveau
d’exigence du projet. Permettra aussi de cadrer les relations
entre le chef de projet et les autres parties prenantes.
- ANNEXE 12 - OUTILS -
QPQQCOC (Questionnement
générique organisé = Matrice
de Quintilien)
Essentiellement au moment de la planification pour
déterminer les activités, les délais, les coûts ou encore le
niveau d’exigence du projet. Potentiellement pour gĂ©rer
certaines « crises » pendant la mise en Ɠuvre et prendre du
recul sur les situations ainsi que sur les rĂŽles et
responsabilités.
- ANNEXE 15 - OUTILS –
Planification par Vagues =
Rolling Wave Planning
Essentiellement au moment de la planification, mais aussi
pour le suivi de la mise Ɠuvre et de ses dĂ©lais/ressources, en
particulier.
- ANNEXE 16 - OUTILS -
SystĂšme dernier planificateur
= Last Planner System (LPS)
Essentiellement dans la planification, mais aussi au plus prĂšs
du terrain lorsqu’il est nĂ©cessaire de replannifier des tĂąches
ou livrables au regard de changements ou Ă©vĂšnements
spécifiques.
- ANNEXE 17 - OUTILS –
Structure de DĂ©coupage du
Projet (SDP= WBS)
Essentiellement au moment de la planification, mais aussi
pour le suivi de la mise Ɠuvre et la maütrise de l’envergure
en particulier.
- ANNEXE 18 - OUTILS – PERT
Essentiellement au moment de la planification, mais aussi
pour le suivi de la mise Ɠuvre et de ses dĂ©lais/ressources, en
particulier.
- ANNEXE 19 - OUTILS - GANTT Essentiellement au moment de la planification, mais aussi
pour le suivi de la mise Ɠuvre et de ses dĂ©lais en particulier.
- ANNEXE 20 - OUTILS –
Chaine Critique
Essentiellement au moment de la planification, mais aussi
pour le suivi de la mise Ɠuvre et de ses dĂ©lais en particulier.
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
32
OUTILS (suite) UTILISATION POTENTIELLEMENT RECOMMANDEE (suite)
- ANNEXE 21 - OUTILS –
Management de la Valeur
Acquise = Earned Value
Management (EVM)
Essentiellement en mode suivi et pour apprécier les
tendances du projet sur les volets coûts et délais. Permet de
calculer des indicateurs de pilotage.
- ANNEXE 22 - OUTILS –
ModĂšle agile de pilotage de
projet : SCRUM
Pour mener à bien certaines phases du projet nécessitant
une gestion plus collective ou pour répondre à des situations
de crise. Pilier du mode Agile.
Pour plus de dĂ©tails sur cette phase « Mettre en Ɠuvre » et pour apprĂ©cier les sources d’efficacitĂ© et
de gaspillage, consulter l’annexe 5.
7.3 - RÎles et responsabilités
Le sponsor donne les moyens au projet de fonctionner et représente le projet auprÚs de la direction.
Comme il est imputable de l’atteinte des objectifs et des exigences fixĂ©s pour le projet, il suit la mise
en Ɠuvre de prùs. Le sponsor est le plus souvent le client payeur des projets de transformations
organisationnelles. Comme il a fixé au moment du démarrage les hypothÚses, contraintes et limites,
il assume pendant la « mise en Ɠuvre », le lien entre les livrables et les objectifs. Il reste le garant
de la performance, c’est-Ă -dire de la capacitĂ© du projet Ă  minimiser ses sources de gaspillage tout en
augmentant au maximum la satisfaction du client et la valeur du projet pour ce dernier.
Le client utilisateur doit ĂȘtre, lui aussi, clairement impliquĂ©, mais aussi canalisĂ© dans ses vellĂ©itĂ©s de
changement et ses responsabilitĂ©s sur la priorisation. S’il a dĂ©terminĂ© des exigences fonctionnelles
(préalablement dans les étapes de lancement du projet), il contribue à arbitrer les priorités au
moment de la mise en Ɠuvre. Dans le cas de changements (initiĂ©s par lui ou pas), ou simplement de
dĂ©cisions ou d’options Ă  prendre pendant le projet, il canalise l’expertise des contributeurs/experts.
Il oriente le chef de projet et le Sponsor dans l’organisation gĂ©nĂ©rale du projet. Il est
particuliÚrement présent pour cautionner la planification proposée et accepter les livrables.
Le chef de projet est clairement l’artisan principal de cette phase de mise en Ɠuvre. On le nomme
souvent « le pilote ». Au moment de la planification, il est responsable de prĂ©voir les plans d’actions
et les « vases communicants » entre les différents leviers de la planification (délais, budget, contenu,
niveau de qualité, risques, Ressources, etc.). Il propose des options de réalisation et assume les plans
d’actions opĂ©rationnels qui accompagnent ces options. Au moment de la rĂ©alisation, il maĂźtrise les
Ă©carts et Ă©value/propose des changements. Il est le lien entre toutes les parties prenantes du projet
sans toutefois monopoliser le leadership.
Dans le cas d’une gestion de projet en mode Agile selon le concept le plus utilisĂ© actuellement :
SCRUM, le rĂŽle de « Scrum manager » est dĂ©terminant. Parfois, il peut ĂȘtre confondu avec celui de
chef de projet, mĂȘme si cela ne reprĂ©sente pas la « Bonne pratique » (voir outils en annexe 22).
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
33
8 - TRANSFERER LES RESPONSABILITES
8.1 - Vue d’ensemble de la phase
C’est au cours de cette phase que la transmission de la responsabilitĂ© de l’application des rĂ©sultats
du projet entre l’équipe de projet et le client sera rĂ©alisĂ©e. Elle doit donc ĂȘtre formalisĂ©e, parce
qu’elle constitue la fin de la mission de l’équipe projet.
Il ne s’agit pas de la clîture ni du bilan du projet, mais bien d’une phase concrùte de travail qui
consiste Ă  remettre au(x) client(s) les « clefs » du projet, Ă  lui donner les moyens d’exploiter la
transformation souhaitĂ©e. Cette phase doit ĂȘtre considĂ©rĂ©e comme « la rĂ©ception » des rĂ©sultats du
projet par le client et le sponsor. Elle intÚgre le plus souvent des volets « formation » et
« communication » assez présents.
Cette phase est essentielle pour la finalisation du projet et pour la pérennisation des résultats
souhaités par le client (utilisateur). Dans un projet de transformation, la tendance classique serait de
limiter cette phase et de « zapper » vers un autre projet.
Si elle se dĂ©roule correctement, cette phase sera une garantie d’atteinte des rĂ©sultats du projet et
de leur appropriation au sein de l’entreprise. Sa rĂ©ussite de cette phase est fortement facilitĂ©e si le
client est intĂ©grĂ© Ă  l’équipe projet ou si un rapport (reporting) pĂ©riodique est effectuĂ© auprĂšs de lui
par le chef de projet au cours des phases précédentes. Il est fortement conseillé, en fonction de la
nature, de la complexitĂ© et de l’incidence des rĂ©sultats du projet sur le fonctionnement de
l’entreprise, d’effectuer le transfert des responsabilitĂ©s de l’équipe projet au client par briques
successives.
Plus le projet inclura « d’agilitĂ© », plus il sera morcelĂ© en livrables courts et dĂ©finis et plus la phase
de transfert de responsabilités sera aisée et efficace.
Lors de cette phase, la tentation est grande d’amĂ©liorer toujours et encore les livrables et d’aller « un
peu plus loin ». Pourtant, ce n’est pas son objectif. A priori, la phase de transfert de responsabilitĂ©
n’est pas une phase de production, mais plutît d’installation, comme pour un projet industriel. Il
n’est en gĂ©nĂ©ral pas conseillĂ© d’exploiter cette phase pour amĂ©liorer les livrables. Il est important
pour l’ensemble des acteurs de se concentrer sur l’objectif de transfert de responsabilitĂ© et de ne pas
se disperser.
A priori, si nous avons atteint cette étape du projet, cela signifie que les livrables ont été réalisés et
acceptĂ©s lors de la phase prĂ©cĂ©dente et qu’il est nĂ©cessaire de les transfĂ©rer, de les intĂ©grer au
quotidien de l’entreprise et du client qui a souhaitĂ© que le projet se rĂ©alise.
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
34
A l’issue de la phase « transfĂ©rer les responsabilitĂ©s » le client dispose des Ă©lĂ©ments essentiels
suivants :
- un document de synthÚse sur la réalisation du projet rappelant les attendus de celui-ci
(donnĂ©es d’entrĂ©e et de sortie), les motivations de choix effectuĂ©s lors du dĂ©roulement du
projet permettant, si d’autres dĂ©veloppements ultĂ©rieurs sont envisagĂ©s, d’avoir un retour
d’expĂ©rience de l’équipe qui a conduit le projet ;
- un cahier de procédures détaillées aidant le client et ses équipes pour la phase
d’appropriation des rĂ©sultats du projet et la mise en place des modifications d’organisation
induites par le projet dans l’entreprise ;
- des indicateurs de performance permettant de mesurer les gains apportés par la mise en
Ɠuvre des prĂ©conisations issues des rĂ©sultats du projet sur l’organisation, sachant que les
valeurs de rĂ©fĂ©rence sont celles constatĂ©es avant la mise en Ɠuvre des modifications
d’organisation, donc antĂ©rieures au projet ;
- une information des diffĂ©rents intervenants (sponsor, client, hiĂ©rarchie, etc.) ainsi qu’un
programme de formation et d’accompagnement des Ă©quipes d’utilisateurs du client.
En fonction de la complexitĂ© du changement d’organisation induit par les rĂ©sultats du projet, le
manager de projet devra prĂ©voir un « Service AprĂšs-Vente » de la mise en Ɠuvre du projet adaptĂ©
au mode de fonctionnement de l’entreprise sous forme de rĂ©unions pĂ©riodiques pendant quelques
mois, ou sous forme de téléassistance (hot-line).
8.2 - Les outils associés
Voir fiches outils suivantes en annexe :
- modĂšle de cotation (Scoring model) en annexe 10 : pour reboucler sur la valeur attendue et
imaginée du projet à son lancement ;
- SDP (Structure de DĂ©coupage du Projet) en annexe 17 : pour s’assurer que l’ensemble des
livrables ont bien été transférés.
8.3 - RÎles et responsabilités
Au cours de cette phase, les rÎles et responsabilités de chacun des intervenants sont les suivants :
Chef de projet : comme dans toutes les autres phases du projet, son rîle est essentiel. Il s’agit ici
essentiellement d’un rĂŽle « pĂ©dagogique ». Le chef de projet doit savoir donner l’autonomie
suffisante à son client pour que ce dernier intÚgre les livrables dans son environnement opérationnel
et se les approprie.
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
35
Client et/ou utilisateur : son rĂŽle est prĂ©pondĂ©rant puisqu’il devient, Ă  l’issue de cette phase, celui
qui va officiellement utiliser les livrables. Il s’engage Ă  mettre en Ɠuvre les rĂ©sultats de projet auprĂšs
de ses Ă©quipes, qu’il sensibilisera si nĂ©cessaire. Il Ă©change avec le chef de projet sur les activitĂ©s de
transfert et d’accompagnement proposĂ©es par celui-ci. Il enregistre les valeurs des indicateurs de
mesure des rĂ©sultats issus de la mise en Ɠuvre du projet et tient Ă  jour un Ă©tat des Ă©ventuelles
dérives ou non-performances constatées.
Sponsor : Il doit s’assurer essentiellement de la rĂ©alitĂ© du transfert opĂ©rationnel et de la satisfaction
du client à ce moment précis du projet. Il doit veiller à ce que cette phase ne dure pas trop
longtemps et ne soit pas l’occasion de « refaire » le projet.
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
36
9 – CLOTURER ET FAIRE LE BILAN
9.1 - Vue d’ensemble de la phase
Cette phase termine le projet. Le client doit bien entendu y ĂȘtre associĂ©. Il s’agira d’effectuer un bilan
sur l’ensemble des livrables prĂ©vus incluant les modifications prises en compte en cours de projet et
de mesurer les écarts par rapport aux livrables réalisés.
Avant la cĂ©lĂ©bration des rĂ©ussites et la dissolution effective de l’équipe projet, ses derniĂšres
rĂ©alisations seront de terminer les documents et d’évaluer le processus rĂ©ellement suivi par le projet
(appelĂ© communĂ©ment REX pour « retour d’expĂ©rience » ou « post-mortem »).
Vous trouverez ci-dessous, classées par ordre chronologique, les étapes clés de la phase « clÎturer et
faire le bilan » et les risques envisagés en cas de non application :
- Décider de clÎturer le projet. Cette décision se prend en association avec le client, sur la
base d’un bilan des livrables prĂ©vus et des livrables Ă  terminer.
Risque : paradoxalement, vouloir Ă  tout prix rĂ©aliser l’intĂ©gralitĂ© des livrables prĂ©vus
initialement ou satisfaire de façon exhaustive les demandes complémentaires du client
peut amener l’équipe projet Ă  s’épuiser sur des reliquats de « reste-Ă -faire », se
dĂ©courager et perdre en efficacitĂ©, en luciditĂ© par rapport au bienfondĂ© des requĂȘtes. En
effet, certaines demandes rĂ©siduelles peuvent s’avĂ©rer trĂšs longues et/ou coĂ»teuses, et
garder l’équipe projet trop longtemps encore mobilisĂ©e sous le prĂ©texte de « terminer »
le projet n’est pas la rĂ©ponse adaptĂ©e. Mieux vaut clore le projet et Ă©ventuellement
ouvrir un autre projet dans la foulée, en repassant par les 5 phases du cycle de vie si
nĂ©cessaire. L’approche « Agile » des projets Ă©vite en gĂ©nĂ©ral cette situation, car elle
permet de se poser la question de l’intĂ©rĂȘt d’un nouveau sprint en « objectivant » son
rapport « bénéfices/efforts ».
- Effectuer un bilan complet. Le bilan portera tant sur les livrables que sur les aspects
budgétaires et délais, ainsi que sur le processus suivi pour réaliser le projet. Ce bilan est
constituĂ© d’un Ă©tat des lieux gĂ©nĂ©ral du projet et d’un ensemble de « leçons apprises ». Le
bilan devra enfin intégrer un chapitre sur la satisfaction du client. Les questions à se poser :
‱ Quels documents garder/archiver pour le futur ? Qui, quand, comment, 

‱ Les objectifs du projet ont-ils Ă©tĂ© atteints ? Quels objectifs ne l’ont-ils pas Ă©tĂ© ?
‱ Quels ont Ă©tĂ© les coĂ»ts rĂ©els du projet, les bĂ©nĂ©fices et les dĂ©penses futures ? Quelle est
la rentabilité réelle ?
‱ Quels dĂ©lais ont Ă©tĂ© tenus, lesquels ne l’ont pas Ă©tĂ© et pourquoi ?
‱ Comment s’est dĂ©roulĂ© le processus du projet ? Quelles difficultĂ©s particuliĂšres, quelles
réussites ?
‱ Quelle est la satisfaction du client ? Comment cela est-il mesurĂ© ?
‱ Quelles leçons en tirer pour le futur ?
Risque : si ce bilan n’est pas fait, chacun va se faire une opinion subjective et les faits ne
seront pas respectĂ©s. De plus, il n’y aura pas de capitalisation de l’expĂ©rience ni
d’amĂ©lioration pour les futurs projets semblables. Il est important de bien prendre en
compte les retours des différentes parties prenantes.
- CĂ©lĂ©brer la fin du projet consiste Ă  marquer l’évĂ©nement par un moment particulier entre les
protagonistes.
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
37
Risque : ne pas prendre le temps de célébrer la fin de projet pourrait nuire à la
remobilisation des Ă©quipes sur les futurs projets. C’est en effet une façon de reconnaitre
la contribution de chacun et un formidable moyen de souder les Ă©quipes par la prise de
conscience de rĂ©alisation d’une « Ɠuvre » commune. La cĂ©lĂ©bration permettra
Ă©galement de communiquer lisiblement Ă  toutes les parties prenantes que le projet n’est
dĂ©sormais plus portĂ© par l’équipe l’ayant dĂ©veloppĂ©. La cĂ©lĂ©bration doit donc ĂȘtre
proche de la dissolution de l’équipe projet, qui clĂŽt dĂ©finitivement le projet.
9.2 - Les outils associés
Le bilan du projet est la derniùre occasion de mettre à jour le Gantt, l’analyse de risque, le suivi
budgétaire (cf. « Earned Value » Management de la valeur acquise).
La qualitĂ© a un rĂŽle prĂ©pondĂ©rant dans cette phase en s’assurant qu’elle est rĂ©ellement pratiquĂ©e et
en recueillant les éléments à suivre dans le futur en termes de management de la qualité en
fonctionnement courant.
9.3 - RÎles et responsabilités
Les principaux acteurs intéressés :
Le sponsor du projet doit s’assurer que ce bilan est prĂ©parĂ© et fait dans de bonnes conditions. Il aura
en gĂ©nĂ©ral la responsabilitĂ© de dĂ©cider et mettre en Ɠuvre les prĂ©conisations remontĂ©es lors du
bilan.
Le chef projet coordonne ce bilan et s’assure de l’implication de tous, en particulier de celle du ou
des clients (internes ou externes). Les acteurs clefs du projet, comme le client, sont associés à ce
bilan.
Le reprĂ©sentant du service qualitĂ© doit s’assurer que le processus « bilan de projet » soit bien
rĂ©alisĂ©, il doit enregistrer les besoins d’évolution, les mettre en Ɠuvre au sein des processus et
veiller Ă  leur bon fonctionnement au quotidien. Il s’assure aussi du transfert de responsabilitĂ© auprĂšs
des nouveaux responsables.
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
38
ANNEXE 1
L’annexe 1 prĂ©sente l’historique du Lean Manufacturing.
ANNEXES 2 A 7
Pour des raisons de mise en page en paysage et sous forme de tableaux, vous trouverez les annexes
2 Ă  7 Ă  la fin de notre guide (Ă  partir de la page 84).
INTRODUCTION AUX ANNEXES-OUTILS (ANNEXES 7 A 23)
L’ensemble du GBP-LPM a Ă©tĂ© Ă©crit pour les lecteurs qui souhaitent dĂ©velopper leurs connaissances
et compétences sur le Lean, appliqué à la Gestion des Projets de Transformation Organisationnelle.
Pour rappel, de tels projets sont initiés afin de faire évoluer les pratiques, les processus, les rÎles ou
les responsabilitĂ©s dans le but de corriger une non performance ou bien d’anticiper et d’atteindre un
niveau de performance souhaité.
Selon le lecteur concerné, ces annexe-outils vont permettre de :
- faire découvrir ou approfondir des outils souvent utilisés en gestion de projet,
- choisir l’outil le plus adaptĂ© Ă  la situation, selon l’étape du cycle ou selon le type de projet,
- mettre en valeur les possibilités et les limites de ces outils.
Elles ont Ă©tĂ© crĂ©Ă©es afin d’ĂȘtre accessibles Ă  tous nos lecteurs quel que soit leur niveau de
connaissance initiale.
APPROPRIATION ET UTILISATION DES OUTILS
Nous avons choisi, par expérience, de présenter ces outils dans un ordre chronologique optimal à
leur utilisation.
NĂ©anmoins nous soulignons le fait qu’ils peuvent ĂȘtre utilisĂ©s sĂ©parĂ©ment, et qu’il n’y a aucune
nécessité de tous les utiliser, et ceci pour plusieurs raisons :
- ils requiÚrent différents niveaux de maturité ;
- ils requiĂšrent diffĂ©rents dĂ©lais de mise en Ɠuvre ;
- ils sont adaptés à des projets plus ou moins agiles, plus ou moins définis.
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
39
ANNEXE 1 : METHODOLOGIES DU LEAN MANUFACTURING
Le Lean Manufacturing est une mĂ©thode visant Ă  atteindre l’excellence industrielle pour tous les
processus de l’entreprise. Elle est basĂ©e sur le principe de l’amĂ©lioration continue. Elle consiste en
une logique d’amĂ©lioration continue en progressant par petits pas (KAIZEN) et en utilisant « l’effet
cliquet », c'est-à-dire sans retour en arriÚre.
Plusieurs mĂ©thodes itĂ©ratives peuvent ĂȘtre employĂ©es, par exemple :
Le DMAIC est une méthode itérative.
A la fin de chaque projet il est possible de s’en fixer un nouveau afin de tendre vers l’excellence.
Figure 9 –Cycle DMAIC
Source : « graphique original GR LPM » 2012
D : DĂ©finir : DĂ©finition du projet et du pĂ©rimĂštre d’action du processus Ă  amĂ©liorer..
M : Mesurer : Mise en place d’indicateur de mesure de la performance du processus.
A : Analyser : Identifier les causes de dérive du processus.
I : (Improve) AmĂ©liorer : Mise en place d’un plan d’actions d’amĂ©lioration du processus.
C : ContrĂŽler : VĂ©rification de l’atteinte des objectifs, formalisation du nouveau processus et clĂŽture
projet.
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
40
Le Kaizen : Principe d’amĂ©lioration continue impliquant tous les salariĂ©s (et nĂ©cessitant donc
l’adhĂ©sion de tous) dont la dĂ©marche cohĂ©rente, procĂšde Ă©tape par Ă©tape, par sous-groupes de
travail, afin d’atteindre les objectifs suivants :
- rendre le travail plus motivant et plus efficient
- amĂ©liorer l’environnement de travail
- mettre à jour les procédures
Le PDCA ou Roue de Deming est aussi une mĂ©thode itĂ©rative d’amĂ©lioration continue
Figure 10 –PDCA et la roue de Deming
Source : « graphique original GR LPM » 2012
P : Planifier : DĂ©finir le projet sur lequel on va travailler.
D : DĂ©velopper : RĂ©alisation du projet.
C : ContrÎler : ContrÎle des prestations réalisées avec mesure de la performance.
A : Ajuster : Actions correctives et décision de lancer un nouveau projet.
La cale sous la roue de Deming Ă©vite de revenir en arriĂšre, il s’agit de la formalisation de la
capitalisation de l’expĂ©rience, du SystĂšme QualitĂ©, des audits de performance, 

GBP-LPM – 1
ÈRE
EDITION – Juin 2012
41
Voici quelques exemples d’outils frĂ©quemment utilisĂ©s dans le Lean Manufacturing :
Le 5S : Une sous-Ă©tape habituelle du kaizen est la mĂ©thode 5S oĂč l’on procĂšde en 5 Ă©tapes Ă 
amĂ©liorer l’espace de travail. Il s’agit aussi bien du poste de travail d’un atelier que d’un bureau ou
encore du bureau virtuel d’un ordinateur.
- Seiri : Supprimer => Se Ă©barrasser de tout ce qui est inutile de l’espace de travail
- Seiton : Situer les objects, => Organiser de façon efficace le nouvel espace de travail
avec définition de nouvelles rÚgles de rangement, 

- Seiso : Saleté à proscrire => Nettoyer et laisser systématiquement propre
- Seiketsu : Suivi des rĂšgles => Standardiser, mettre en place des consignes permettant
de respecter et faire perdurer les 3 Ă©tapes en amont. Identification de zones visuelles
de placement, formation du personnel, 

- Shitsuke : Satisfaire => Progresser : Cette derniĂšre Ă©tape est une Ă©tape
d’amĂ©lioration continue oĂč les salariĂ©s s’approprient les actions : responsabiliser
chacun, mise en place de contrîles, 

Les 5 « pourquoi » : La pratique des 5 pourquoi est la base d'une méthode de résolution de
problĂšmes proposĂ©e adaptable Ă  tous les processus d’une entreprise. Il s'agit de poser la question
pertinente commençant par un pourquoi afin de trouver la source, la cause principale de la
défaillance. Cette méthode de travail est surtout faite pour trouver la cause principale du problÚme
rencontré. Avec 5 questions commençant par « pourquoi », on essaie de trouver les raisons les plus
importantes ayant provoquĂ© la dĂ©faillance pour aboutir Ă  la cause principale et aider l’éradiquer.
Le Kanban : Un kanban (terme japonais signifiant « fiche » ou « étiquette ») est une simple fiche
cartonnée que l'on fixe sur les bacs ou les conteneurs de piÚces dans une ligne d'assemblage ou
une zone de stockage. Ceci est devenu une méthode qui consiste à mettre en place des affichages
pour Ă©viter la constitution d'en-cours trop importants.
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
42
ANNEXE 7 : MANAGEMENT DE RISQUE (RISK MANAGEMENT)
L’objectif /Plus-value de l’outil
 Gagner en efficacitĂ© dans la rĂ©alisation d'un projet de transformation par une dĂ©marche
d'anticipation et de prévention des risques de non atteinte des objectifs.
Cette dĂ©marche se doit d’ĂȘtre construite, simple et orientĂ©e vers l’action.
Description
Un projet se définit par ses finalités exprimées en fonctionnalités et performances, objectivées par
les niveaux des prestations Ă  atteindre. La phase de conception a pour but de choisir des principes de
solutions, et la phase de développement / implantation concrétise la transformation grùce aux plans
d'action.
Ces plans d'action engendrent des activités (et/ou processus) collectives et/ou individuelles,
lesquelles consomment des ressources humaines, matériels, financiÚres, 
 (cf. activity based costing
= Méthode des coûts par activité ).
Les risques de non aboutissement des objectifs d'un projet de transformation ont donc trois sources
potentielles, Ă  savoir :
A. Les objectifs et les niveaux de prestations inaccessibles aux dispositifs opérationnels
disponibles,
B. Des activités (et/ou processus) inopérantes,
C. Des ressources défaillantes.
DĂ©marche
Etape 1 "Le calage"
 VĂ©rifier l'adĂ©quation entre le niveau d'ambition et les activitĂ©s et ressources nĂ©cessaires.
Celui-ci peut s’avĂ©rer nĂ©cessaire mais paraĂźtre inaccessible en fonction des moyens
disponibles. Dans ce cas, la solution est de dĂ©composer l’ambition initiale en Ă©tapes
successives, fondĂ©es sur des activitĂ©s (et/ou processus) et l’emploi de ressources rĂ©alistes.
L'absence de consĂ©quences de nature stratĂ©gique doit ĂȘtre vĂ©rifiĂ©e, les dĂ©lais et coĂ»ts
supplĂ©mentaires du projet doivent ĂȘtre Ă©valuĂ©s prĂ©cisĂ©ment.
L'ensemble doit ĂȘtre formellement acceptĂ© par le sponsor du projet.
Etape 2 "L'inventaire"
Les ambitions étant calées, la méthode de management des risques consiste à analyser en anticipant
les possibilités de défaillance sur les activités (et/ou processus) ou sur les ressources.
Exemples de risques processus : non application des méthodes de la gestion de projet,
dysfonctionnement de son processus de pilotage et de décision, communication insuffisante, non-
respect des lois, 

GBP-LPM – 1
ÈRE
EDITION – Juin 2012
43
Exemples de risques sur les ressources : absence de décideur lors des comités de pilotage, manque
de moyens financiers, manque d’une compĂ©tence d'expert, 

La méthode consiste à inventorier de façon prospective les risques de défaillance pour chacune des
activités (et/ou processus) clés et pour chaque type de ressource nécessaire.
L'attention premiĂšre doit ĂȘtre portĂ©e sur les ressources uniques. Ce travail est Ă  faire en sĂ©ance
d'équipe projet, éventuellement complétée de personnes d'expérience.
Etape 3 "La priorisation"
Tous les risques n'ont pas la mĂȘme probabilitĂ© de se produire (occurrence), ni les mĂȘmes
conséquences (gravité). L'équipe d'analyse de risque définit pour chaque risque la gravité et
l'occurrence. Cette étape peut nécessiter de prendre des renseignements auprÚs de responsables
métiers ne participant pas à la réunion de travail.
Exemple d'outil :
Choix de l'Ă©chelle de cotation d’occurrence :
3 - la solution existe et peut ĂȘtre intĂ©grĂ©e ainsi dans le projet
5 - la solution existe mais demande des adaptations pour ĂȘtre
appliquée au projet
15 - la solution n'existe pas et nĂ©cessite d'ĂȘtre dĂ©veloppĂ©e.
Choix de l’échelle de cotation de gravitĂ© :
3 – une dĂ©faillance n'a pas d'impact sur les objectifs QDC du projet
5 – une dĂ©faillance peut ĂȘtre corrigĂ©e dans les marges libres du
projet
15 – une dĂ©faillance remet fortement en cause les objectifs QDC du
projet
Figure 11
Source : « graphique original GR LPM » 2012
Etape 4 "La prévention"
Les risques 225 puis 75 sont à prioriser pour construire les plans de prévention en réduction du
niveau de risques. Pour chaque risque, le chemin à parcourir étant clarifié, les plans "quoi x qui x
quand" sont documentés et gérés. Lorsque la pertinence des actions prévues sur les activités (et/ou
processus) et les ressources est remise en cause, le retour à l'étape 1 de la démarche s'impose.
Etape 5 "Le pilotage"
La gestion des risques est de dimension stratégique. A ce titre, elle fait partie du tableau de bord du
projet. Les risques majeurs et l'avancement des plans d'action en réduction sont à présenter lors de
chaque comité de pilotage projet.
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
44
Etape 6 "La mise Ă  jour"
Au fur et Ă  mesure de l'avancement du projet de transformation des Ă©vĂšnements non attendus se
produisent, des objectifs peuvent ĂȘtre recalĂ©s, et de nouvelles ambitions apparaitre. De façon
pĂ©riodique, la dĂ©marche de prĂ©vention des risques doit ĂȘtre revisitĂ©e, voire reprise. Il est du ressort
du chef de projet et de son équipe de faire vivre ce processus itératif.
Recommandations de mise en Ɠuvre
 DĂ©marche d'Ă©changes et de concertations de l'Ă©quipe projet avec son environnement.
 L'utilisation de l'outil doit rester simple en se basant avant tout sur une approche intuitive et
opérationnelle.
 Le nombre de risques gĂ©rĂ©s doit rester limitĂ©.
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
45
ANNEXE 8 : TDC - THEORIE DES CONTRAINTES (THEORIE OF CONSTRAINTS -TOC)
L’origine du terme employĂ© :
Les travaux d’E.Goldratt publiĂ©s pour la premiĂšre fois en 1984 (The Goal « Ă©dition française « Le
but ») sont Ă  l’origine de cette mĂ©thode. Selon le terme « thĂ©orie des contraintes », il propose que
tout systĂšme complexe comporte plusieurs contraintes, mais qu’il peut ĂȘtre « rendu plus efficace » Ă 
moindre effort, si l’on identifie et amĂ©liore sa « contrainte principale ».
L’objectif /Plus-value de l’outil :
Cette thĂ©orie a pour particularitĂ© notable qu’elle ne considĂšre pas les contraintes comme des
éléments négatifs du systÚme mais suggÚre de les utiliser à notre avantage.
La plus value de cet outil s’avĂšre ĂȘtre une mĂ©thode d’analyse des systĂšmes complexes pour identifier
les points principaux à améliorer.
Description :
Le cheminement d’amĂ©lioration proposĂ© est gĂ©nĂ©rique. Quelle que soit la nature du processus Ă 
améliorer, il peut se schématiser en 5 étapes clés :
1. Identifier la contrainte
2. Augmenter l’utilisation de la contrainte
3. Subordonner les autres activités à la contrainte
4. Ajuster la performance de la contrainte
5. Recommencer depuis l’étape 1 (si nĂ©cessaire)
DĂ©marche :
1 Identifier la contrainte
Dans un premier temps, l’analyse du systùme doit permettre d’identifier la contrainte principale,
c’est-Ă -dire l’étape du processus, qui, par sa lenteur supĂ©rieure, empĂȘche les autres Ă©tapes de
produire à leurs capacités maximum.
2 Augmenter l’utilisation de la contrainte
Dans un deuxiĂšme temps, il faut s’assurer que le processus actuel utilise bien l’étape-contrainte au
maximum de ses capacités de production. Dans le cas contraire, il faut en priorité prendre des
actions directes pour utiliser en permanence l’étape contrainte.
Il faut aussi s’assurer que la contrainte est « protĂ©gĂ©e », c’est-Ă -dire que toutes les Ă©tapes amont du
processus sont organisĂ©es de façon Ă  toujours alimenter l’étape-contrainte, et que celle-ci aie
toujours les ressources pour produire en permanence au maximum de sa capacité.
GBP-LPM – 1
ÈRE
EDITION – Juin 2012
46
3 Subordonner les autres activités à la contrainte
Dans un troisiĂšme temps, toutes les Ă©tapes du processus en amont de la contrainte doivent ĂȘtre
rythmĂ©es en fonction de la capacitĂ© de la contrainte, afin de ne pas prendre trop d’avance (inutile de
prendre une avance qui ne pourra ĂȘtre absorbĂ©e).
4 Ajuster la performance de la contrainte
Dans un quatriĂšme temps, une fois le processus optimisĂ© et rythmĂ©, il est temps d’analyser l’étape-
contrainte pour identifier les actions possibles permettant d’augmenter ses capacitĂ©s de production.
Il faut souligner qu’il n’aurait pas Ă©tĂ© opportun d’essayer d’augmenter la capacitĂ© de la contrainte
avant mĂȘme d’avoir optimisĂ© le processus global.
5 Recommencer depuis l’étape 1 (si nĂ©cessaire)
Une fois les quatre premiĂšres Ă©tapes terminĂ©es, il est possible de revenir Ă  l’étape n°1, pour essayer
d’identifier une nouvelle contrainte principale qui limite notre nouveau processus optimisĂ©.
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management
Lean project management

Mais conteĂșdo relacionado

Mais procurados

2005-10-17 Mathieu Kokinski OPM3 - Modele de maturite organisationnelle en ge...
2005-10-17 Mathieu Kokinski OPM3 - Modele de maturite organisationnelle en ge...2005-10-17 Mathieu Kokinski OPM3 - Modele de maturite organisationnelle en ge...
2005-10-17 Mathieu Kokinski OPM3 - Modele de maturite organisationnelle en ge...Jean Gariépy
 
Diagnostic maturité (11 septembre 2013)
Diagnostic maturité (11 septembre 2013)Diagnostic maturité (11 septembre 2013)
Diagnostic maturité (11 septembre 2013)cdpgestion
 
PMO sur un programme de l\'Etat, P3O
PMO sur un programme de l\'Etat, P3OPMO sur un programme de l\'Etat, P3O
PMO sur un programme de l\'Etat, P3OLENNY_DESCAMPS
 
Community of Practice - Project Office : Capacity management : A hot topic in...
Community of Practice - Project Office : Capacity management : A hot topic in...Community of Practice - Project Office : Capacity management : A hot topic in...
Community of Practice - Project Office : Capacity management : A hot topic in...PMI-Montréal
 
Marouane harmach et wail aaminou conduite changement pmo-ppm2013 - managemen...
Marouane harmach et wail aaminou  conduite changement pmo-ppm2013 - managemen...Marouane harmach et wail aaminou  conduite changement pmo-ppm2013 - managemen...
Marouane harmach et wail aaminou conduite changement pmo-ppm2013 - managemen...Marouane Harmach
 
Gouvernance d'un portefeuille global - Anticiper les dissonances stratégiques
Gouvernance d'un portefeuille global - Anticiper les dissonances stratégiquesGouvernance d'un portefeuille global - Anticiper les dissonances stratégiques
Gouvernance d'un portefeuille global - Anticiper les dissonances stratégiquesXAVIER HERMAN
 
CdeP GESTION ORGANISATIONNELLE DE PROJET : Diagnostic maturité (11 septembre...
CdeP GESTION ORGANISATIONNELLE DE PROJET : Diagnostic maturité (11 septembre...CdeP GESTION ORGANISATIONNELLE DE PROJET : Diagnostic maturité (11 septembre...
CdeP GESTION ORGANISATIONNELLE DE PROJET : Diagnostic maturité (11 septembre...PMI-MontrĂ©al
 
Programmes de FormAction de Quali-Scope: MENER ENSEMBLE LE CHANGEMENT (mc)
Programmes de FormAction de Quali-Scope:  MENER ENSEMBLE LE CHANGEMENT (mc)Programmes de FormAction de Quali-Scope:  MENER ENSEMBLE LE CHANGEMENT (mc)
Programmes de FormAction de Quali-Scope: MENER ENSEMBLE LE CHANGEMENT (mc)Claude Emond
 
Comment Ă©valuer la maturitĂ© organisationnelle en projet ? Cas d’Ă©tude d...
Comment Ă©valuer la maturitĂ© organisationnelle en projet ? Cas d’Ă©tude d...Comment Ă©valuer la maturitĂ© organisationnelle en projet ? Cas d’Ă©tude d...
Comment Ă©valuer la maturitĂ© organisationnelle en projet ? Cas d’Ă©tude d...PMI-MontrĂ©al
 
Pmbok 5Ă©dition change 2013
Pmbok 5Ă©dition change   2013Pmbok 5Ă©dition change   2013
Pmbok 5Ă©dition change 2013Marc Bonnemains
 
Le Projet Borealis : Quelques pratiques Scandinaves en gestion de projet
Le Projet Borealis : Quelques pratiques Scandinaves en gestion de projetLe Projet Borealis : Quelques pratiques Scandinaves en gestion de projet
Le Projet Borealis : Quelques pratiques Scandinaves en gestion de projetPMI-Montréal
 
Communauté de pratique Gestion organisationnelle - Panel sur la gestion de pr...
Communauté de pratique Gestion organisationnelle - Panel sur la gestion de pr...Communauté de pratique Gestion organisationnelle - Panel sur la gestion de pr...
Communauté de pratique Gestion organisationnelle - Panel sur la gestion de pr...PMI-Montréal
 
Pmilq colloque 2018 p. huot mise sur pied et developpement d un bureau de projet
Pmilq colloque 2018 p. huot mise sur pied et developpement d un bureau de projetPmilq colloque 2018 p. huot mise sur pied et developpement d un bureau de projet
Pmilq colloque 2018 p. huot mise sur pied et developpement d un bureau de projetPMI Lévis-Québec
 
Pmp : management des parties prenantes
Pmp : management des parties prenantesPmp : management des parties prenantes
Pmp : management des parties prenantesHassan EL ALLOUSSI
 
IDP 2015 - Atelier de 3 jours - Gestion agile des projets d'innovation (4, 9 ...
IDP 2015 - Atelier de 3 jours - Gestion agile des projets d'innovation (4, 9 ...IDP 2015 - Atelier de 3 jours - Gestion agile des projets d'innovation (4, 9 ...
IDP 2015 - Atelier de 3 jours - Gestion agile des projets d'innovation (4, 9 ...Claude Emond
 
Symposium 2016 : CONF. 202 Charles Bourgault, Marie-Claude Perras & Yvan Pelc...
Symposium 2016 : CONF. 202 Charles Bourgault, Marie-Claude Perras & Yvan Pelc...Symposium 2016 : CONF. 202 Charles Bourgault, Marie-Claude Perras & Yvan Pelc...
Symposium 2016 : CONF. 202 Charles Bourgault, Marie-Claude Perras & Yvan Pelc...PMI-Montréal
 
AEDIAN - BaromÚtre PMO résumé
AEDIAN - BaromÚtre PMO résuméAEDIAN - BaromÚtre PMO résumé
AEDIAN - BaromÚtre PMO résuméAEDIANmarketing
 
CONF. 204 - Conditions et mise en Ɠuvre des bĂ©nĂ©fices d’un projet Agile
CONF. 204 - Conditions et mise en Ɠuvre des bĂ©nĂ©fices d’un projet AgileCONF. 204 - Conditions et mise en Ɠuvre des bĂ©nĂ©fices d’un projet Agile
CONF. 204 - Conditions et mise en Ɠuvre des bĂ©nĂ©fices d’un projet AgilePMI-MontrĂ©al
 
Le PMBOK n'est pas agile ?, ben voyons donc !!!
Le PMBOK n'est pas agile ?, ben voyons donc !!! Le PMBOK n'est pas agile ?, ben voyons donc !!!
Le PMBOK n'est pas agile ?, ben voyons donc !!! PMI-Montréal
 

Mais procurados (20)

2005-10-17 Mathieu Kokinski OPM3 - Modele de maturite organisationnelle en ge...
2005-10-17 Mathieu Kokinski OPM3 - Modele de maturite organisationnelle en ge...2005-10-17 Mathieu Kokinski OPM3 - Modele de maturite organisationnelle en ge...
2005-10-17 Mathieu Kokinski OPM3 - Modele de maturite organisationnelle en ge...
 
Diagnostic maturité (11 septembre 2013)
Diagnostic maturité (11 septembre 2013)Diagnostic maturité (11 septembre 2013)
Diagnostic maturité (11 septembre 2013)
 
PMO sur un programme de l\'Etat, P3O
PMO sur un programme de l\'Etat, P3OPMO sur un programme de l\'Etat, P3O
PMO sur un programme de l\'Etat, P3O
 
Community of Practice - Project Office : Capacity management : A hot topic in...
Community of Practice - Project Office : Capacity management : A hot topic in...Community of Practice - Project Office : Capacity management : A hot topic in...
Community of Practice - Project Office : Capacity management : A hot topic in...
 
Marouane harmach et wail aaminou conduite changement pmo-ppm2013 - managemen...
Marouane harmach et wail aaminou  conduite changement pmo-ppm2013 - managemen...Marouane harmach et wail aaminou  conduite changement pmo-ppm2013 - managemen...
Marouane harmach et wail aaminou conduite changement pmo-ppm2013 - managemen...
 
Gouvernance d'un portefeuille global - Anticiper les dissonances stratégiques
Gouvernance d'un portefeuille global - Anticiper les dissonances stratégiquesGouvernance d'un portefeuille global - Anticiper les dissonances stratégiques
Gouvernance d'un portefeuille global - Anticiper les dissonances stratégiques
 
CdeP GESTION ORGANISATIONNELLE DE PROJET : Diagnostic maturité (11 septembre...
CdeP GESTION ORGANISATIONNELLE DE PROJET : Diagnostic maturité (11 septembre...CdeP GESTION ORGANISATIONNELLE DE PROJET : Diagnostic maturité (11 septembre...
CdeP GESTION ORGANISATIONNELLE DE PROJET : Diagnostic maturité (11 septembre...
 
Programmes de FormAction de Quali-Scope: MENER ENSEMBLE LE CHANGEMENT (mc)
Programmes de FormAction de Quali-Scope:  MENER ENSEMBLE LE CHANGEMENT (mc)Programmes de FormAction de Quali-Scope:  MENER ENSEMBLE LE CHANGEMENT (mc)
Programmes de FormAction de Quali-Scope: MENER ENSEMBLE LE CHANGEMENT (mc)
 
Comment Ă©valuer la maturitĂ© organisationnelle en projet ? Cas d’Ă©tude d...
Comment Ă©valuer la maturitĂ© organisationnelle en projet ? Cas d’Ă©tude d...Comment Ă©valuer la maturitĂ© organisationnelle en projet ? Cas d’Ă©tude d...
Comment Ă©valuer la maturitĂ© organisationnelle en projet ? Cas d’Ă©tude d...
 
Pmbok 5Ă©dition change 2013
Pmbok 5Ă©dition change   2013Pmbok 5Ă©dition change   2013
Pmbok 5Ă©dition change 2013
 
Le Projet Borealis : Quelques pratiques Scandinaves en gestion de projet
Le Projet Borealis : Quelques pratiques Scandinaves en gestion de projetLe Projet Borealis : Quelques pratiques Scandinaves en gestion de projet
Le Projet Borealis : Quelques pratiques Scandinaves en gestion de projet
 
Communauté de pratique Gestion organisationnelle - Panel sur la gestion de pr...
Communauté de pratique Gestion organisationnelle - Panel sur la gestion de pr...Communauté de pratique Gestion organisationnelle - Panel sur la gestion de pr...
Communauté de pratique Gestion organisationnelle - Panel sur la gestion de pr...
 
Pmilq colloque 2018 p. huot mise sur pied et developpement d un bureau de projet
Pmilq colloque 2018 p. huot mise sur pied et developpement d un bureau de projetPmilq colloque 2018 p. huot mise sur pied et developpement d un bureau de projet
Pmilq colloque 2018 p. huot mise sur pied et developpement d un bureau de projet
 
00 contexte gén management de l'intégration
00 contexte gén   management de l'intégration00 contexte gén   management de l'intégration
00 contexte gén management de l'intégration
 
Pmp : management des parties prenantes
Pmp : management des parties prenantesPmp : management des parties prenantes
Pmp : management des parties prenantes
 
IDP 2015 - Atelier de 3 jours - Gestion agile des projets d'innovation (4, 9 ...
IDP 2015 - Atelier de 3 jours - Gestion agile des projets d'innovation (4, 9 ...IDP 2015 - Atelier de 3 jours - Gestion agile des projets d'innovation (4, 9 ...
IDP 2015 - Atelier de 3 jours - Gestion agile des projets d'innovation (4, 9 ...
 
Symposium 2016 : CONF. 202 Charles Bourgault, Marie-Claude Perras & Yvan Pelc...
Symposium 2016 : CONF. 202 Charles Bourgault, Marie-Claude Perras & Yvan Pelc...Symposium 2016 : CONF. 202 Charles Bourgault, Marie-Claude Perras & Yvan Pelc...
Symposium 2016 : CONF. 202 Charles Bourgault, Marie-Claude Perras & Yvan Pelc...
 
AEDIAN - BaromÚtre PMO résumé
AEDIAN - BaromÚtre PMO résuméAEDIAN - BaromÚtre PMO résumé
AEDIAN - BaromÚtre PMO résumé
 
CONF. 204 - Conditions et mise en Ɠuvre des bĂ©nĂ©fices d’un projet Agile
CONF. 204 - Conditions et mise en Ɠuvre des bĂ©nĂ©fices d’un projet AgileCONF. 204 - Conditions et mise en Ɠuvre des bĂ©nĂ©fices d’un projet Agile
CONF. 204 - Conditions et mise en Ɠuvre des bĂ©nĂ©fices d’un projet Agile
 
Le PMBOK n'est pas agile ?, ben voyons donc !!!
Le PMBOK n'est pas agile ?, ben voyons donc !!! Le PMBOK n'est pas agile ?, ben voyons donc !!!
Le PMBOK n'est pas agile ?, ben voyons donc !!!
 

Semelhante a Lean project management

PMO VALUE RING - Complete presentation (Fr-CAN1).pdf
PMO VALUE RING - Complete presentation (Fr-CAN1).pdfPMO VALUE RING - Complete presentation (Fr-CAN1).pdf
PMO VALUE RING - Complete presentation (Fr-CAN1).pdfDAHRAOUI Med Riad
 
CONF. 203 – Agile et le bureau de projet
CONF. 203 – Agile et le bureau de projetCONF. 203 – Agile et le bureau de projet
CONF. 203 – Agile et le bureau de projetPMI-MontrĂ©al
 
Management de projet agile vs classique pmi atlantic 20120322
Management de projet agile vs classique pmi atlantic 20120322Management de projet agile vs classique pmi atlantic 20120322
Management de projet agile vs classique pmi atlantic 20120322Jean-Luc MAZE
 
10674427.ppt
10674427.ppt10674427.ppt
10674427.pptDsireAttmn
 
Définir et piloter la stratégie de déploiement de votre grand programme de tr...
Définir et piloter la stratégie de déploiement de votre grand programme de tr...Définir et piloter la stratégie de déploiement de votre grand programme de tr...
Définir et piloter la stratégie de déploiement de votre grand programme de tr...Pvalconseil2016
 
Les diffĂ©rents mĂ©thodes d’évolution du projet.pptx
Les diffĂ©rents mĂ©thodes d’évolution du projet.pptxLes diffĂ©rents mĂ©thodes d’évolution du projet.pptx
Les diffĂ©rents mĂ©thodes d’évolution du projet.pptxtaiebamin1
 
Les diffĂ©rents mĂ©thodes d’évolution du projet.pptx
Les diffĂ©rents mĂ©thodes d’évolution du projet.pptxLes diffĂ©rents mĂ©thodes d’évolution du projet.pptx
Les diffĂ©rents mĂ©thodes d’évolution du projet.pptxtaiebamin1
 
Présentation 2019 du partenariat de recherche Aurore
Présentation 2019 du partenariat de recherche AurorePrésentation 2019 du partenariat de recherche Aurore
Présentation 2019 du partenariat de recherche AurorePierre Disarbois
 
Partenariat de recherche aurore 2019 daylight consulting
Partenariat de recherche aurore 2019 daylight consultingPartenariat de recherche aurore 2019 daylight consulting
Partenariat de recherche aurore 2019 daylight consultingPierre Disarbois
 
Présentation projeo conseil_simplifié
Présentation projeo conseil_simplifiéPrésentation projeo conseil_simplifié
Présentation projeo conseil_simplifiéPauline SEMELIER
 
Comment redresser la crédibilité d'un Bureau de projets?
Comment redresser la crédibilité d'un Bureau de projets?Comment redresser la crédibilité d'un Bureau de projets?
Comment redresser la crédibilité d'un Bureau de projets?PMI-Montréal
 
Introduction de la gestion de projet Agile au sein de l’équipe RĂ©seau de Bell...
Introduction de la gestion de projet Agile au sein de l’équipe RĂ©seau de Bell...Introduction de la gestion de projet Agile au sein de l’équipe RĂ©seau de Bell...
Introduction de la gestion de projet Agile au sein de l’équipe RĂ©seau de Bell...PMI-MontrĂ©al
 
Edias - Tutorat - rapport - mars 2018
Edias - Tutorat - rapport - mars 2018Edias - Tutorat - rapport - mars 2018
Edias - Tutorat - rapport - mars 2018Guillaume BROUSSEAU
 
Accélérateur PME
Accélérateur PMEAccélérateur PME
Accélérateur PMEBpifrance
 
PMO: Les notions de base
PMO: Les notions de basePMO: Les notions de base
PMO: Les notions de baseElyes Grar
 
Comment concilier agilité et conception centrée utilisateurs dans un projet d...
Comment concilier agilité et conception centrée utilisateurs dans un projet d...Comment concilier agilité et conception centrée utilisateurs dans un projet d...
Comment concilier agilité et conception centrée utilisateurs dans un projet d...louschwartz
 
Matinée PMI L'APPROCHE D'ARCHITECTURE D'AFFAIRES POUR ASSURER L'ALIGNEMENT DU...
Matinée PMI L'APPROCHE D'ARCHITECTURE D'AFFAIRES POUR ASSURER L'ALIGNEMENT DU...Matinée PMI L'APPROCHE D'ARCHITECTURE D'AFFAIRES POUR ASSURER L'ALIGNEMENT DU...
Matinée PMI L'APPROCHE D'ARCHITECTURE D'AFFAIRES POUR ASSURER L'ALIGNEMENT DU...PMI-Montréal
 
La gestion de projet LEAN
La gestion de projet LEANLa gestion de projet LEAN
La gestion de projet LEANClaude Emond
 
Organisation et management du projet
Organisation et management du projetOrganisation et management du projet
Organisation et management du projetDonkichotte
 

Semelhante a Lean project management (20)

PMO VALUE RING - Complete presentation (Fr-CAN1).pdf
PMO VALUE RING - Complete presentation (Fr-CAN1).pdfPMO VALUE RING - Complete presentation (Fr-CAN1).pdf
PMO VALUE RING - Complete presentation (Fr-CAN1).pdf
 
CONF. 203 – Agile et le bureau de projet
CONF. 203 – Agile et le bureau de projetCONF. 203 – Agile et le bureau de projet
CONF. 203 – Agile et le bureau de projet
 
Management de projet agile vs classique pmi atlantic 20120322
Management de projet agile vs classique pmi atlantic 20120322Management de projet agile vs classique pmi atlantic 20120322
Management de projet agile vs classique pmi atlantic 20120322
 
10674427.ppt
10674427.ppt10674427.ppt
10674427.ppt
 
Définir et piloter la stratégie de déploiement de votre grand programme de tr...
Définir et piloter la stratégie de déploiement de votre grand programme de tr...Définir et piloter la stratégie de déploiement de votre grand programme de tr...
Définir et piloter la stratégie de déploiement de votre grand programme de tr...
 
Les diffĂ©rents mĂ©thodes d’évolution du projet.pptx
Les diffĂ©rents mĂ©thodes d’évolution du projet.pptxLes diffĂ©rents mĂ©thodes d’évolution du projet.pptx
Les diffĂ©rents mĂ©thodes d’évolution du projet.pptx
 
Les diffĂ©rents mĂ©thodes d’évolution du projet.pptx
Les diffĂ©rents mĂ©thodes d’évolution du projet.pptxLes diffĂ©rents mĂ©thodes d’évolution du projet.pptx
Les diffĂ©rents mĂ©thodes d’évolution du projet.pptx
 
Présentation 2019 du partenariat de recherche Aurore
Présentation 2019 du partenariat de recherche AurorePrésentation 2019 du partenariat de recherche Aurore
Présentation 2019 du partenariat de recherche Aurore
 
Partenariat de recherche aurore 2019 daylight consulting
Partenariat de recherche aurore 2019 daylight consultingPartenariat de recherche aurore 2019 daylight consulting
Partenariat de recherche aurore 2019 daylight consulting
 
Présentation projeo conseil_simplifié
Présentation projeo conseil_simplifiéPrésentation projeo conseil_simplifié
Présentation projeo conseil_simplifié
 
Comment redresser la crédibilité d'un Bureau de projets?
Comment redresser la crédibilité d'un Bureau de projets?Comment redresser la crédibilité d'un Bureau de projets?
Comment redresser la crédibilité d'un Bureau de projets?
 
Introduction de la gestion de projet Agile au sein de l’équipe RĂ©seau de Bell...
Introduction de la gestion de projet Agile au sein de l’équipe RĂ©seau de Bell...Introduction de la gestion de projet Agile au sein de l’équipe RĂ©seau de Bell...
Introduction de la gestion de projet Agile au sein de l’équipe RĂ©seau de Bell...
 
Edias - Tutorat - rapport - mars 2018
Edias - Tutorat - rapport - mars 2018Edias - Tutorat - rapport - mars 2018
Edias - Tutorat - rapport - mars 2018
 
Accélérateur PME
Accélérateur PMEAccélérateur PME
Accélérateur PME
 
Methode Agile
Methode Agile Methode Agile
Methode Agile
 
PMO: Les notions de base
PMO: Les notions de basePMO: Les notions de base
PMO: Les notions de base
 
Comment concilier agilité et conception centrée utilisateurs dans un projet d...
Comment concilier agilité et conception centrée utilisateurs dans un projet d...Comment concilier agilité et conception centrée utilisateurs dans un projet d...
Comment concilier agilité et conception centrée utilisateurs dans un projet d...
 
Matinée PMI L'APPROCHE D'ARCHITECTURE D'AFFAIRES POUR ASSURER L'ALIGNEMENT DU...
Matinée PMI L'APPROCHE D'ARCHITECTURE D'AFFAIRES POUR ASSURER L'ALIGNEMENT DU...Matinée PMI L'APPROCHE D'ARCHITECTURE D'AFFAIRES POUR ASSURER L'ALIGNEMENT DU...
Matinée PMI L'APPROCHE D'ARCHITECTURE D'AFFAIRES POUR ASSURER L'ALIGNEMENT DU...
 
La gestion de projet LEAN
La gestion de projet LEANLa gestion de projet LEAN
La gestion de projet LEAN
 
Organisation et management du projet
Organisation et management du projetOrganisation et management du projet
Organisation et management du projet
 

Último

Algo II: les files cours + exercices corrigés
Algo II: les files cours + exercices corrigésAlgo II: les files cours + exercices corrigés
Algo II: les files cours + exercices corrigésSana REFAI
 
le probleme de la planification JSP exposee (2) (2).pptx
le probleme de la planification JSP exposee (2) (2).pptxle probleme de la planification JSP exposee (2) (2).pptx
le probleme de la planification JSP exposee (2) (2).pptximaneeaouattahee
 
pdfcoffee.com_4-production-fond-des-puits-completion-pdf-free.pdf
pdfcoffee.com_4-production-fond-des-puits-completion-pdf-free.pdfpdfcoffee.com_4-production-fond-des-puits-completion-pdf-free.pdf
pdfcoffee.com_4-production-fond-des-puits-completion-pdf-free.pdfMedAbdelhayeSidiAhme
 
Présentation_Soirée-Information_ Surverse_Thibert _30 avril 2024
Présentation_Soirée-Information_ Surverse_Thibert _30 avril 2024Présentation_Soirée-Information_ Surverse_Thibert _30 avril 2024
Présentation_Soirée-Information_ Surverse_Thibert _30 avril 2024Ville de Chùteauguay
 
mémoire genie civil presenté lors de la soutenance de mémoire
mémoire genie civil presenté lors de la soutenance de mémoiremémoire genie civil presenté lors de la soutenance de mémoire
mémoire genie civil presenté lors de la soutenance de mémoireEzechiasSteel
 

Último (6)

Algo II: les files cours + exercices corrigés
Algo II: les files cours + exercices corrigésAlgo II: les files cours + exercices corrigés
Algo II: les files cours + exercices corrigés
 
JTC 2024 BĂątiment et PhotovoltaĂŻque.pdf
JTC 2024  BĂątiment et PhotovoltaĂŻque.pdfJTC 2024  BĂątiment et PhotovoltaĂŻque.pdf
JTC 2024 BĂątiment et PhotovoltaĂŻque.pdf
 
le probleme de la planification JSP exposee (2) (2).pptx
le probleme de la planification JSP exposee (2) (2).pptxle probleme de la planification JSP exposee (2) (2).pptx
le probleme de la planification JSP exposee (2) (2).pptx
 
pdfcoffee.com_4-production-fond-des-puits-completion-pdf-free.pdf
pdfcoffee.com_4-production-fond-des-puits-completion-pdf-free.pdfpdfcoffee.com_4-production-fond-des-puits-completion-pdf-free.pdf
pdfcoffee.com_4-production-fond-des-puits-completion-pdf-free.pdf
 
Présentation_Soirée-Information_ Surverse_Thibert _30 avril 2024
Présentation_Soirée-Information_ Surverse_Thibert _30 avril 2024Présentation_Soirée-Information_ Surverse_Thibert _30 avril 2024
Présentation_Soirée-Information_ Surverse_Thibert _30 avril 2024
 
mémoire genie civil presenté lors de la soutenance de mémoire
mémoire genie civil presenté lors de la soutenance de mémoiremémoire genie civil presenté lors de la soutenance de mémoire
mémoire genie civil presenté lors de la soutenance de mémoire
 

Lean project management

  • 1. GUIDE DES BONNES PRATIQUES DU LEAN PROJECT MANAGEMENT AppliquĂ© Ă  la gestion des projets de transformation RĂ©alisĂ© par : Groupe de RĂ©flexion Lean Project Management Sur les chemins de Grande RandonnĂ©e du Management

  • 2. GBP-LPM – 1 ÈRE EDITION – Juin 2012 2 PREAMBULE M o d e d ’ e m p l o i : Pour favoriser la comprĂ©hension des diffĂ©rents sujets traitĂ©s et vous permettre de mieux apprĂ©cier les termes et concepts contenus dans ce guide, nous avons choisi de faire des liens vers : - les annexes : Qui developpement certains contextes en rapport direct avec ce guide ; - le « Lexique Glossaire du Management » qui renvoie vers d’autres, termes et supports. L e s V e r s i o n s d u G B P - L P M : Ce document s’intitule « Guide des Bonnes Pratiques du Lean Project Management » (GBP-LPM ) – PremiĂšre Ă©dition. Nous invitons nos lecteurs Ă  nous faire part de leurs apprĂ©ciations positives et/ou de leurs propositions d'amĂ©lioration de ce Guide, sachant qu’un site Internet sera dĂ©diĂ© Ă  cet objectif d’interaction et de partage. GrĂące Ă  vos contributions, nous espĂ©rons qu'un GBP-LPM – DeuxiĂšme Ă©dition pourra ĂȘtre publiĂ© dans un avenir proche. Ce Guide a Ă©tĂ© rĂ©alisĂ© par un groupe de bĂ©nĂ©voles qui ont ƓuvrĂ© pour en dĂ©livrer cette premiĂšre Ă©dition. Si ce sujet vous intĂ©resse et si vous souhaitez transmettre vos connaissances, n'hĂ©sitez pas Ă  nous contacter via le site Internet. Peut-ĂȘtre pourriez-vous envisager de participer Ă  la prochaine Ă©dition du GBP-LPM, voire de crĂ©er, Ă  votre initiative, un nouveau groupe de bĂ©nĂ©voles
 ?! Au plaisir de lire vos apprĂ©ciations et contributions ! . Pour plus d’information sur les droits de Creative Commons, suivez le lien Creative Commons Nous vous demandons d’utiliser ce Guide et de le diffuser selon les droits de Creative Commons : - gardez toujours la mention des auteurs de la premiĂšre Ă©dition ; - ne modifiez le contenu qu’en respectant la cohĂ©rence avec la premiĂšre Ă©dition ; - ne vendez pas ce premier Guide et les futures Ă©ditions ; - gardez les mĂȘmes conditions Creative Commons pour les futures Ă©ditions.
  • 3. GBP-LPM – 1 ÈRE EDITION – Juin 2012 3 GenĂšse du GR-LPM (Groupe de RĂ©flexion Lean Project Management) Le GBP-LPM est l'aboutissement d’une vĂ©ritable dĂ©marche collaborative rĂ©alisĂ©e par des acteurs bĂ©nĂ©voles, motivĂ©s, totalement indĂ©pendants les uns des autres, pourtant concepteurs et porteurs de ce projet. Une telle collaboration s'appuie sur un moteur : l’envie de partager en groupe (GR-LPM) des expĂ©riences et des compĂ©tences pour les mettre gracieusement Ă  disposition de tous ceux qui le souhaitent, notamment sous la forme d’un « Guide des Bonnes Pratiques en Lean Project Management » (GBP–LPM). Le 30 mars 2010, Ă  l’issue d’une confĂ©rence organisĂ©e par Erick ATHIER, fondateur associĂ© d’IQAR, Dominique GARRET, soutien de l’évĂšnement en qualitĂ© de reprĂ©sentant du « PMI-Project Management Institute France-Sud Chapter », propose de crĂ©er un groupe de rĂ©flexion sur le « Lean Project Management ». Cette idĂ©e rencontre une Ă©coute favorable et de vraies attentes. Les membres du groupe s'accordent sur une charte du GR-LPM, qui repose sur les deux principes suivants : - le partage des connaissances et leur transmission Ă  un plus large public, notamment Ă  l’occasion d’une confĂ©rence ; - une Ă©quipe de rĂ©flexion et de travail constituĂ©e de personnes indĂ©pendantes, volontaires et bĂ©nĂ©voles, motivĂ©es par la pratique du travail collaboratif. Le Groupe de RĂ©flexion Lean Project Management est constituĂ© : 1. des membres permanents du GR-LPM : Pendant plus d'un an, les investissements personnels des contributeurs alimentent les travaux du GR-LPM. Au fil des rĂ©unions mensuelles, le croisement des expĂ©riences de chacun au travers des Ă©crits sur les thĂšmes retenus permet de construire petit Ă  petit le prĂ©sent GBP-LPM. Ont contribuĂ© Ă  ces travaux : Marie-France PORTIER Bruno MOUESCA AndrĂ© CHAVEL MichaĂ«l DUCRET HervĂ© ROUTON Christian GUERIN 2. du Pilote du GR-LPM et expert en la matiĂšre - Intervenant bĂ©nĂ©vole : Erick ATHIER Dirigeant Fondateur et associĂ© d’IQar MBA – Manager de Projet CertifiĂ© PMPÂź 3. de l’initiateur du GR-LPM et observateur – Soutien bĂ©nĂ©vole : Dominique GARRET Dirigeant fondateur d’AXcion Auteur du «Lexique Glossaire d Management » Administrateur du PMI Chapitre France-Sud 4. d’organismes parrains :
  • 4. GBP-LPM – 1 ÈRE EDITION – Juin 2012 4 AFPI (Association de Formation Professionnelle de l’Industrie), reprĂ©sentĂ©e par FrĂ©dĂ©ric GAUTHIER, responsable PĂŽle Formation continue. Nous remercions L’AFPI pour les locaux mis Ă  disposition Ă  l’occasion des rĂ©unions physiques et pour la confĂ©rence du 24/11/11. PMI-Project Management Institute – Branche RhĂŽne-Alpes, reprĂ©sentĂ© par Bruno LAUDE, PrĂ©sident de la branche RhĂŽne-Alpes et VP du Chapitre France-Sud, et par Bernard AVRIL, Administrateur PMI Chapitre FS, chef de projet pour la confĂ©rence du 24/11/11 REMERCIEMENTS : Nous tenons Ă  remercier tout particuliĂšrement CĂ©line GROSJEAN, transcriptrice libĂ©rale (1 rue LUIZET 69130 Ecully), qui nous a apportĂ©, gracieusement, son savoir-faire pour la mise en forme du GBP-LPM. Nous remercions Ă©galement Liying ZHOU pour la crĂ©ation de plusieurs illustrations du GBP-LPM.
  • 5. GBP-LPM – 1 ÈRE EDITION – Juin 2012 5 PĂ©rimĂštre d’application du GBP-LPM Le « Guide de Bonnes Pratiques du Lean Project Management », dĂ©signĂ© sous le vocable GBP-LPM, a pour objectif principal de reprĂ©senter un support de rĂ©fĂ©rence pour les acteurs de la gestion de projets souhaitant dĂ©velopper leurs connaissances et leurs compĂ©tences du Lean appliquĂ© Ă  la Gestion des Projets de Transformation Organisationnelle. Parmi ces diffĂ©rents acteurs, se distinguent : - les Sponsors (promoteurs, maitres d’ouvrage, bĂ©nĂ©ficiaires) de la dĂ©marche Lean Project Management (LPM) amenĂ©s Ă  Ă©tudier l’opportunitĂ© d’un projet, Ă  promouvoir ou appuyer la mise en Ɠuvre du LPM dans son environnement ; - les Managers et membres des Ă©quipes de projets, qui, composĂ©s principalement d’opĂ©rationnels, sont dans l’obligation d’optimiser leur mĂ©thode et outils de gestion de projets. Le GBP-LPM aura donc pour but de devenir d’abord un instrument d’acquisition de compĂ©tences, puis de rĂ©fĂ©rence mĂ©thodologique dans la conduite des projets. Le GBP-LPM est dĂ©diĂ© aux projets de « Transformations Organisationnelles ». Un projet de transformation organisationnelle est un projet initiĂ© au sein d’une organisation (entreprise, association, service public, etc.) pour faire Ă©voluer les pratiques, les processus, les outils, les rĂŽles ou les responsabilitĂ©s, et, au bout du compte, la compĂ©tence collective dans le but d'amĂ©liorer ses performances organisationnelles en cohĂ©rence avec les objectifs stratĂ©giques fixĂ©s. De tels projets ont en commun les caractĂ©ristiques suivantes : - ils ont Ă  leur tĂȘte un Sponsor (propriĂ©taire du processus Ă  crĂ©er, Ă  supprimer ou Ă  transformer) clairement identifiĂ© ; - ils contribuent et s’inscrivent dans une dĂ©marche globale d’entreprise ; - ils intĂšgrent nĂ©cessairement une part de conduite de changement et modifient gĂ©nĂ©ralement les pĂ©rimĂštres de responsabilitĂ©s ; - ils sont limitĂ©s dans le temps et dotĂ©s de contraintes qui peuvent et doivent ĂȘtre Ă©tablies relativement tĂŽt dans le processus de gestion du projet. Plus de dĂ©tails sont donnĂ©s dans les chapitres suivants du GBP-LPM. Voici cependant quelques exemples de projets de transformations : - fusion – acquisition – intĂ©gration ; - mise en place d’un nouvel outil de production, de nouvelles mĂ©thodes de travail ; - informatisation d’un processus d’affaires ; - dĂ©ploiement gĂ©ographique d’activitĂ©s de services ou de production ; - 

  • 6. GBP-LPM – 1 ÈRE EDITION – Juin 2012 6 « Selon IBM et dans le cadre du CEO Study (enquĂȘte menĂ©e auprĂšs de 1 130 dirigeants de grandes entreprises dans le monde et publiĂ©e en mai 2008), l’entreprise de demain sera avide de changements. Cependant, la plupart des dirigeants interrogĂ©s sont peu confiants dans la capacitĂ© de leur entreprise Ă  mettre en Ɠuvre les changements nĂ©cessaires. Le « change gap » (Ă©cart entre les changements attendus par les dirigeants et leur perception de la capacitĂ© de leur entreprise Ă  y faire face) a quasiment triplĂ© depuis 2006, poussant de nombreux dirigeants Ă  lutter pour maintenir la croissance et la stabilitĂ© de leurs entreprises ». C’est certain, il y aura de nombreux projets de transformation organisationnelle Ă  rĂ©ussir demain, peut-ĂȘtre plus qu’aujourd’hui. Les fondements des principes mĂ©thodologiques prĂ©sentĂ©s dans le GBP-LPM concernent la rĂ©ussite du changement dans les organisations humaines. Leur cadre d'application est donc plus large que les projets de transformation organisationnelle. Ces principes se retrouvent par exemple dans l'industrie Ă  travers la conduite des projets de rĂ©duction de coĂ»t impliquant de la reconception des produits et des process. Il appartiendra aux lecteurs de s’en inspirer. Notre ambition au travers de ce guide est de partager avec les lecteurs et les professionnels de la conduite du changement notre comprĂ©hension de la complĂ©mentaritĂ© des concepts structurants et des pratiques de pilotage en mode projet, de la dĂ©marche Lean et des mĂ©thodes Agile. Bonne lecture !
  • 7. GBP-LPM – 1 ÈRE EDITION – Juin 2012 7 SOMMAIRE 1 - LE LEAN MANUFACTURING 9 1.1 – Historique et dĂ©finition 9 1.2 - Objectifs 10 1.3 – Les facteurs de succĂšs ou niveaux d’analyse 11 2 – L’AGILE 12 2.1 – La gestion de projets « Agile » 12 2.2 – Les limites et l’ouverture vers le Lean Project Management 14 3 – LEAN PROJECT MANAGEMENT 15 3.1 - Les 10 causes de pertes d’efficacitĂ© en gestion de projets 15 3.2 – L’efficacitĂ© par la maĂźtrise de la valeur 18 4 - LES FACTEURS DE SUCCÈS POUR RÉUSSIR UN PROJET DE TRANSFORMATION 19 5 - FORMALISER L’IDÉE DU PROJET 23 5.1 – Vue d’ensemble de la phase 23 5.2 – Les outils associĂ©s 24 5.3 – RĂŽles et responsabilitĂ©s 24 6 - INNOVER ET S’ENGAGER 25 6.1 - Vue d’ensemble de la phase 25 6.2 - Les outils associĂ©s 28 6.3 - RĂŽles et responsabilitĂ©s 28 7 - METTRE EN ƒUVRE 30 7.1 - Vue d’ensemble de la phase 30 7.2 - Les outils associĂ©s 30 7.3 - RĂŽles et responsabilitĂ©s 32 8 - TRANSFÉRER LES RESPONSABILITÉS 33 8.1 - Vue d’ensemble de la phase 33 8.2 - Les outils associĂ©s 34 8.3 - RĂŽles et responsabilitĂ©s 34 9 – CLÔTURER ET FAIRE LE BILAN 36 9.1 - Vue d’ensemble de la phase 36 9.2 - Les outils associĂ©s 37 9.3 - RĂŽles et responsabilitĂ©s 37 ANNEXE 1 38 ANNEXES 2 À 7 38 INTRODUCTION AUX ANNEXES-OUTILS (ANNEXES 7 À 23) 38
  • 8. GBP-LPM – 1 ÈRE EDITION – Juin 2012 8 APPROPRIATION ET UTILISATION DES OUTILS 38 ANNEXE 1 : MÉTHODOLOGIES DU LEAN MANUFACTURING 39 ANNEXE 7 : MANAGEMENT DE RISQUE (RISK MANAGEMENT) 42 ANNEXE 8 : TDC - THÉORIE DES CONTRAINTES (TOC) 45 ANNEXE 9 : OUTILS DE LA MESURE ET DE L’ANALYSE QUALITÉ 47 ANNEXE 10 : MODELE DE COTATION (SCORING MODEL) 52 ANNEXE 11 : SMART (AIDE À LA DÉFINITION D’UN OBJECTIF OU D’UN INDICATEUR) 54 ANNEXE 12 : QPQQCOC 55 ANNEXE 13 : LE PROCESSUS DE CRÉATIVITÉ 57 ANNEXE 14 : REMUE MÉNINGES (BRAINSTORMING) 58 OUTILS DE PLANNIFICATION & PILOTAGE APPROPRIATION ET UTILISATION DES OUTILS 59 ANNEXE 15 : PLANIFICATION PAR VAGUES (ROLLING WAVE PLANNING) 60 ANNEXE 16 : DERNIER PLANIFICATEUR (LPS - LAST PLANNER SYSTEM) 62 ANNEXE 17 : SDP - STRUCTURE DE DÉCOUPAGE DU PROJET (WBS) 63 ANNEXE 18 : PERT - PROGRAM EVALUATION & REVIEW TECHNIQUE 66 ANNEXE 19 : GANTT 68 ANNEXE 20 : CHAINE CRITIQUE 70 ANNEXE 21 : MVA – MANAGEMENT PAR LA VALEUR ACQUISE (EVM - EARNED VALUE MANAGEMENT) 72 ANNEXE 22 : MODÈLE DE PILOTAGE PROJET SCRUM 75 ANNEXE 23 : ESPACE COLLABORATIF (OBEYA ROOM / WAR ROOM) 77 ANNEXE 24 : PARALLÈLE ENTRE LES SOURCES DE GASPILLAGES DU LEAN ET LES PERTES EN GESTION DE PROJETS 79 ANNEXE 2 : CYCLE DE VIE, PHASE : « FORMALISER L’IDÉEE DU PROJET » 80 ANNEXE 3 : CYCLE DE VIE, PHASE : « INNOVER ET S’ENGAGER » 81 ANNEXE 4 : CYCLE DE VIE, PHASE : « METTRE EN ƒUVRE » 83 ANNEXE 5 : CYCLE DE VIE, PHASE : « TRANSFÉRER LES RESPONSABILITÉS » 85 ANNEXE 6 : CYCLE DE VIE, PHASE : ‘CLÔTURER, FAIRE LE BILAN’ 87
  • 9. GBP-LPM – 1 ÈRE EDITION – Juin 2012 9 1 - LE LEAN MANUFACTURING 1.1 – Historique et dĂ©finition Toyota a dĂ©veloppĂ©, au sortir de la Seconde guerre mondiale, un systĂšme de production remarquablement efficace qui prenait Ă  contre-pied les principes de production de masse utilisĂ©s jusqu’alors (prolongement du Taylorisme). Ce systĂšme de production, le TPS (Toyota Production System), repose sur la base de « la stabilitĂ© des pratiques » et deux piliers : le « juste Ă  temps » (produire le juste nĂ©cessaire au moment oĂč le besoin est exprimĂ©) et le « jidoka » = Autonomation (maĂźtrise efficace de la qualitĂ©). Le TPS s'articule autour de l'idĂ©e d’identifier le client, la valeur ajoutĂ©e et, par dĂ©duction, d'Ă©liminer les gaspillages et les pertes. Ce systĂšme a Ă©voluĂ© et propose de nombreux outils et concepts. Le TPS s'inspire largement des idĂ©es de William Edwards DEMING. (Roue de DEMING/PDCA : AmĂ©lioration continue). En synthĂšse, Le systĂšme de production Toyota (TPS) a donnĂ© lieu au dĂ©ploiement de plusieurs outils et mĂ©thodologies spĂ©cifiques Ă  la production industrielle (voir annexe 1). Il est gĂ©nĂ©ralement reprĂ©sentĂ© par un « temple » comme celui ci-aprĂšs : Figure 1 – Maison TPS Source : « graphique original GR LPM » 2012
  • 10. GBP-LPM – 1 ÈRE EDITION – Juin 2012 10 Le Lean manufacturing est un terme inventĂ© en 1987 par James P. WOMACK et Daniel T. JONES, deux chercheurs du MIT (Massaschussetts Institute of Technology). Ces deux chercheurs ont crĂ©Ă© la mĂ©thodologie Lean en utilisant le TPS comme exemple de production tout en conceptualisant la culture Toyota. Lean signifie littĂ©ralement « maigre », « svelte », mais aussi « ajustĂ© » (ex. : une carburation « Lean », ni trop riche, ni trop pauvre). Cette derniĂšre traduction semble plus dans l’esprit du mot que voulaient exprimer WOMACK et JONES. 1.2 - Objectifs  Le premier objectif poursuivi par la dĂ©marche de Lean manufacturing est de gĂ©nĂ©rer la valeur ajoutĂ©e maximale au moindre coĂ»t et au plus vite. Pour atteindre un tel objectif, le Lean donne beaucoup d’importance Ă  la formation des personnes et en particulier Ă  leur aptitude Ă  rĂ©soudre des problĂšmes (voir TRIZ). C’est un mode de fonctionnement permettant Ă  l'entreprise d'amĂ©liorer fortement sa productivitĂ© et sa rĂ©activitĂ© par une division des tĂąches, non pas suivant une logique par nature, mais par un dĂ©coupage des produits ou des processus. L'efficacitĂ© est la rĂ©sultante des compĂ©tences et des responsabilitĂ©s de chacun des acteurs impliquĂ©s. Suivant P. WOMACK et D. JONES (cf « Lean Thinking »), 5 Ă©tapes sont nĂ©cessaires pour assurer une dĂ©marche Lean : 1. DĂ©terminer la valeur du produit, c’est-Ă -dire spĂ©cifier ce qui crĂ©e de la valeur pour le client. 2. Identifier la chaĂźne de la valeur pour chaque produit : mesurer toutes les Ă©tapes du processus en termes de performance et identifier les Ă©tapes inutiles. 3. Favoriser l’écoulement du flux : mettre en place des flux continus et assurer le mouvement continu des produits, des services et des informations tout en Ă©liminant le gaspillage. 4. Passer du flux poussĂ© au flux tirĂ©, c'est-Ă -dire laisser le client orienter (tirer) la valeur du produit. 5. Viser la perfection : mettre en Ɠuvre une dynamique d’amĂ©lioration continue pĂ©renne.  Le second objectif poursuivi par la dĂ©marche de Lean manufacturing est d’éliminer toutes les sources de gaspillages. « Gaspillages » est la traduction pour muda en japonais. Voici les 7 sources identifiĂ©es : 1. La SURPRODUCTION : fait de produire en avance sans besoin exprimĂ©, qui engendre des stocks, des surplus de main d’Ɠuvre, machines et marchandises, 
 2. L’ATTENTE : arrĂȘts de production
 3. Les TRANSPORTS et MANUTENTIONS INUTILES : dĂ©placements et manutentions inutiles des produits 4. Les MOUVEMENTS INUTILES : tout mouvement n’ajoutant aucune valeur, dĂ©placement inutiles 5. Les STOCKS : ils engendrent des frais de stockage, avec nĂ©cessitĂ© d’espace de stockage, d’assurance. 6. Les TÂCHES INUTILES : ces tĂąches incorrectes ou non nĂ©cessaires n’apportent aucune valeur au produit. 7. La PRODUCTION DEFECTUEUSE (rebus et dĂ©chets) : dĂ©fauts sur des produits fabriquĂ©s.
  • 11. GBP-LPM – 1 ÈRE EDITION – Juin 2012 11 1.3 – Les facteurs de succĂšs ou niveaux d’analyse Les deux objectifs prĂ©citĂ©s de dĂ©veloppement de la valeur et de rĂ©duction des sources de gaspillages impliquent les facteurs de succĂšs suivants du systĂšme de pensĂ©e Lean : 1. Formuler une stratĂ©gie Ă  long terme : baser ses dĂ©cisions sur le long terme mĂȘme si cela peut nuire Ă  l’atteinte de certains objectifs Ă  plus court terme. 2. DĂ©velopper un schĂ©ma productif Ă  travers ces diffĂ©rentes Ă©tapes (les bons processus produiront les bons rĂ©sultats) :  mettre en place des processus avec flux continus ;  mettre en place les flux tirĂ©s pour Ă©viter la surproduction ;  lisser la charge de travail par une production constante ;  obtenir la qualitĂ© du premier coup : construire cette culture avec rĂ©solution immĂ©diate des problĂšmes ;  standardiser les processus et les activitĂ©s, viser l’amĂ©lioration continue et responsabiliser les employĂ©s ;  mettre en place le contrĂŽle visuel pour identifier tous les problĂšmes ;  garantir la robustesse de l’appareil de production au service des employĂ©s. 3. Former des employĂ©s et partenaires :  former des responsables qui connaissent parfaitement le travail pour transmettre la philosophie et former les Ă©quipes ;  former des personnes et des Ă©quipes exemplaires qui appliquent cette nouvelle culture ;  respecter et motiver ses partenaires (leur faire aussi intĂ©grer l’amĂ©lioration continue). 4. IntĂ©grer l’amĂ©lioration opĂ©rationnelle par la rĂ©solution continue de problĂšmes :  visites de terrain (gemba Walk) ;  prendre des dĂ©cisions en s’inscrivant dans une dĂ©marche consensuelle et mettre en Ɠuvre rapidement les plans d’actions choisis ;  intĂ©grer l’amĂ©lioration continue par des pratiques de type Hansei (auto-rĂ©flexion) corrective et Kaizen (amĂ©lioration permanente)
  • 12. GBP-LPM – 1 ÈRE EDITION – Juin 2012 12 2 – L’AGILE 2.1 – La gestion de projets « Agile » ParallĂšlement aux avancĂ©es du Lean Manufacturing, les mĂ©thodologies de gestion/Management de projet ont aussi sensiblement Ă©voluĂ© dans les annĂ©es 1990, notamment par l’apport de la gestion de projet AGILE concernant, dans un premier temps, les projets de dĂ©veloppement de logiciels informatiques. Il faut cependant attendre les annĂ©es 2000 pour voir l’idĂ©e se structurer autour du « Manifeste agile » (Agile Manifesto, 2001), qui Ă©tablit les 12 principes fondamentaux suivants : 1. Notre plus haute prioritĂ© est de satisfaire le client en livrant rapidement et rĂ©guliĂšrement des fonctionnalitĂ©s‹à grande valeur ajoutĂ©e. 2. Accueillez positivement les changements de besoins, mĂȘme tard dans le projet. Les processus Agile‹exploitent le changement pour donner un avantage compĂ©titif au client. 3. Livrez frĂ©quemment avec des ‹cycles de quelques semaines Ă  quelques mois et une‹prĂ©fĂ©rence pour les plus courts. 4. Les utilisateurs ou leurs reprĂ©sentants et les‹contributeurs doivent travailler ensemble quotidiennement‹tout au long du projet. 5. RĂ©alisez les projets avec des personnes motivĂ©es. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixĂ©s. 6. La mĂ©thode la plus simple et la plus efficace pour transmettre de l’information Ă  l'Ă©quipe et Ă  l’intĂ©rieur de celle-ci est le dialogue en face Ă  face. 7. Un rĂ©sultat opĂ©rationnel est la principale mesure d’avancement. 8. Les processus Agile encouragent un rythme de dĂ©veloppement soutenable. Ensemble, les commanditaires, les contributeurs et les utilisateurs devraient ĂȘtre capables de maintenir‹ indĂ©finiment un rythme constant. 9. Une attention continue Ă  l'excellence technique et Ă  une bonne conception renforce l’AgilitĂ©. 10. La simplicitĂ© - c’est-Ă -dire l’art de minimiser la quantitĂ© de travail inutile - est essentielle. 11. Les meilleures architectures, spĂ©cifications et conceptions Ă©mergent d'Ă©quipes auto- organisĂ©es. 12. À intervalles rĂ©guliers, l'Ă©quipe rĂ©flĂ©chit aux moyens de devenir plus efficace, puis rĂšgle et modifie son comportement en consĂ©quence. Le tableau ci-aprĂšs permet d’apprĂ©cier le parallĂšle qui existe entre l’approche « Agile » et les facteurs de succĂšs du Lean Manufacturing.
  • 13. GBP-LPM – 1 ÈRE EDITION – Juin 2012 13 FACTEURS DE SUCCES DU LEAN PRINCIPES AGILE 1. La formulation d’une stratĂ©gie Ă  long terme ou philosophie Ă  long terme - Accueillez positivement les changements de besoins, mĂȘme tard dans le projet. Les processus Agile‹exploitent le changement pour donner un avantage compĂ©titif au client. 2. Le dĂ©veloppement d’un schĂ©ma productif caractĂ©ristique : les bons processus produiront les bons rĂ©sultats Mise en place de processus avec flux continus. - Livrez frĂ©quemment avec des cycles de quelques semaines Ă  quelques mois et une‹prĂ©fĂ©rence pour les plus courts. Mise en place de flux tirĂ©s pour Ă©viter la surproduction. - Notre plus haute prioritĂ© est de satisfaire le client en livrant rapidement et rĂ©guliĂšrement des fonctionnalitĂ©s‹à grande valeur ajoutĂ©e. Lisser la charge de travail par une production constante. - Les processus Agile encouragent un rythme de dĂ©veloppement ‹soutenable. Ensemble, les commanditaires, les contributeurs et les utilisateurs devraient ĂȘtre capables de maintenir‹indĂ©finiment un rythme constant. Obtenir la qualitĂ© du premier coup : construire cette culture avec rĂ©solution immĂ©diate des problĂšmes. - Un rĂ©sultat opĂ©rationnel est la principale mesure d’avancement. Standardisation des processus et des activitĂ©s : base de l’amĂ©lioration continue et responsabilisation des employĂ©s. - La simplicitĂ© – c’est-Ă -dire l’art de minimiser la quantitĂ© de travail inutile – est essentielle. Mise en place du contrĂŽle visuel pour identifier tous les problĂšmes. - Une attention continue Ă  l'excellence technique et Ă  une bonne conception renforce l’AgilitĂ©. Robustesse de l’appareil de production au service des employĂ©s. - Accueillez positivement les changements de besoins, mĂȘme tard dans le projet. Les processus Agile‹exploitent le changement pour donner un avantage compĂ©titif au client. 3. Le dĂ©veloppement des employĂ©s et partenaires : Former des responsables qui connaissent parfaitement le travail pour transmettre la philosophie et former les Ă©quipes. - Les utilisateurs ou leurs reprĂ©sentants et les‹contributeurs doivent travailler ensemble quotidiennement‹tout au long du projet. - RĂ©alisez les projets avec des personnes motivĂ©es.‹Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixĂ©s Former des personnes et des Ă©quipes exemplaires qui appliquent cette nouvelle culture. Respecter et motiver ses partenaires (leur faire aussi intĂ©grer l’amĂ©lioration continue). 4. IntĂ©grer l’amĂ©lioration opĂ©rationnelle par la rĂ©solution continue de problĂšmes Aller sur le terrain (Visites de terrain = gemba Walk). - La mĂ©thode la plus simple et la plus efficace pour ‹transmettre de l’information Ă  l'Ă©quipe et Ă  l’intĂ©rieur de celle-ci est le dialogue en face Ă  face. Prendre des dĂ©cisions en s’inscrivant dans une dĂ©marche consensuelle + mettre en Ɠuvre rapidement les plans d’actions choisis. - Les meilleures architectures, spĂ©cifications et‹conceptions Ă©mergent d'Ă©quipes auto-organisĂ©es. IntĂ©grer l’amĂ©lioration continue : rĂ©flexion et amĂ©lioration en continu (Hansei et Kaizen). - À intervalles rĂ©guliers, l'Ă©quipe rĂ©flĂ©chit aux moyens‹de devenir plus efficace, puis rĂšgle et modifie son‹comportement en consĂ©quence Figure 2 – Correspondances AGILE – LEAN MANUFACTURING
  • 14. GBP-LPM – 1 ÈRE EDITION – Juin 2012 14 DĂšs lors, l’approche « Agile » est considĂ©rĂ©e comme une alternative aux mĂ©thodes de management de projets dites « PrĂ©dictives » ou « dĂ©finies » plus classiques. Elle s’est avĂ©rĂ©e comme une option d’adaptation dans la gestion de certains projets, le plus souvent dans les systĂšmes et technologies de l’information (IT maintenant dĂ©signĂ© sous le vocable TICC). C’est en effet dans le domaine de l’informatique que l’Agile a Ă©tĂ© et demeure le plus largement documentĂ© et mis en Ɠuvre. GARTNER avait mĂȘme prĂ©dit en 2009 que « 80% des projets de dĂ©veloppement des logiciels utiliseraient les mĂ©thodes Agile en 2012 ». Dans ce secteur, la mĂ©thode de dĂ©veloppement dite «Agile», vise essentiellement Ă  rĂ©duire le cycle de vie du projet de rĂ©alisation en accĂ©lĂ©rant la phase de production. A ce titre, elle rejoint les objectifs principaux du Lean : augmenter la valeur et diminuer les pertes. En employant la mĂ©thode Agile, le client obtient trĂšs vite une premiĂšre version mise en production sur le pĂ©rimĂštre prioritaire. Ainsi, il est possible d'associer les utilisateurs dĂšs le dĂ©but du projet. GrĂące Ă  la mise en Ɠuvre d'une mĂ©thodologie de conduite de projet fondĂ©e sur les principes Agile, Ă  savoir :  le dĂ©veloppement d’une premiĂšre version avec les fonctionnalitĂ©s prioritaires ;  l’intĂ©gration des fonctionnalitĂ©s complĂ©mentaires par un processus itĂ©ratif ;  la rĂ©alisation de tests tout au long des cycles de rĂ©alisation ;  l’implication forte du client. Le client d'un projet met trĂšs vite en exploitation un produit partiel pour tester ces performances. Dans ce processus court, les exploitants sont impliquĂ©s dans la dĂ©finition du produit : dĂšs rĂ©ception du produit, il est important d’identifier et de transmettre toutes les suggestions Ă  envisager concernant la version proposĂ©e. Les modifications nĂ©cessaires sont ainsi intĂ©grĂ©es sans remise en cause de tout ou partie du produit comme ce serait le cas pour un projet pilotĂ© en cascade (comme dans le DĂ©veloppemet DirigĂ© par les Tests) ou en V (mĂ©thodes classiques). 2.2 – Les limites et l’ouverture vers le Lean Project Management Le domaine d’application de l’Agile, souvent limitĂ© Ă  ce secteur IT, a certainement constituĂ© un frein Ă  son dĂ©ploiement plus large. La plupart des entreprises qui utilisent l’Agile dĂ©finissent et analysent des critĂšres prĂ©alables au choix de la mĂ©thode de gestion, Ă  savoir :  Organisation et gouvernance : avoir la disponibilitĂ© du client dans la gestion des prioritĂ©s et des changements ainsi que son implication effective dans le quotidien du projet.  Qualification du projet (pĂ©rimĂštre, dĂ©lais, spĂ©cifications techniques, etc.) : pouvoir dĂ©velopper par itĂ©ration la solution visĂ©e par le projet.  Équipe de projet : avoir ou faire Ă©voluer le rĂŽle des acteurs vers un mode Agile (rĂŽles et responsabilitĂ©s, disponibilitĂ© des acteurs, niveau d’adhĂ©sion Ă  l’Agile, etc.). Certains rĂŽles sont mĂȘme crĂ©Ă©s (scrum manager). Leur relation Ă  la planification, Ă  la gestion de la valeur, Ă  la gestion des risques, mais aussi au management de l’équipe Ă©volue trĂšs fortement au passage d’une mĂ©thode dite prĂ©dictive/conventionnelle Ă  une mĂ©thode dite « Agile ».  Environnement de travail et production : pouvoir allouer des moyens spĂ©cifiques Ă  l’équipe de projet (configuration des locaux et de l’équipe, interface avec le systĂšme de production, etc.). DĂšs lors, il Ă©tait tentant d’explorer autrement le rapprochement des principes et valeurs de la gestion de projet « Agile » d’une part, et de ceux du « Lean manufacturing » d’autre part.
  • 15. GBP-LPM – 1 ÈRE EDITION – Juin 2012 15 3 – LEAN PROJECT MANAGEMENT Claude EMOND (http:///www.qualiscope.ca) a Ă©tĂ© un prĂ©curseur de la formalisation de cette approche de management des projets (qu’ils soient chaordiques ou pas) Ă  travers ses dĂ©marches de « Change Boxing » qui consistent Ă  appliquer les principes clefs du Lean manufacturing et de l’Agile aux projets de transformations. Claude EMOND, avec plusieurs consultants, a proposĂ© une transcription intĂ©ressante des 7 sources de gaspillage du Lean manufacturing vers la gestion de projets en rajoutant 3 autres sources pour dĂ©terminer les 10 causes de pertes d’efficacitĂ© en conduite de projets. Ces 10 causes de pertes en management de projets sont orientĂ©es par la valeur, donc par le client, et constituent les fondements du Lean Project Management. 3.1 - Les 10 causes de pertes d’efficacitĂ© en gestion de projets Ces 10 causes de pertes d’efficacitĂ© du Lean Project Management sont prĂ©sentĂ©es dans le tableau ci- dessous (figure 3), dont une version plus dĂ©taillĂ©e est proposĂ©e en annexe 24. Il existe un parallĂšle entre les 7 sources de gaspillage du Lean Manufacturing et les 10 causes de pertes en projet Ă  partir desquelles le chef de projet et toutes les parties prenantes devront s’entendre pour optimiser les chances de succĂšs du projet (figure 3), ainsi que les pratiques Ă  valoriser (figure 4 et annexe 24). L’annexe 24 complĂšte finalement ces deux tableaux par un listage des outils les plus appropriĂ©s pour chacune de ces sources de gaspillage.
  • 16. GBP-LPM – 1 ÈRE EDITION – Juin 2012 16 Les GASPILLAGES dans le LEAN MANUFACTURING (gestion flux matĂ©riel) Commentaires pour Ă©clairer et « traduire » vers le mode projets Source de GASPILLAGE en GESTION DE PROJETS SURPRODUCTION (travail rĂ©alisĂ© trop en avance, engendrant surplus de main d’Ɠuvre, machines, marchandises, etc.) RĂ©aliser des tĂąches qui ne sont pas forcĂ©ment demandĂ©es (pas de demande « aval ») et qui risquent fort de ne plus ĂȘtre nĂ©cessaires. Souvent lancĂ©es pour « occuper » des ressources (talents) surabondantes. REALISER LE PROJET DANS UN MAUVAIS TIMING, REALISER UN PROJET OU DES LIVRABLES SANS VALEUR AJOUTEE ATTENTE (ArrĂȘts de production, etc.) L'opĂ©rateur attend des piĂšces, ou les piĂšces doivent attendre avant d'ĂȘtre traitĂ©es ATTENTE DE DONNEES D'ENTREES / MANQUE D'EFFICACITE DANS L'EXPLOITATION DES DONNEES DE SORTIE TRANSPORTS ET MANUTENTIONS INUTILES (dĂ©placements et manutentions inutiles du fait du manque de fonctionnalitĂ© de l’espace de travail) L'objet fabriquĂ© est dĂ©placĂ© inutilement et doit passer typiquement Ă  des endroits sans valeur ajoutĂ©e ... TRANSFERT DEFICIENT DE L'INFORMATION / PROBLEMES DE COMMUNICATION (***) MOUVEMENTS INUTILES (Tout mouvement qui n’ajoute aucune valeur) Celui qui fabrique doit effectuer des mouvements ou dĂ©placements inutiles pour effectuer son travail : il n'a pas tout sous la main. MOYENS, PROCESSUS ET DOCUMENTATION IMPARFAITS STOCKS INUTILES (engendrant des frais de stockage, avec nĂ©cessitĂ© d’espace de stockage, assurance, etc.) Faire des stocks pour optimiser localement un processus ou parce que le processus de fabrication n'est pas assez rĂ©actif. DECISIONS QUI ATTENDENT / PROCESSUS DE PILOTAGE et D'ACCEPTATION TROP COMPLEXES TÂCHES INUTILES (tĂąches n’apportant aucune valeur au produit) TĂąches n’apportant aucune valeur au produit REALISATIONS INUTILES (« gold platting ») PRODUCTION DEFECTUEUSE (rebus, dĂ©chets et dĂ©fauts sur produits fabriquĂ©s => invendus) Non QualitĂ© REALISATIONS NON APPRECIEES PAR LES CLIENTS Principes ajoutĂ©s par Claude EMOND (*), M. BOBEK (**) et M. HOWELL MACOMBER (***) SITUATIONS OU L'ON S'ARRANGE AVEC LES MOYENS DU BORD (« Making do ») RESISTANCE AU CHANGEMENT (**) NON GESTION DES PERCEPTIONS (*) Figure 3 – Sources de gaspillage en conduite de projets
  • 17. GBP-LPM – 1 ÈRE EDITION – Juin 2012 17 Source de GASPILLAGE en GESTION DE PROJETS PRATIQUES et COMPETENCES A VALORISER afin de diminuer les sources de gaspillages en mode projets REALISER LE PROJET DANS UN MAUVAIS TIMING, REALISER UN PROJET OU DES LIVRABLES SANS VALEUR AJOUTEE VĂ©rifier la pertinence de la transformation souhaitĂ©e (origine, but, enjeu) Avoir un Sponsor clairement identifiĂ© et impliquĂ© Evaluer le couple « valeur/risques » du projet, aussi en rapport avec d'autres projets en cours ou Ă  dĂ©marrer VĂ©rifier le niveau rĂ©el de prioritĂ© du projet dans le portefeuille MaĂźtriser parfaitement les hypothĂšses, limites et contraintes du projet Exprimer le projet en termes de niveau de performance Ă  atteindre MaĂźtriser les changements et rĂ©Ă©valuer rĂ©guliĂšrement le couple « valeur/risques » ATTENTE DE DONNEES D'ENTREES / MANQUE D'EFFICACITE DANS L'EXPLOITATION DES DONNEES DE SORTIE Remettre le PERT au centre de la planification Impliquer les ressources rĂ©alisant les tĂąches ainsi que leurs managers dans la dĂ©finition des « entrĂ©es/sorties » Avoir les ressources compĂ©tentes et disponibles au bon moment Savoir anticiper TRANSFERT DEFICIENT DE L'INFORMATION / PROBLEMES DE COMMUNICATION (***) Communication efficace et directe s'appuyant sur un minimum de relais Un bon Ă©quilibre entre communications formelles et informelles Espaces de travail collaboratif, points frĂ©quents et rĂ©guliers Style de management adaptĂ© Ă  l'autonomie des Ă©quipes (fonction des compĂ©tences et de la motivation) Valorisation des comportements efficaces pour le fonctionnement de l'Ă©quipe MOYENS, PROCESSUS ET DOCUMENTATION IMPARFAITS Optimiser les processus et la documentation liĂ©s Ă  la gestion des projets (documents autoporteurs) Optimiser le SI projets Optimiser le reporting AccĂšs rapide aux ressources (organisation matricielle rĂ©elle) Environnement de travail collaboratif DECISIONS QUI ATTENDENT / PROCESSUS DE PILOTAGE et D'ACCEPTATION TROP COMPLEXES Clarifier, optimiser les dĂ©lais, outils et instances de prise de dĂ©cision et le systĂšme d'arbitrage Impliquer le client et le Sponsor, tout comme les experts clefs dans le projet COPIL opĂ©rationnel et ayant le pouvoir de dĂ©cider REALISATIONS INUTILES (« gold platting ») DĂ©couper le projet en phases et en livrables Remettre la SDP/WBS au centre de la planification Exprimer le projet en termes d'exigences et de performances REALISATIONS NON APPRECIEES PAR LES CLIENTS Depuis l'opportunitĂ© jusqu'Ă  la clĂŽture, collaborer Ă©troitement avec le client et le sponsor du projet Faire exprimer le projet en termes d'exigences, de niveau de performance Ă  atteindre DĂ©finir une stratĂ©gie de test / validation / acceptation avec le client Viser une livraison par « version » SITUATIONS OU L'ON S'ARRANGE AVEC LES MOYENS DU BORD (« Making do ») Obtenir les moyens proportionnĂ©s aux enjeux du projet Accepter le changement et le maĂźtriser Trouver et gĂ©rer la compĂ©tence et l'expertise RESISTANCE AU CHANGEMENT (**) Communiquer sur l'origine, les enjeux, les objectifs. Relier le projet Ă  la stratĂ©gie IntĂ©grer la gestion du changement Ă  la gestion du projet (activitĂ©s concrĂštes et rĂ©elles) Etablir des objectifs pour toutes les parties prenantes NON GESTION DES PERCEPTIONS (*) Etablir des limites, des contraintes et des hypothĂšses collectivement au dĂ©marrage du projet S'assurer en permanence des Ă©quilibres entre les exigences, les besoins, les objectifs Être Ă  l'Ă©coute et communiquer IntĂ©grer au plus tĂŽt toutes les parties-prenantes au projet Figure 4 – Pratiques Ă  valoriser pour diminuer les pertes d’efficacitĂ© en conduite de projets
  • 18. GBP-LPM – 1 ÈRE EDITION – Juin 2012 18 3.2 – L’efficacitĂ© par la maĂźtrise de la valeur Conduire un projet ne peut se rĂ©sumer Ă  minimiser ou Ă©liminer des pertes d’efficacitĂ©. Par essence, un projet se rĂ©ussit aussi dans l’animation d’un flux de crĂ©ation de valeur. C’est le rĂŽle du cycle de vie que d’encadrer la crĂ©ation de la valeur dans un projet. Le cycle de vie est gĂ©nĂ©ralement spĂ©cifique Ă  chacun des projets. Il peut ĂȘtre schĂ©matisĂ©, Ă  trĂšs haut niveau, de la maniĂšre suivante : Lancer, Planifier, ExĂ©cuter, ClĂŽturer (concept IPECC du PMIÂź) Dans un projet de transformation, les Ă©tapes encadrant la crĂ©ation de valeur sont les suivantes :  formaliser l’idĂ©e (voir dĂ©tails dans chapitre 5)  innover et s’engager (voir dĂ©tails dans chapitre 6)  mettre en Ɠuvre (voir dĂ©tails dans chapitre 7)  transfĂ©rer les responsabilites (voir dĂ©tails dans chapitre 8)  clĂŽturer, faire le bilan (voir dĂ©tails dans chapitre 9) Ainsi, aprĂšs les bases de rĂ©flexion spĂ©cifiques aux projets de transformation (voir chapitre 4), les chapitres subsĂ©quents (5 Ă  9) du GBP-LPM reprennent chacune des Ă©tapes du projet en suivant la dĂ©marche ci-dessous : - comprendre les bĂ©nĂ©fices et rĂ©alisations attendues Ă  chacune des phases pour crĂ©er de la valeur ; - repĂ©rer et agir sur les sources de pertes d’efficacitĂ© de la phase ; - s’appuyer sur des outils spĂ©cifiques permettant de diminuer les risques de pertes d’efficacitĂ© et d’augmenter la valeur attendue Ă  l’issue de la phase. => EfficacitĂ© VS Efficience
  • 19. GBP-LPM – 1 ÈRE EDITION – Juin 2012 19 4 - LES FACTEURS DE SUCCES POUR REUSSIR UN PROJET DE TRANSFORMATION Comme dĂ©fini en introduction dans la section « PĂ©rimĂštre d’application du GBP-LPM », les projets de transformation recouvrent des caractĂ©ristiques et conditions de succĂšs particuliĂšres. Ce chapitre a pour objectif de dĂ©terminer les Ă©lĂ©ments prĂ©requis (ou Ă  renforcer) dans l’entreprise pour qu’un projet de transformation puisse atteindre son objectif principal, Ă  savoir : « Augmenter la capacitĂ© Ă  produire de la valeur » (voir figure 5). Figure 5 : Projets VS opĂ©rations courantes Source : « graphique original sociĂ©tĂ© IQar : http://smp2.org et http://iqar-france.fr » En effet, l’entreprise est un ensemble de ressources, d’opĂ©rations et de stratĂ©gies gĂ©rĂ©es dans l’optique de Produire de la valeur + Augmenter de maniĂšre continue la capacitĂ© Ă  produire de la valeur. Tout systĂšme de management efficace prend en compte ces deux aspects, parfois « concurrents » dans l’utilisation des ressources de l’organisation. La rĂ©alisation d’un projet de transformation s’inscrit dans ce contexte et vise Ă  augmenter la capacitĂ© de l’entreprise Ă  produire de la valeur en minimisant les perturbations opĂ©rationnelles qui crĂ©ent cette valeur au quotidien. Les premiĂšres conditions favorables pour la mise en Ɠuvre de ce type de projet se rĂ©sument probablement dans la figure 6 suivante, c'est-Ă -dire dans la justification consensuelle du projet que l’on pourrait rĂ©sumer par « Faire le bon projet et le faire au meilleur moment ». Figure 6 - Se transformer : Vision, DĂ©cision, Action Source : « graphique original sociĂ©tĂ© IQar : http://smp2.org et http://iqar-france.fr »
  • 20. GBP-LPM – 1 ÈRE EDITION – Juin 2012 20 Pour crĂ©er le consensus sur la transformation, il faut concrĂštement veiller Ă  : - Impliquer les utilisateurs : c’est un principe d’habilitation, fondamental dans les « MĂ©thodes Agile » et du LEAN Manufacturing. Il faut placer l’individu et notamment le client au centre du dĂ©veloppement. Ceci permet de limiter l’opposition au changement. Il est donc important de choisir des personnes « clĂ©s » dans l’équipe de projet. L’utilisateur, s’il est partie-prenante dans l’équipe de projet, ne pourra qu’adhĂ©rer puisqu’il aura participĂ© Ă  l’élaboration collective des livrables Ă  chaque Ă©tape. - S’assurer du support de la Direction GĂ©nĂ©rale : son implication est essentielle. C’est elle qui exprime le besoin de changement d’organisation et qui est Ă  l’origine du projet. Celui-ci ne peut pas dĂ©buter tant que les moyens financiers et humains demandĂ©s par le chef de projet ne sont pas accordĂ©s. La Direction nomme le chef de projet et approuve la constitution de l’équipe projet. Elle approuve Ă©galement le calendrier de rĂ©alisation du projet proposĂ© par l’équipe projet. DĂšs qu’elle a avalisĂ© le dĂ©marrage du projet, son soutien doit ĂȘtre sans faille. Elle doit aider le chef de projet Ă  faire « sauter » les freins en particulier auprĂšs de la hiĂ©rarchie et des dĂ©cideurs Ă  chaque jalon. - Faire consensus sur la production de valeur avec les acteurs de la transformation, mais aussi avec les acteurs de sa future gestion rĂ©currente. Quel que soit le domaine d’affaires, la taille de l’entreprise ou sa culture, il est indĂ©niable qu’il y a une constante dans les projets de transformations : Ils offrent aux diffĂ©rents acteurs des intĂ©rĂȘts et des opportunitĂ©s divergents. Chacun accorde en effet Ă  la transformation une valeur ou une contre-valeur qui dĂ©termine largement son implication dans le projet. MĂȘme quand la transformation semble s’imposer Ă  l’entreprise, le moment choisi pour rĂ©aliser la transformation est presque systĂ©matiquement discutĂ©e. La notion de bĂ©nĂ©fices doit alors ĂȘtre mise au centre de toutes les dĂ©cisions pendant le projet. La gestion de la transformation doit apporter des rĂ©ponses Ă  long terme (la valeur de la transformation), mais aussi Ă  plus court terme, c'est-Ă -dire les bĂ©nĂ©fices pour chacun des acteurs impliquĂ©s en tant qu’expert dans le projet (figure 7). Figure 7 – Le projet de transformation est un lien entre la stratĂ©gie et les bĂ©nĂ©fices attendus Source : « graphique original sociĂ©tĂ© IQar : http://smp2.org et http://iqar-france.fr »
  • 21. GBP-LPM – 1 ÈRE EDITION – Juin 2012 21 DĂ©couper le projet en petites Ă©tapes cohĂ©rentes est donc un des points importants de la conduite de projet Agile. Le morcĂšlement de la transformation s’avĂšre ĂȘtre gĂ©nĂ©ralement une excellente stratĂ©gie pour la recherche d’adhĂ©sion au projet. Il s’agit d’obtenir des Ă©tapes autoportantes et courtes (Sprint), avec une dĂ©finition claire, comprise et approuvĂ©e de tous les acteurs. Aussi, des livrables sont nĂ©cessaires pour avancer sans perte de temps sur le projet. Il est Ă©galement indispensable que le chef de projet nomme un responsable pour chacune des tĂąches Ă©lĂ©mentaires identifiĂ©es. Ce responsable est le «porteur» de la tĂąche et la rĂ©alise et/ou la coordonne au sein de l’équipe projet. Ainsi, au-delĂ  du dĂ©coupage de chacune des Ă©tapes de la mise en Ɠuvre, il est essentiel de remettre le PERT au centre du projet et de sa rĂ©alisation. Plus que dans tout type de projets, les projets de transformation organisationnelle mĂ©ritent de viser un maximum de bĂ©nĂ©fices en un minimum de temps. Ceci est nĂ©cessaire pour ne pas perdre l’adhĂ©sion de certains acteurs. D’autres clefs de succĂšs sont garantes de l’optimisation du dĂ©roulement du projet. Elles concernent naturellement les notions de performance et de compĂ©tence. - Choisir le bon chef de projet : son rĂŽle est essentiel. Il doit maĂźtriser les outils de la conduite de projet, avoir de grandes qualitĂ©s d’écoute et la capacitĂ© de comprendre et de faire passer des messages Ă  des publics aussi variĂ©s que la direction gĂ©nĂ©rale, l’encadrement (middle management), ou l’opĂ©rateur utilisateur ou sachant. Il doit savoir s’imposer auprĂšs de tous par ses qualitĂ©s et non par la fonction qu’il occupe. Il est le garant du respect du cahier des charges, du projet et de sa rĂ©ussite. - Obtenir le personnel compĂ©tent : cela va sans dire, c’est Ă©vident. En phase d’avant-projet, s’il est dĂ©jĂ  nommĂ© par la direction gĂ©nĂ©rale, c’est au chef de projet de constituer son Ă©quipe de projet. Il doit ĂȘtre en mesure d’en choisir les membres en fonction de leurs compĂ©tences techniques sur le sujet concernant le projet. Il doit pouvoir faire ce choix aux frontiĂšres des contraintes hiĂ©rarchiques. Cependant, in fine, la validation de la constitution de l’équipe projet est de la responsabilitĂ© de la direction gĂ©nĂ©rale. - Avoir une Ă©quipe autonome dans sa prise de responsabilitĂ© : dans l’item prĂ©cĂ©dent, nous avons parlĂ© du choix des membres de l’équipe projet en fonction de leurs compĂ©tences eu Ă©gard au sujet du projet. Le chef de projet doit s’assurer que chaque membre de son Ă©quipe a la libertĂ© de ses prises de responsabilitĂ© dans le cadre de son dĂ©tachement au sein de l’équipe projet. Il doit ĂȘtre informĂ© par un membre susceptible de subir des pressions de la part de sa hiĂ©rarchie de nature Ă  changer ses dĂ©cisions ou ses orientations dans le cadre de la conduite du projet. Finalement, il apparait dĂ©terminant de rendre la transformation totalement concrĂšte dans l’esprit des personnes qui vont contribuer Ă  la rĂ©aliser ou plus tard Ă  l’opĂ©rer. Les principes d’intĂ©gration et de rĂ©alitĂ© donneront du corps Ă  la transformation. - Planifier de maniĂšre rĂ©aliste : entre la phase d’avant-projet et la validation du lancement du projet par la direction gĂ©nĂ©rale, le chargĂ© de projet doit s’assurer que le planning gĂ©nĂ©ral de dĂ©roulement du projet est cohĂ©rent avec les allocations de moyens humains consacrĂ©s au projet. Il ne doit pas cĂ©der, a priori, aux pressions de la direction gĂ©nĂ©rale tentant de lui imposer des dĂ©lais non rĂ©alistes. Les dĂ©lais doivent ĂȘtre nĂ©gociables avec les moyens humains et financiers accordĂ©s au projet. Le rĂŽle du chef de projet, en cours de projet, est d’identifier les sources de glissement de planning et de proposer des actions correctives. Un reporting rĂ©gulier doit ĂȘtre fait Ă  la direction gĂ©nĂ©rale. Une approche de la planification par vague dĂ©ferlante (voir annexe 15) semble tout Ă  fait appropriĂ©e.
  • 22. GBP-LPM – 1 ÈRE EDITION – Juin 2012 22 - Prendre en compte tous les facteurs liĂ©s Ă  l’environnement du projet : ce sont des facteurs qui peuvent ĂȘtre liĂ©s Ă  l’environnement de l’entreprise : taille de l’entreprise, type d’organisation, modifications majeures affectant l’entreprise en cours de rĂ©alisation du projet, etc. La figure 8 ci-aprĂšs rĂ©sume l’ensemble des leviers prĂ©requis Ă  la bonne rĂ©alisation d’un projet de transformation. Figure 8 – PrĂ©requis Ă  la rĂ©alisation d’un projet de transformation organisationnelle Source : « graphique original sociĂ©tĂ© IQar : http://smp2.org et http://iqar-france.fr »
  • 23. GBP-LPM – 1 ÈRE EDITION – Juin 2012 23 5 - FORMALISER L’IDEE DU PROJET 5.1 – Vue d’ensemble de la phase C’est la toute premiĂšre phase du projet. Dans certaines organisations, cette phase est prĂ©cĂ©dĂ©e d’une phase d’opportunitĂ© ou de cotation (scoring) du projet (voir outils en annexe 10), c’est-Ă -dire de caractĂ©risation de l'apport de valeur versus les contraintes de rĂ©alisation entre plusieurs axes de solutions possibles. Cette hiĂ©rarchisation facilite le choix par le sponsor du projet. On parle alors souvent d’un avant-projet. Lorsqu’une telle phase n’existe pas en tant que tel, l’opportunitĂ© est une « donnĂ©e de sortie » de la phase « Formaliser l’idĂ©e du projet ». L’opportunitĂ© du projet permet de faire Ă©tablir, par les principaux acteurs, un consensus sur le couple « valeur ajoutĂ©e/risques encourus » Ă  s’engager dans le projet. La phase d’opportunitĂ© dĂ©termine aussi naturellement les objectifs assignĂ©s, tout comme l’existence d’un budget pour formaliser le projet, les Ă©chĂ©ances principales, les hypothĂšses, les contraintes, les conditions de rĂ©ussite et toute autre exigence. Dans un projet de transformation, les principaux acteurs veilleront Ă  ne pas court-circuiter cette phase, au risque de voir les ressources consommĂ©es se trouver gaspillĂ©es par des rĂ©sultats en fort Ă©cart avec les attentes. Cette phase a aussi comme objectif de dĂ©terminer le niveau d’engagement qui doit ĂȘtre partagĂ© et portĂ© par un sponsor (payeur et membre de la direction) et par un client et/ou des utilisateurs. Un des piĂšges majeurs d'un projet de transformation serait de partir d'emblĂ©e dans l'application d'une solution poussĂ©e avec influence et/ou autoritĂ© par certains sans en avoir rĂ©ellement apprĂ©ciĂ© l'adĂ©quation avec le rapport « valeurs/risques ». En rĂ©sumĂ©, il s'agit Ă  ce stade de s'abstenir de la facilitĂ© des solutions toutes faites mises en avant. Certains acteurs pourraient influencer le choix des solutions Ă  leur avantage spĂ©cifique sans nĂ©cessairement mesurer l‘impact et, surtout, l’effort de mise en Ɠuvre. La phase « Formaliser l’idĂ©e du projet » vise Ă  poser LA bonne question que le projet tentera ensuite de rĂ©soudre. L’objectif principal de la phase « Formaliser l’idĂ©e du projet » est donc bien d’établir la non-performance actuelle et de dĂ©finir l'objectif de performance visĂ©. A l’issue de la phase « Formaliser l’idĂ©e du projet », les parties prenantes disposent : - d’un constat objectif sur la non-performance (justification) ; - d’une analyse des « sachants » Ă  propos des causes, des pistes de solutions (attentes et exigences) ; - d’ordre de grandeur pour le projet (coĂ»ts, dĂ©lais, contenu, qualitĂ©, etc.) ; - d’un plan d'actions prĂ©cis pour la phase suivante. Cette premiĂšre phase doit ĂȘtre approuvĂ©e formellement par le sponsor et le client dans la charte du projet. Pour voir plus en dĂ©tails comment s’appliquent les principes du Lean Project management Ă  cette phase, voir l’annexe 3 (« Cycle de vie : formaliser l’idĂ©e du projet »).
  • 24. GBP-LPM – 1 ÈRE EDITION – Juin 2012 24 5.2 – Les outils associĂ©s Voir fiches-outils suivantes en annexe : - Cotation (Scoring) en annexe 10, pour Ă©valuer l’idĂ©e du projet afin de s’engager ou pas dans le projet ou encore pour prioriser le projet dans la « pile » des projets de l’entreprise. - Management de risque (Risk-Management) en annexe 7, pour anticiper les principaux risques et mettre en perspective la valeur du projet avec les risques encourus. - SDP ou WBS en annexe 17, pour dĂ©couper le projet en Ă©tapes Ă  forte valeur ajoutĂ©e. - SMART en annexe 11, pour la qualitĂ© de dĂ©finition des objectifs Ă  atteindre. 5.3 – RĂŽles et responsabilitĂ©s La premiĂšre phase d’un projet reprĂ©sente une collaboration entre le sponsor et les clients. Le chef de projet est nommĂ© durant cette premiĂšre phase. Le sponsor est celui qui a le plus intĂ©rĂȘt Ă  ce que le projet se rĂ©alise. Dans le cadre de projets de transformation organisationnelle, il est un des membres dirigeant. Il peut ĂȘtre nommĂ© « commanditaire » ou « propriĂ©taire » du projet. Il donne les moyens au projet de fonctionner et le reprĂ©sente auprĂšs de la direction. Il est responsable de l’atteinte des objectifs du projet. Il valide les hypothĂšses, les contraintes et les limites Ă  la rĂ©alisation de celui-ci lors de la phase « Formaliser l’idĂ©e du projet ». La dĂ©nomination de « client » est gĂ©nĂ©ralement utilisĂ©e pour dĂ©crire au moins 2 types de clients, le payeur et l’utilisateur. Dans le cadre des projets de transformation, le client payeur est souvent interne Ă  l’organisation (reprĂ©sentĂ© par le sponsor). Le client utilisateur doit ĂȘtre, lui aussi, clairement identifiĂ© et impliquĂ© dans toutes les phases, y compris la premiĂšre phase de formalisation de l’idĂ©e du projet. Les utilisateurs doivent exprimer leur besoin en termes d’exigences fonctionnelles. Une dĂ©rive frĂ©quente rĂ©side dans l’absence d’implication rĂ©elle des clients, alors simplement reprĂ©sentĂ©s par le sponsor. Le chef de projet est nommĂ© par le sponsor. Il est responsable du « voyage » si l’on considĂšre que la transformation consistera Ă  aller d’une situation « A » non performante vers une situation « B » visĂ©e. Sa responsabilitĂ© au cours de ce « voyage » consiste concrĂštement Ă  : - identifier tous les acteurs et les impliquer ; - dĂ©terminer des scĂ©narii de rĂ©alisation et conduire le sponsor et le client Ă  n’en retenir qu’un ; - prĂ©voir la rĂ©alisation du projet sur l’ensemble des domaines de gestion (coĂ»ts, dĂ©lais, contenus, risques, RH, communication, qualitĂ©, etc.) et faire approuver les plans d’actions associĂ©s ; - assurer un suivi du projet pour maĂźtriser et gĂ©rer les Ă©carts, maĂźtriser et faire approuver les changements, le cas Ă©chĂ©ant.
  • 25. GBP-LPM – 1 ÈRE EDITION – Juin 2012 25 6 - INNOVER ET S’ENGAGER 6.1 - Vue d’ensemble de la phase La phase de formalisation terminĂ©e, le projet de transformation a pris sens et est devenu opportun. La nature des performances Ă  changer et les niveaux de gaps (Ă©carts) Ă  combler ont Ă©tĂ© identifiĂ©s et clairement caractĂ©risĂ©s par l'Ă©quipe de projet. Le sponsor et le client les ont validĂ©s. L a v i s i o n s y s t Ă© m i q u e p a r t a g Ă© e Au cours de ce processus de diagnostic approfondi, l'Ă©quipe de projet s'est appropriĂ© la situation d'insatisfaction liĂ©e Ă  l'existence de ces Ă©carts (gaps) et s'est bĂąti une culture commune des sujets. Entre eux, les acteurs partagent, plus que tout autre, une reprĂ©sentation commune de l'Ă©cosystĂšme organisationnel concernĂ©, de ses fonctionnalitĂ©s, de ses limites, de son identitĂ©, et probablement de ses mythes fondateurs et de ses valeurs. En tout cas, s'agissant d'un projet de transformation organisationnelle, la bonne comprĂ©hension de ces diffĂ©rents aspects peut ĂȘtre recommandĂ©e tant il est vrai que la mise en Ɠuvre des changements pour atteindre un nouvel Ă©tat de performances accrues passe par de l'adhĂ©sion partagĂ©e. L e l a n g a g e c o m m u n Ce parcours initiatique se concrĂ©tise en particulier dans la construction d'une codification partagĂ©e entre les Ă©quipiers projet au premier niveau et, d'une façon moins prĂ©cise, avec leurs proches dans leurs rĂ©seaux directs. C'est le langage commun du projet. L a r e c h e r c h e d e s o l u t i o n s DĂšs lors, l'Ă©quipe projet dispose de tous les Ă©lĂ©ments et des atouts pour trouver les solutions d'amĂ©lioration opĂ©rationnelles et pragmatiques qui permettront d'atteindre le nouveau palier de performances organisationnelles visĂ©. Deux dĂ©marches complĂ©mentaires sont, en gĂ©nĂ©ral, mises en Ɠuvre en parallĂšle. 1. Pour les solutions "prĂ©existantes", repĂ©rĂ©es lors de la phase de diagnostic : une rapide Ă©valuation de leurs rĂ©els enjeux et des conditions de leur faisabilitĂ© est conduite. Si la pertinence de ces solutions est dĂ©montrĂ©e, la barriĂšre Ă  l'adhĂ©sion et Ă  la mise en Ɠuvre est moins difficile Ă  franchir. Si les niveaux d'amĂ©lioration sont en dessous du niveau visĂ©, l’équipe devra commencer une recherche pour de nouvelles solutions.
  • 26. GBP-LPM – 1 ÈRE EDITION – Juin 2012 26 2. Pour les axes de progrĂšs sans piste de solution identifiĂ©e : L'Ă©quipe de projet va devoir faire preuve de crĂ©ativitĂ© opĂ©rationnelle. Il existe de nombreuses mĂ©thodes de crĂ©ativitĂ©, plus ou moins complexes Ă  mettre en Ɠuvre. La plus connue est le ‘’Remue mĂ©ninges’’ (brainstorming) (annexe 14). Simple Ă  mettre en Ɠuvre, c'est la mĂ©thode de rĂ©fĂ©rence et elle convient bien en particulier dans les projets de transformation organisationnelle Ă  condition de la mettre en Ɠuvre correctement. L'efficacitĂ© d'un processus de crĂ©ativitĂ© dĂ©pend dans l'ordre de : a. La qualitĂ© de sa prĂ©paration Rappelons-nous "qu'un problĂšme bien posĂ© est Ă  moitiĂ© rĂ©solu". Le processus sera vĂ©ritablement crĂ©atif s'il se donne la possibilitĂ© d'accĂ©der Ă  des solutions rĂ©ellement innovantes, en rupture. Pour cela, il est recommandĂ© de reformuler le sujet en termes fonctionnels. Cette approche mĂ©thodologique prĂ©sente de multiples avantages parmi lesquels : - s'extraire du cadre restreint de la solution existante ; - poser le problĂšme Ă  rĂ©soudre en termes neutres de besoins et d'objectifs ; - intĂ©grer facilement des apports et des benchmarks externes. b. L'organisation et la conduite du processus crĂ©atif. Il s'agit en particulier d'ĂȘtre exigeant sur : - le choix des participants ; - la neutralitĂ© et la dynamique de l'animateur ; - le respect des participants ; - l'alternance des Ă©tapes de divergence et de convergence ; - le dĂ©roulement en 7 Ă©tapes (cf. annexe 14). c. L'exploitation des idĂ©es produites. Il peut sembler curieux que cette Ă©tape, qui est l'aboutissement recherchĂ© du processus, soit en dernier par ordre d'importance. Pour se convaincre de la pertinence de cette façon de voir, il suffit de s'interroger sur la qualitĂ© de solutions construites sur des propositions en dĂ©calage par rapport aux niveaux des enjeux et de la complexitĂ©. Sans paraphraser, rappelons certaines phrases cĂ©lĂšbres d'Einstein : - « Un problĂšme sans solution est un problĂšme mal posĂ© » ; - « Si je disposais d'une heure pour rĂ©soudre un problĂšme et que ma vie en dĂ©pende, je consacrerais les 55 premiĂšres minutes Ă  dĂ©finir la question appropriĂ©e Ă  poser, car, une fois cela fait, je pourrais rĂ©soudre le problĂšme en moins de 5 minutes" L a q u a l i f i c a t i o n d e s s c Ă© n a r i i Les idĂ©es produites par l'Ă©quipe de projet en groupe de crĂ©ativitĂ© sont assemblĂ©es en scĂ©narii de solutions sur une base de cohĂ©rence et de compatibilitĂ©. Chacun des scĂ©narii est Ă©valuĂ© en termes de potentiel sur le rĂ©fĂ©rentiel cible construit au dĂ©part et en termes de faisabilitĂ©. Pour la rapiditĂ© et la qualitĂ© de l'Ă©valuation, l'Ă©quipe projet doit travailler de façon participative en s'appuyant sur une implication des acteurs potentiellement fortement impactĂ©s par la mise en Ɠuvre de la solution. La mĂ©thode de cotation (« scoring ») sera partagĂ©e. La plus simple est le diagramme 4 carrĂ©s, bien connu, croisant l'axe des bĂ©nĂ©fices avec celui de la faisabilitĂ©.
  • 27. GBP-LPM – 1 ÈRE EDITION – Juin 2012 27 Les paramĂštres de faisabilitĂ© peuvent ĂȘtre multiples, surtout dans le cadre d'un projet de transformation organisationnelle. En effet, la faisabilitĂ© peut ĂȘtre Ă  dĂ©cliner par exemple sur : - le dĂ©lai compatible ou non avec le cadrage du sponsor ; - les moyens physiques Ă  mettre en Ɠuvre en cohĂ©rence ou non avec le budget prĂ©vu par le sponsor ; - les parties prenantes obligatoirement associĂ©es au processus de dĂ©cision comme les partenaires sociaux et les instances reprĂ©sentatives dans l'entreprise ; - la capacitĂ© d'adhĂ©sion des salariĂ©s (motivation), la culture d'entreprise, etc. ; - la remise en cause de processus informels existants, mais stratĂ©giques dans la crĂ©ation de valeur de l'entreprise ; - ... Certains de ces critĂšres peuvent ĂȘtre destructeurs d'une solution. L'Ă©valuation moyenne de faisabilitĂ© n'est alors pas suffisante. Attention Ă  ne pas prendre ses dĂ©sirs pour des rĂ©alitĂ©s ! Pour les scĂ©narii aux enjeux les plus forts avec une faisabilitĂ© jugĂ©e « accessible », une analyse de risque (cf. annexe 7) est rĂ©alisĂ©e et un prĂ©-planning de mise en Ɠuvre construit sur la base d'un plan d'action de mise en Ɠuvre et de dĂ©ploiement. L a v a l i d a t i o n p a r l e s p o n s o r e t l e ( s ) c l i e n t ( s ) Les scĂ©narii qualifiĂ©s Ă  la hauteur des enjeux du projet avec une faisabilitĂ© suffisante et des risques clairement identifiĂ©s sont alors prĂ©sentĂ©s aux Sponsor et client(s) pour discussion et choix. L e c o n t r a t d ' o b j e c t i f Le sponsor dĂ©cide de confier le pilotage de la mise en Ɠuvre de la solution de changement retenue Ă  l'Ă©quipe projet. En fonction de la nature des transformations Ă  rĂ©aliser, le choix des membres constituant cette Ă©quipe peut ĂȘtre adaptĂ©. L'Ă©quipe projet est alors mandatĂ©e par le sponsor dans un contrat d'objectifs pour dĂ©ployer le scĂ©nario choisi. La fin de cette phase doit faire l'objet d'un plan de communication officiel. La transparence sur l'objet de la mission et les clauses de son dĂ©roulement ainsi que l'engagement de la direction sont des conditions nĂ©cessaires Ă  la rĂ©ussite du projet dans les phases suivantes. Pour plus de dĂ©tails sur cette phase et pour apprĂ©cier les sources d’efficacitĂ© et de gaspillage, consulter l’annexe 4 (voir aussi les termes : Contrats et management de contrats ; Objectifs )
  • 28. GBP-LPM – 1 ÈRE EDITION – Juin 2012 28 6.2 - Les outils associĂ©s Voir fiches outils suivantes en annexe : - processus de crĂ©ativitĂ© en annexe 13 pour assurer sa cohĂ©rence avec le problĂšme posĂ© et sa richesse de production ; - cotation = scoring en annexe 10 pour Ă©valuer les scĂ©narii ; - management de risque = risk-management en annexe 7 pour anticiper les principaux risques, mettre en perspective les conditions de rĂ©ussite du dĂ©veloppement des solutions, construire un plan d'action et un planning pertinents ; - GANTT en annexe 19 pour construire le planning prĂ©visionnel du dĂ©veloppement et du dĂ©ploiement des scĂ©narii qualifiĂ©s. 6.3 - RĂŽles et responsabilitĂ©s L e S p o n s o r L'Ă©quipe de projet conduit sa dĂ©marche sur la base du mandat que le sponsor lui a confiĂ©. Le rĂ©fĂ©rentiel d'appropriation et de mise en situation pour la crĂ©ativitĂ© de l'Ă©quipe est validĂ© avec le sponsor. L'objectif est de s'assurer de la bonne comprĂ©hension du pĂ©rimĂštre du sujet. A l'issue du processus de crĂ©ativitĂ© et de sĂ©lection des scĂ©narii probables sur la base des dossiers argumentĂ©s prĂ©sentĂ©s par le chef de projet et son Ă©quipe, le sponsor choisit le scĂ©nario Ă  dĂ©velopper. Il contribue Ă  la construction du plan de communication sur le projet qui va ĂȘtre mis en Ɠuvre, le valide et apporte officiellement son cautionnement. Il missionne l'Ă©quipe de projet pour la phase de dĂ©ploiement et signe les contrats d'objectif. L e m a n a g e r d e p r o j e t Avant tout, il est le garant du bon dĂ©roulement de la phase et du processus de crĂ©ativitĂ©. Il est acteur comme ses Ă©quipiers de la construction du rĂ©fĂ©rentiel de crĂ©ativitĂ©. Il s'assure de sa bonne comprĂ©hension par chacun des membres de l'Ă©quipe. En fonction de ses compĂ©tences, il peut ĂȘtre l'animateur des sĂ©ances de crĂ©ativitĂ©, ou dĂ©lĂ©guer ce rĂŽle Ă  une personne plus adaptĂ©e. Pour certains sujets de crĂ©ativitĂ©, il peut ĂȘtre nĂ©cessaire de faire appel Ă  la prĂ©sence de personnes de l'Ă©quipe de projet pour des sĂ©ances de crĂ©ativitĂ©. Il se charge alors d'obtenir leur disponibilitĂ© et leur explique les raisons de leur implication et l'importance. Il participe activement et pilote les sĂ©ances de croisement des idĂ©es pour la construction et des scĂ©narii, ainsi qu'aux sĂ©ances d'Ă©valuation. Il entĂ©rine le choix de son Ă©quipe projet concernant les propositions prĂ©sentĂ©es pour validation au sponsor.
  • 29. GBP-LPM – 1 ÈRE EDITION – Juin 2012 29 L ' a n i m a t e u r d e s s Ă© a n c e s d e c r Ă© a t i v i t Ă© Son rĂŽle est primordial pour la qualitĂ© du travail de production d'idĂ©es en sĂ©ance. Il explique aux membres de l'Ă©quipe de crĂ©ativitĂ© et s'impose Ă  lui-mĂȘme les attitudes fondamentales nĂ©cessaires Ă  la crĂ©ativitĂ© : - Ă©coute de soi pour laisser Ă©merger les Ă©lĂ©ments prĂ©conscients et les livrer spontanĂ©ment sans autocensure ; - disponibilitĂ© aux autres pour intĂ©grer ce qui est proposĂ© sans critique ; - l'expression spontanĂ©e et l'expression par les images ; - la fluiditĂ© pour privilĂ©gier la quantitĂ© Ă  la qualitĂ© ; - la flexibilitĂ© de la dĂ©marche en fonction des occasions qui se prĂ©sentent, sans lourdeur. Dans son rĂŽle, l'animateur assure trois fonctions : - participer Ă  la production d'idĂ©es au mĂȘme titre que les autres membres ; - faciliter la tĂąche de chaque participant (libĂ©rer les timides, rĂ©guler discrĂštement les bavards, faire s'exprimer les silencieux, etc.) ; - rĂ©guler le fonctionnement du groupe (resituer, reformuler et positiver, relancer, rĂ©- impliquer, etc.). L ' Ă© q u i p e p r o j e t Le client fait totalement partie de l’équipe et prĂ©cise ses exigences tout au long de la phase d’innovation et d’engagement. Avec ses exigences, il affine les contraintes, les hypothĂšses de travail et les risques. Les membres de l'Ă©quipe s'approprient la dĂ©marche par leur implication dans la construction du rĂ©fĂ©rentiel prĂ©alable aux sĂ©ances de crĂ©ativitĂ©. Ils font partie de l'Ă©quipe de crĂ©ativitĂ©, de la gĂ©nĂ©ration des idĂ©es jusqu'Ă  la construction des scĂ©narii et leurs Ă©valuations. En sĂ©ance, ils mettent en application les attitudes fondamentales propices Ă  la qualitĂ© de production des sĂ©ances de crĂ©ativitĂ©. Le croisement des idĂ©es et la construction des scĂ©narii est de leur responsabilitĂ©, de mĂȘme que tous les travaux nĂ©cessaires Ă  l'Ă©valuation de celles-ci. L e s i n v i t Ă© s « n a ĂŻ f s » a u x s Ă© a n c e s d e c r Ă© a t i v i t Ă© En nombre trĂšs limitĂ© (1 Ă  2 personnes), l'association de ce type de profil Ă  une sĂ©ance de crĂ©ativitĂ© peut s'avĂ©rer trĂšs profitable pour accroĂźtre la richesse des propositions, surtout si les membres de l'Ă©quipe projet sont trĂšs imprĂ©gnĂ©s de l'existant. De maniĂšre gĂ©nĂ©rale, les critĂšres Ă  retenir pour le choix des profils sont : - la neutralitĂ© par rapport au sujet ; - une bonne culture gĂ©nĂ©rale ; - une capacitĂ© Ă  s'intĂ©grer et Ă  s'exprimer dans un univers nouveau tout en respectant les rĂšgles d'attitude fondamentales pour la crĂ©ativitĂ© ; - l'apport d'une expĂ©rience dĂ©calĂ©e tout en prĂ©sentant des parallĂšles avec le sujet Ă  traiter.
  • 30. GBP-LPM – 1 ÈRE EDITION – Juin 2012 30 7 - METTRE EN ƒUVRE 7.1 - Vue d’ensemble de la phase La phase « mettre en Ɠuvre » intĂšgre deux sous-ensembles importants, Ă  savoir : planifier et rĂ©aliser. Elle est spĂ©cifique Ă  chacun des projets, dont la mise en Ɠuvre reste unique. De ce fait, elle se dĂ©compose en Ă©tapes de crĂ©ation de valeur, chacune d’entre elles Ă©tant jalonĂ©e par des dĂ©cisions relatives Ă  l’acceptation du plan de management de projet tout d’abord (fin de la planification), puis des livrables (tout au long de la rĂ©alisation). La phase de mise en Ɠuvre intĂšgre donc nĂ©cessairement des activitĂ©s de tests et d’acceptation des livrables. Les Ă©tapes de la phase « Mettre en Ɠuvre » sont gĂ©nĂ©ralement envisagĂ©es Ă  l’issue de la phase « Innover et s’engager ». En effet, l’engagement se matĂ©rialise Ă  ce moment-lĂ  par le choix d’un scĂ©nario de rĂ©alisation qui sera donc dĂ©coupĂ© en Ă©tapes de crĂ©ation de valeur. Les Ă©tapes sont ensuite confirmĂ©es au dĂ©but de la phase « Mettre en Ɠuvre », c’est-Ă -dire Ă  l’issue de l’exercice de planification. Pendant la phase « Mettre en Ɠuvre », les enjeux sont donc de prĂ©voir et de maĂźtriser la crĂ©ation de valeur. Typiquement, au cours de la rĂ©alisation, l’équipe de projet s’attachera Ă  maĂźtriser les Ă©carts et les dĂ©rives potentielles du projet, la gestion des changements Ă©tant au centre des prĂ©occupations des acteurs tout au long de cette phase. 7.2 - Les outils associĂ©s Pour rĂ©aliser la phase « Mettre en Ɠuvre », les acteurs du projet devront s’appuyer sur l’ensemble des outils proposĂ©s en annexe du GBP-LPM. OUTILS UTILISATION POTENTIELLEMENT RECOMMANDEE - ANNEXE 7 - OUTILS – Management de risque = Risk management En phase de planification dans l’évaluation, la qualification, la quantification et le suivi des risques inhĂ©rents Ă  la rĂ©alisation de tout projet. En phase de rĂ©alisation si les risques se prĂ©sentent. - ANNEXE 8 - OUTILS – ThĂ©orie des Contraintes = TOC Essentiellement au moment de la planification, mais aussi pour le suivi de la mise Ɠuvre et de ses dĂ©lais/ressources, en particulier. - ANNEXE 9 - OUTILS – QUALITÉ Essentiellement au moment de la planification et de l’acceptation.
  • 31. GBP-LPM – 1 ÈRE EDITION – Juin 2012 31 OUTILS (suite) UTILISATION POTENTIELLEMENT RECOMMANDEE (suite) - ANNEXE 10 - OUTILS – ModĂšle de cotation = Scoring model Doit ĂȘtre mis Ă  jour au fur et Ă  mesure de l’avancement du projet (Ă  ses grands jalons de mise en Ɠuvre) afin de permettre Ă  la direction de prioriser le projet dans le portefeuille. - ANNEXE 11 - OUTILS - SMART (Aide Ă  la dĂ©finition d’un objectif ou indicateur) Essentiellement au moment de la planification pour dĂ©terminer les dĂ©lais, les coĂ»ts ou encore le niveau d’exigence du projet. Permettra aussi de cadrer les relations entre le chef de projet et les autres parties prenantes. - ANNEXE 12 - OUTILS - QPQQCOC (Questionnement gĂ©nĂ©rique organisĂ© = Matrice de Quintilien) Essentiellement au moment de la planification pour dĂ©terminer les activitĂ©s, les dĂ©lais, les coĂ»ts ou encore le niveau d’exigence du projet. Potentiellement pour gĂ©rer certaines « crises » pendant la mise en Ɠuvre et prendre du recul sur les situations ainsi que sur les rĂŽles et responsabilitĂ©s. - ANNEXE 15 - OUTILS – Planification par Vagues = Rolling Wave Planning Essentiellement au moment de la planification, mais aussi pour le suivi de la mise Ɠuvre et de ses dĂ©lais/ressources, en particulier. - ANNEXE 16 - OUTILS - SystĂšme dernier planificateur = Last Planner System (LPS) Essentiellement dans la planification, mais aussi au plus prĂšs du terrain lorsqu’il est nĂ©cessaire de replannifier des tĂąches ou livrables au regard de changements ou Ă©vĂšnements spĂ©cifiques. - ANNEXE 17 - OUTILS – Structure de DĂ©coupage du Projet (SDP= WBS) Essentiellement au moment de la planification, mais aussi pour le suivi de la mise Ɠuvre et la maĂźtrise de l’envergure en particulier. - ANNEXE 18 - OUTILS – PERT Essentiellement au moment de la planification, mais aussi pour le suivi de la mise Ɠuvre et de ses dĂ©lais/ressources, en particulier. - ANNEXE 19 - OUTILS - GANTT Essentiellement au moment de la planification, mais aussi pour le suivi de la mise Ɠuvre et de ses dĂ©lais en particulier. - ANNEXE 20 - OUTILS – Chaine Critique Essentiellement au moment de la planification, mais aussi pour le suivi de la mise Ɠuvre et de ses dĂ©lais en particulier.
  • 32. GBP-LPM – 1 ÈRE EDITION – Juin 2012 32 OUTILS (suite) UTILISATION POTENTIELLEMENT RECOMMANDEE (suite) - ANNEXE 21 - OUTILS – Management de la Valeur Acquise = Earned Value Management (EVM) Essentiellement en mode suivi et pour apprĂ©cier les tendances du projet sur les volets coĂ»ts et dĂ©lais. Permet de calculer des indicateurs de pilotage. - ANNEXE 22 - OUTILS – ModĂšle agile de pilotage de projet : SCRUM Pour mener Ă  bien certaines phases du projet nĂ©cessitant une gestion plus collective ou pour rĂ©pondre Ă  des situations de crise. Pilier du mode Agile. Pour plus de dĂ©tails sur cette phase « Mettre en Ɠuvre » et pour apprĂ©cier les sources d’efficacitĂ© et de gaspillage, consulter l’annexe 5. 7.3 - RĂŽles et responsabilitĂ©s Le sponsor donne les moyens au projet de fonctionner et reprĂ©sente le projet auprĂšs de la direction. Comme il est imputable de l’atteinte des objectifs et des exigences fixĂ©s pour le projet, il suit la mise en Ɠuvre de prĂšs. Le sponsor est le plus souvent le client payeur des projets de transformations organisationnelles. Comme il a fixĂ© au moment du dĂ©marrage les hypothĂšses, contraintes et limites, il assume pendant la « mise en Ɠuvre », le lien entre les livrables et les objectifs. Il reste le garant de la performance, c’est-Ă -dire de la capacitĂ© du projet Ă  minimiser ses sources de gaspillage tout en augmentant au maximum la satisfaction du client et la valeur du projet pour ce dernier. Le client utilisateur doit ĂȘtre, lui aussi, clairement impliquĂ©, mais aussi canalisĂ© dans ses vellĂ©itĂ©s de changement et ses responsabilitĂ©s sur la priorisation. S’il a dĂ©terminĂ© des exigences fonctionnelles (prĂ©alablement dans les Ă©tapes de lancement du projet), il contribue Ă  arbitrer les prioritĂ©s au moment de la mise en Ɠuvre. Dans le cas de changements (initiĂ©s par lui ou pas), ou simplement de dĂ©cisions ou d’options Ă  prendre pendant le projet, il canalise l’expertise des contributeurs/experts. Il oriente le chef de projet et le Sponsor dans l’organisation gĂ©nĂ©rale du projet. Il est particuliĂšrement prĂ©sent pour cautionner la planification proposĂ©e et accepter les livrables. Le chef de projet est clairement l’artisan principal de cette phase de mise en Ɠuvre. On le nomme souvent « le pilote ». Au moment de la planification, il est responsable de prĂ©voir les plans d’actions et les « vases communicants » entre les diffĂ©rents leviers de la planification (dĂ©lais, budget, contenu, niveau de qualitĂ©, risques, Ressources, etc.). Il propose des options de rĂ©alisation et assume les plans d’actions opĂ©rationnels qui accompagnent ces options. Au moment de la rĂ©alisation, il maĂźtrise les Ă©carts et Ă©value/propose des changements. Il est le lien entre toutes les parties prenantes du projet sans toutefois monopoliser le leadership. Dans le cas d’une gestion de projet en mode Agile selon le concept le plus utilisĂ© actuellement : SCRUM, le rĂŽle de « Scrum manager » est dĂ©terminant. Parfois, il peut ĂȘtre confondu avec celui de chef de projet, mĂȘme si cela ne reprĂ©sente pas la « Bonne pratique » (voir outils en annexe 22).
  • 33. GBP-LPM – 1 ÈRE EDITION – Juin 2012 33 8 - TRANSFERER LES RESPONSABILITES 8.1 - Vue d’ensemble de la phase C’est au cours de cette phase que la transmission de la responsabilitĂ© de l’application des rĂ©sultats du projet entre l’équipe de projet et le client sera rĂ©alisĂ©e. Elle doit donc ĂȘtre formalisĂ©e, parce qu’elle constitue la fin de la mission de l’équipe projet. Il ne s’agit pas de la clĂŽture ni du bilan du projet, mais bien d’une phase concrĂšte de travail qui consiste Ă  remettre au(x) client(s) les « clefs » du projet, Ă  lui donner les moyens d’exploiter la transformation souhaitĂ©e. Cette phase doit ĂȘtre considĂ©rĂ©e comme « la rĂ©ception » des rĂ©sultats du projet par le client et le sponsor. Elle intĂšgre le plus souvent des volets « formation » et « communication » assez prĂ©sents. Cette phase est essentielle pour la finalisation du projet et pour la pĂ©rennisation des rĂ©sultats souhaitĂ©s par le client (utilisateur). Dans un projet de transformation, la tendance classique serait de limiter cette phase et de « zapper » vers un autre projet. Si elle se dĂ©roule correctement, cette phase sera une garantie d’atteinte des rĂ©sultats du projet et de leur appropriation au sein de l’entreprise. Sa rĂ©ussite de cette phase est fortement facilitĂ©e si le client est intĂ©grĂ© Ă  l’équipe projet ou si un rapport (reporting) pĂ©riodique est effectuĂ© auprĂšs de lui par le chef de projet au cours des phases prĂ©cĂ©dentes. Il est fortement conseillĂ©, en fonction de la nature, de la complexitĂ© et de l’incidence des rĂ©sultats du projet sur le fonctionnement de l’entreprise, d’effectuer le transfert des responsabilitĂ©s de l’équipe projet au client par briques successives. Plus le projet inclura « d’agilitĂ© », plus il sera morcelĂ© en livrables courts et dĂ©finis et plus la phase de transfert de responsabilitĂ©s sera aisĂ©e et efficace. Lors de cette phase, la tentation est grande d’amĂ©liorer toujours et encore les livrables et d’aller « un peu plus loin ». Pourtant, ce n’est pas son objectif. A priori, la phase de transfert de responsabilitĂ© n’est pas une phase de production, mais plutĂŽt d’installation, comme pour un projet industriel. Il n’est en gĂ©nĂ©ral pas conseillĂ© d’exploiter cette phase pour amĂ©liorer les livrables. Il est important pour l’ensemble des acteurs de se concentrer sur l’objectif de transfert de responsabilitĂ© et de ne pas se disperser. A priori, si nous avons atteint cette Ă©tape du projet, cela signifie que les livrables ont Ă©tĂ© rĂ©alisĂ©s et acceptĂ©s lors de la phase prĂ©cĂ©dente et qu’il est nĂ©cessaire de les transfĂ©rer, de les intĂ©grer au quotidien de l’entreprise et du client qui a souhaitĂ© que le projet se rĂ©alise.
  • 34. GBP-LPM – 1 ÈRE EDITION – Juin 2012 34 A l’issue de la phase « transfĂ©rer les responsabilitĂ©s » le client dispose des Ă©lĂ©ments essentiels suivants : - un document de synthĂšse sur la rĂ©alisation du projet rappelant les attendus de celui-ci (donnĂ©es d’entrĂ©e et de sortie), les motivations de choix effectuĂ©s lors du dĂ©roulement du projet permettant, si d’autres dĂ©veloppements ultĂ©rieurs sont envisagĂ©s, d’avoir un retour d’expĂ©rience de l’équipe qui a conduit le projet ; - un cahier de procĂ©dures dĂ©taillĂ©es aidant le client et ses Ă©quipes pour la phase d’appropriation des rĂ©sultats du projet et la mise en place des modifications d’organisation induites par le projet dans l’entreprise ; - des indicateurs de performance permettant de mesurer les gains apportĂ©s par la mise en Ɠuvre des prĂ©conisations issues des rĂ©sultats du projet sur l’organisation, sachant que les valeurs de rĂ©fĂ©rence sont celles constatĂ©es avant la mise en Ɠuvre des modifications d’organisation, donc antĂ©rieures au projet ; - une information des diffĂ©rents intervenants (sponsor, client, hiĂ©rarchie, etc.) ainsi qu’un programme de formation et d’accompagnement des Ă©quipes d’utilisateurs du client. En fonction de la complexitĂ© du changement d’organisation induit par les rĂ©sultats du projet, le manager de projet devra prĂ©voir un « Service AprĂšs-Vente » de la mise en Ɠuvre du projet adaptĂ© au mode de fonctionnement de l’entreprise sous forme de rĂ©unions pĂ©riodiques pendant quelques mois, ou sous forme de tĂ©lĂ©assistance (hot-line). 8.2 - Les outils associĂ©s Voir fiches outils suivantes en annexe : - modĂšle de cotation (Scoring model) en annexe 10 : pour reboucler sur la valeur attendue et imaginĂ©e du projet Ă  son lancement ; - SDP (Structure de DĂ©coupage du Projet) en annexe 17 : pour s’assurer que l’ensemble des livrables ont bien Ă©tĂ© transfĂ©rĂ©s. 8.3 - RĂŽles et responsabilitĂ©s Au cours de cette phase, les rĂŽles et responsabilitĂ©s de chacun des intervenants sont les suivants : Chef de projet : comme dans toutes les autres phases du projet, son rĂŽle est essentiel. Il s’agit ici essentiellement d’un rĂŽle « pĂ©dagogique ». Le chef de projet doit savoir donner l’autonomie suffisante Ă  son client pour que ce dernier intĂšgre les livrables dans son environnement opĂ©rationnel et se les approprie.
  • 35. GBP-LPM – 1 ÈRE EDITION – Juin 2012 35 Client et/ou utilisateur : son rĂŽle est prĂ©pondĂ©rant puisqu’il devient, Ă  l’issue de cette phase, celui qui va officiellement utiliser les livrables. Il s’engage Ă  mettre en Ɠuvre les rĂ©sultats de projet auprĂšs de ses Ă©quipes, qu’il sensibilisera si nĂ©cessaire. Il Ă©change avec le chef de projet sur les activitĂ©s de transfert et d’accompagnement proposĂ©es par celui-ci. Il enregistre les valeurs des indicateurs de mesure des rĂ©sultats issus de la mise en Ɠuvre du projet et tient Ă  jour un Ă©tat des Ă©ventuelles dĂ©rives ou non-performances constatĂ©es. Sponsor : Il doit s’assurer essentiellement de la rĂ©alitĂ© du transfert opĂ©rationnel et de la satisfaction du client Ă  ce moment prĂ©cis du projet. Il doit veiller Ă  ce que cette phase ne dure pas trop longtemps et ne soit pas l’occasion de « refaire » le projet.
  • 36. GBP-LPM – 1 ÈRE EDITION – Juin 2012 36 9 – CLOTURER ET FAIRE LE BILAN 9.1 - Vue d’ensemble de la phase Cette phase termine le projet. Le client doit bien entendu y ĂȘtre associĂ©. Il s’agira d’effectuer un bilan sur l’ensemble des livrables prĂ©vus incluant les modifications prises en compte en cours de projet et de mesurer les Ă©carts par rapport aux livrables rĂ©alisĂ©s. Avant la cĂ©lĂ©bration des rĂ©ussites et la dissolution effective de l’équipe projet, ses derniĂšres rĂ©alisations seront de terminer les documents et d’évaluer le processus rĂ©ellement suivi par le projet (appelĂ© communĂ©ment REX pour « retour d’expĂ©rience » ou « post-mortem »). Vous trouverez ci-dessous, classĂ©es par ordre chronologique, les Ă©tapes clĂ©s de la phase « clĂŽturer et faire le bilan » et les risques envisagĂ©s en cas de non application : - DĂ©cider de clĂŽturer le projet. Cette dĂ©cision se prend en association avec le client, sur la base d’un bilan des livrables prĂ©vus et des livrables Ă  terminer. Risque : paradoxalement, vouloir Ă  tout prix rĂ©aliser l’intĂ©gralitĂ© des livrables prĂ©vus initialement ou satisfaire de façon exhaustive les demandes complĂ©mentaires du client peut amener l’équipe projet Ă  s’épuiser sur des reliquats de « reste-Ă -faire », se dĂ©courager et perdre en efficacitĂ©, en luciditĂ© par rapport au bienfondĂ© des requĂȘtes. En effet, certaines demandes rĂ©siduelles peuvent s’avĂ©rer trĂšs longues et/ou coĂ»teuses, et garder l’équipe projet trop longtemps encore mobilisĂ©e sous le prĂ©texte de « terminer » le projet n’est pas la rĂ©ponse adaptĂ©e. Mieux vaut clore le projet et Ă©ventuellement ouvrir un autre projet dans la foulĂ©e, en repassant par les 5 phases du cycle de vie si nĂ©cessaire. L’approche « Agile » des projets Ă©vite en gĂ©nĂ©ral cette situation, car elle permet de se poser la question de l’intĂ©rĂȘt d’un nouveau sprint en « objectivant » son rapport « bĂ©nĂ©fices/efforts ». - Effectuer un bilan complet. Le bilan portera tant sur les livrables que sur les aspects budgĂ©taires et dĂ©lais, ainsi que sur le processus suivi pour rĂ©aliser le projet. Ce bilan est constituĂ© d’un Ă©tat des lieux gĂ©nĂ©ral du projet et d’un ensemble de « leçons apprises ». Le bilan devra enfin intĂ©grer un chapitre sur la satisfaction du client. Les questions Ă  se poser : ‱ Quels documents garder/archiver pour le futur ? Qui, quand, comment, 
 ‱ Les objectifs du projet ont-ils Ă©tĂ© atteints ? Quels objectifs ne l’ont-ils pas Ă©tĂ© ? ‱ Quels ont Ă©tĂ© les coĂ»ts rĂ©els du projet, les bĂ©nĂ©fices et les dĂ©penses futures ? Quelle est la rentabilitĂ© rĂ©elle ? ‱ Quels dĂ©lais ont Ă©tĂ© tenus, lesquels ne l’ont pas Ă©tĂ© et pourquoi ? ‱ Comment s’est dĂ©roulĂ© le processus du projet ? Quelles difficultĂ©s particuliĂšres, quelles rĂ©ussites ? ‱ Quelle est la satisfaction du client ? Comment cela est-il mesurĂ© ? ‱ Quelles leçons en tirer pour le futur ? Risque : si ce bilan n’est pas fait, chacun va se faire une opinion subjective et les faits ne seront pas respectĂ©s. De plus, il n’y aura pas de capitalisation de l’expĂ©rience ni d’amĂ©lioration pour les futurs projets semblables. Il est important de bien prendre en compte les retours des diffĂ©rentes parties prenantes. - CĂ©lĂ©brer la fin du projet consiste Ă  marquer l’évĂ©nement par un moment particulier entre les protagonistes.
  • 37. GBP-LPM – 1 ÈRE EDITION – Juin 2012 37 Risque : ne pas prendre le temps de cĂ©lĂ©brer la fin de projet pourrait nuire Ă  la remobilisation des Ă©quipes sur les futurs projets. C’est en effet une façon de reconnaitre la contribution de chacun et un formidable moyen de souder les Ă©quipes par la prise de conscience de rĂ©alisation d’une « Ɠuvre » commune. La cĂ©lĂ©bration permettra Ă©galement de communiquer lisiblement Ă  toutes les parties prenantes que le projet n’est dĂ©sormais plus portĂ© par l’équipe l’ayant dĂ©veloppĂ©. La cĂ©lĂ©bration doit donc ĂȘtre proche de la dissolution de l’équipe projet, qui clĂŽt dĂ©finitivement le projet. 9.2 - Les outils associĂ©s Le bilan du projet est la derniĂšre occasion de mettre Ă  jour le Gantt, l’analyse de risque, le suivi budgĂ©taire (cf. « Earned Value » Management de la valeur acquise). La qualitĂ© a un rĂŽle prĂ©pondĂ©rant dans cette phase en s’assurant qu’elle est rĂ©ellement pratiquĂ©e et en recueillant les Ă©lĂ©ments Ă  suivre dans le futur en termes de management de la qualitĂ© en fonctionnement courant. 9.3 - RĂŽles et responsabilitĂ©s Les principaux acteurs intĂ©ressĂ©s : Le sponsor du projet doit s’assurer que ce bilan est prĂ©parĂ© et fait dans de bonnes conditions. Il aura en gĂ©nĂ©ral la responsabilitĂ© de dĂ©cider et mettre en Ɠuvre les prĂ©conisations remontĂ©es lors du bilan. Le chef projet coordonne ce bilan et s’assure de l’implication de tous, en particulier de celle du ou des clients (internes ou externes). Les acteurs clefs du projet, comme le client, sont associĂ©s Ă  ce bilan. Le reprĂ©sentant du service qualitĂ© doit s’assurer que le processus « bilan de projet » soit bien rĂ©alisĂ©, il doit enregistrer les besoins d’évolution, les mettre en Ɠuvre au sein des processus et veiller Ă  leur bon fonctionnement au quotidien. Il s’assure aussi du transfert de responsabilitĂ© auprĂšs des nouveaux responsables.
  • 38. GBP-LPM – 1 ÈRE EDITION – Juin 2012 38 ANNEXE 1 L’annexe 1 prĂ©sente l’historique du Lean Manufacturing. ANNEXES 2 A 7 Pour des raisons de mise en page en paysage et sous forme de tableaux, vous trouverez les annexes 2 Ă  7 Ă  la fin de notre guide (Ă  partir de la page 84). INTRODUCTION AUX ANNEXES-OUTILS (ANNEXES 7 A 23) L’ensemble du GBP-LPM a Ă©tĂ© Ă©crit pour les lecteurs qui souhaitent dĂ©velopper leurs connaissances et compĂ©tences sur le Lean, appliquĂ© Ă  la Gestion des Projets de Transformation Organisationnelle. Pour rappel, de tels projets sont initiĂ©s afin de faire Ă©voluer les pratiques, les processus, les rĂŽles ou les responsabilitĂ©s dans le but de corriger une non performance ou bien d’anticiper et d’atteindre un niveau de performance souhaitĂ©. Selon le lecteur concernĂ©, ces annexe-outils vont permettre de : - faire dĂ©couvrir ou approfondir des outils souvent utilisĂ©s en gestion de projet, - choisir l’outil le plus adaptĂ© Ă  la situation, selon l’étape du cycle ou selon le type de projet, - mettre en valeur les possibilitĂ©s et les limites de ces outils. Elles ont Ă©tĂ© crĂ©Ă©es afin d’ĂȘtre accessibles Ă  tous nos lecteurs quel que soit leur niveau de connaissance initiale. APPROPRIATION ET UTILISATION DES OUTILS Nous avons choisi, par expĂ©rience, de prĂ©senter ces outils dans un ordre chronologique optimal Ă  leur utilisation. NĂ©anmoins nous soulignons le fait qu’ils peuvent ĂȘtre utilisĂ©s sĂ©parĂ©ment, et qu’il n’y a aucune nĂ©cessitĂ© de tous les utiliser, et ceci pour plusieurs raisons : - ils requiĂšrent diffĂ©rents niveaux de maturitĂ© ; - ils requiĂšrent diffĂ©rents dĂ©lais de mise en Ɠuvre ; - ils sont adaptĂ©s Ă  des projets plus ou moins agiles, plus ou moins dĂ©finis.
  • 39. GBP-LPM – 1 ÈRE EDITION – Juin 2012 39 ANNEXE 1 : METHODOLOGIES DU LEAN MANUFACTURING Le Lean Manufacturing est une mĂ©thode visant Ă  atteindre l’excellence industrielle pour tous les processus de l’entreprise. Elle est basĂ©e sur le principe de l’amĂ©lioration continue. Elle consiste en une logique d’amĂ©lioration continue en progressant par petits pas (KAIZEN) et en utilisant « l’effet cliquet », c'est-Ă -dire sans retour en arriĂšre. Plusieurs mĂ©thodes itĂ©ratives peuvent ĂȘtre employĂ©es, par exemple : Le DMAIC est une mĂ©thode itĂ©rative. A la fin de chaque projet il est possible de s’en fixer un nouveau afin de tendre vers l’excellence. Figure 9 –Cycle DMAIC Source : « graphique original GR LPM » 2012 D : DĂ©finir : DĂ©finition du projet et du pĂ©rimĂštre d’action du processus Ă  amĂ©liorer.. M : Mesurer : Mise en place d’indicateur de mesure de la performance du processus. A : Analyser : Identifier les causes de dĂ©rive du processus. I : (Improve) AmĂ©liorer : Mise en place d’un plan d’actions d’amĂ©lioration du processus. C : ContrĂŽler : VĂ©rification de l’atteinte des objectifs, formalisation du nouveau processus et clĂŽture projet.
  • 40. GBP-LPM – 1 ÈRE EDITION – Juin 2012 40 Le Kaizen : Principe d’amĂ©lioration continue impliquant tous les salariĂ©s (et nĂ©cessitant donc l’adhĂ©sion de tous) dont la dĂ©marche cohĂ©rente, procĂšde Ă©tape par Ă©tape, par sous-groupes de travail, afin d’atteindre les objectifs suivants : - rendre le travail plus motivant et plus efficient - amĂ©liorer l’environnement de travail - mettre Ă  jour les procĂ©dures Le PDCA ou Roue de Deming est aussi une mĂ©thode itĂ©rative d’amĂ©lioration continue Figure 10 –PDCA et la roue de Deming Source : « graphique original GR LPM » 2012 P : Planifier : DĂ©finir le projet sur lequel on va travailler. D : DĂ©velopper : RĂ©alisation du projet. C : ContrĂŽler : ContrĂŽle des prestations rĂ©alisĂ©es avec mesure de la performance. A : Ajuster : Actions correctives et dĂ©cision de lancer un nouveau projet. La cale sous la roue de Deming Ă©vite de revenir en arriĂšre, il s’agit de la formalisation de la capitalisation de l’expĂ©rience, du SystĂšme QualitĂ©, des audits de performance, 

  • 41. GBP-LPM – 1 ÈRE EDITION – Juin 2012 41 Voici quelques exemples d’outils frĂ©quemment utilisĂ©s dans le Lean Manufacturing : Le 5S : Une sous-Ă©tape habituelle du kaizen est la mĂ©thode 5S oĂč l’on procĂšde en 5 Ă©tapes Ă  amĂ©liorer l’espace de travail. Il s’agit aussi bien du poste de travail d’un atelier que d’un bureau ou encore du bureau virtuel d’un ordinateur. - Seiri : Supprimer => Se Ă©barrasser de tout ce qui est inutile de l’espace de travail - Seiton : Situer les objects, => Organiser de façon efficace le nouvel espace de travail avec dĂ©finition de nouvelles rĂšgles de rangement, 
 - Seiso : SaletĂ© Ă  proscrire => Nettoyer et laisser systĂ©matiquement propre - Seiketsu : Suivi des rĂšgles => Standardiser, mettre en place des consignes permettant de respecter et faire perdurer les 3 Ă©tapes en amont. Identification de zones visuelles de placement, formation du personnel, 
 - Shitsuke : Satisfaire => Progresser : Cette derniĂšre Ă©tape est une Ă©tape d’amĂ©lioration continue oĂč les salariĂ©s s’approprient les actions : responsabiliser chacun, mise en place de contrĂŽles, 
 Les 5 « pourquoi » : La pratique des 5 pourquoi est la base d'une mĂ©thode de rĂ©solution de problĂšmes proposĂ©e adaptable Ă  tous les processus d’une entreprise. Il s'agit de poser la question pertinente commençant par un pourquoi afin de trouver la source, la cause principale de la dĂ©faillance. Cette mĂ©thode de travail est surtout faite pour trouver la cause principale du problĂšme rencontrĂ©. Avec 5 questions commençant par « pourquoi », on essaie de trouver les raisons les plus importantes ayant provoquĂ© la dĂ©faillance pour aboutir Ă  la cause principale et aider l’éradiquer. Le Kanban : Un kanban (terme japonais signifiant « fiche » ou « Ă©tiquette ») est une simple fiche cartonnĂ©e que l'on fixe sur les bacs ou les conteneurs de piĂšces dans une ligne d'assemblage ou une zone de stockage. Ceci est devenu une mĂ©thode qui consiste Ă  mettre en place des affichages pour Ă©viter la constitution d'en-cours trop importants.
  • 42. GBP-LPM – 1 ÈRE EDITION – Juin 2012 42 ANNEXE 7 : MANAGEMENT DE RISQUE (RISK MANAGEMENT) L’objectif /Plus-value de l’outil  Gagner en efficacitĂ© dans la rĂ©alisation d'un projet de transformation par une dĂ©marche d'anticipation et de prĂ©vention des risques de non atteinte des objectifs. Cette dĂ©marche se doit d’ĂȘtre construite, simple et orientĂ©e vers l’action. Description Un projet se dĂ©finit par ses finalitĂ©s exprimĂ©es en fonctionnalitĂ©s et performances, objectivĂ©es par les niveaux des prestations Ă  atteindre. La phase de conception a pour but de choisir des principes de solutions, et la phase de dĂ©veloppement / implantation concrĂ©tise la transformation grĂące aux plans d'action. Ces plans d'action engendrent des activitĂ©s (et/ou processus) collectives et/ou individuelles, lesquelles consomment des ressources humaines, matĂ©riels, financiĂšres, 
 (cf. activity based costing = MĂ©thode des coĂ»ts par activitĂ© ). Les risques de non aboutissement des objectifs d'un projet de transformation ont donc trois sources potentielles, Ă  savoir : A. Les objectifs et les niveaux de prestations inaccessibles aux dispositifs opĂ©rationnels disponibles, B. Des activitĂ©s (et/ou processus) inopĂ©rantes, C. Des ressources dĂ©faillantes. DĂ©marche Etape 1 "Le calage"  VĂ©rifier l'adĂ©quation entre le niveau d'ambition et les activitĂ©s et ressources nĂ©cessaires. Celui-ci peut s’avĂ©rer nĂ©cessaire mais paraĂźtre inaccessible en fonction des moyens disponibles. Dans ce cas, la solution est de dĂ©composer l’ambition initiale en Ă©tapes successives, fondĂ©es sur des activitĂ©s (et/ou processus) et l’emploi de ressources rĂ©alistes. L'absence de consĂ©quences de nature stratĂ©gique doit ĂȘtre vĂ©rifiĂ©e, les dĂ©lais et coĂ»ts supplĂ©mentaires du projet doivent ĂȘtre Ă©valuĂ©s prĂ©cisĂ©ment. L'ensemble doit ĂȘtre formellement acceptĂ© par le sponsor du projet. Etape 2 "L'inventaire" Les ambitions Ă©tant calĂ©es, la mĂ©thode de management des risques consiste Ă  analyser en anticipant les possibilitĂ©s de dĂ©faillance sur les activitĂ©s (et/ou processus) ou sur les ressources. Exemples de risques processus : non application des mĂ©thodes de la gestion de projet, dysfonctionnement de son processus de pilotage et de dĂ©cision, communication insuffisante, non- respect des lois, 

  • 43. GBP-LPM – 1 ÈRE EDITION – Juin 2012 43 Exemples de risques sur les ressources : absence de dĂ©cideur lors des comitĂ©s de pilotage, manque de moyens financiers, manque d’une compĂ©tence d'expert, 
 La mĂ©thode consiste Ă  inventorier de façon prospective les risques de dĂ©faillance pour chacune des activitĂ©s (et/ou processus) clĂ©s et pour chaque type de ressource nĂ©cessaire. L'attention premiĂšre doit ĂȘtre portĂ©e sur les ressources uniques. Ce travail est Ă  faire en sĂ©ance d'Ă©quipe projet, Ă©ventuellement complĂ©tĂ©e de personnes d'expĂ©rience. Etape 3 "La priorisation" Tous les risques n'ont pas la mĂȘme probabilitĂ© de se produire (occurrence), ni les mĂȘmes consĂ©quences (gravitĂ©). L'Ă©quipe d'analyse de risque dĂ©finit pour chaque risque la gravitĂ© et l'occurrence. Cette Ă©tape peut nĂ©cessiter de prendre des renseignements auprĂšs de responsables mĂ©tiers ne participant pas Ă  la rĂ©union de travail. Exemple d'outil : Choix de l'Ă©chelle de cotation d’occurrence : 3 - la solution existe et peut ĂȘtre intĂ©grĂ©e ainsi dans le projet 5 - la solution existe mais demande des adaptations pour ĂȘtre appliquĂ©e au projet 15 - la solution n'existe pas et nĂ©cessite d'ĂȘtre dĂ©veloppĂ©e. Choix de l’échelle de cotation de gravitĂ© : 3 – une dĂ©faillance n'a pas d'impact sur les objectifs QDC du projet 5 – une dĂ©faillance peut ĂȘtre corrigĂ©e dans les marges libres du projet 15 – une dĂ©faillance remet fortement en cause les objectifs QDC du projet Figure 11 Source : « graphique original GR LPM » 2012 Etape 4 "La prĂ©vention" Les risques 225 puis 75 sont Ă  prioriser pour construire les plans de prĂ©vention en rĂ©duction du niveau de risques. Pour chaque risque, le chemin Ă  parcourir Ă©tant clarifiĂ©, les plans "quoi x qui x quand" sont documentĂ©s et gĂ©rĂ©s. Lorsque la pertinence des actions prĂ©vues sur les activitĂ©s (et/ou processus) et les ressources est remise en cause, le retour Ă  l'Ă©tape 1 de la dĂ©marche s'impose. Etape 5 "Le pilotage" La gestion des risques est de dimension stratĂ©gique. A ce titre, elle fait partie du tableau de bord du projet. Les risques majeurs et l'avancement des plans d'action en rĂ©duction sont Ă  prĂ©senter lors de chaque comitĂ© de pilotage projet.
  • 44. GBP-LPM – 1 ÈRE EDITION – Juin 2012 44 Etape 6 "La mise Ă  jour" Au fur et Ă  mesure de l'avancement du projet de transformation des Ă©vĂšnements non attendus se produisent, des objectifs peuvent ĂȘtre recalĂ©s, et de nouvelles ambitions apparaitre. De façon pĂ©riodique, la dĂ©marche de prĂ©vention des risques doit ĂȘtre revisitĂ©e, voire reprise. Il est du ressort du chef de projet et de son Ă©quipe de faire vivre ce processus itĂ©ratif. Recommandations de mise en Ɠuvre  DĂ©marche d'Ă©changes et de concertations de l'Ă©quipe projet avec son environnement.  L'utilisation de l'outil doit rester simple en se basant avant tout sur une approche intuitive et opĂ©rationnelle.  Le nombre de risques gĂ©rĂ©s doit rester limitĂ©.
  • 45. GBP-LPM – 1 ÈRE EDITION – Juin 2012 45 ANNEXE 8 : TDC - THEORIE DES CONTRAINTES (THEORIE OF CONSTRAINTS -TOC) L’origine du terme employĂ© : Les travaux d’E.Goldratt publiĂ©s pour la premiĂšre fois en 1984 (The Goal « Ă©dition française « Le but ») sont Ă  l’origine de cette mĂ©thode. Selon le terme « thĂ©orie des contraintes », il propose que tout systĂšme complexe comporte plusieurs contraintes, mais qu’il peut ĂȘtre « rendu plus efficace » Ă  moindre effort, si l’on identifie et amĂ©liore sa « contrainte principale ». L’objectif /Plus-value de l’outil : Cette thĂ©orie a pour particularitĂ© notable qu’elle ne considĂšre pas les contraintes comme des Ă©lĂ©ments nĂ©gatifs du systĂšme mais suggĂšre de les utiliser Ă  notre avantage. La plus value de cet outil s’avĂšre ĂȘtre une mĂ©thode d’analyse des systĂšmes complexes pour identifier les points principaux Ă  amĂ©liorer. Description : Le cheminement d’amĂ©lioration proposĂ© est gĂ©nĂ©rique. Quelle que soit la nature du processus Ă  amĂ©liorer, il peut se schĂ©matiser en 5 Ă©tapes clĂ©s : 1. Identifier la contrainte 2. Augmenter l’utilisation de la contrainte 3. Subordonner les autres activitĂ©s Ă  la contrainte 4. Ajuster la performance de la contrainte 5. Recommencer depuis l’étape 1 (si nĂ©cessaire) DĂ©marche : 1 Identifier la contrainte Dans un premier temps, l’analyse du systĂšme doit permettre d’identifier la contrainte principale, c’est-Ă -dire l’étape du processus, qui, par sa lenteur supĂ©rieure, empĂȘche les autres Ă©tapes de produire Ă  leurs capacitĂ©s maximum. 2 Augmenter l’utilisation de la contrainte Dans un deuxiĂšme temps, il faut s’assurer que le processus actuel utilise bien l’étape-contrainte au maximum de ses capacitĂ©s de production. Dans le cas contraire, il faut en prioritĂ© prendre des actions directes pour utiliser en permanence l’étape contrainte. Il faut aussi s’assurer que la contrainte est « protĂ©gĂ©e », c’est-Ă -dire que toutes les Ă©tapes amont du processus sont organisĂ©es de façon Ă  toujours alimenter l’étape-contrainte, et que celle-ci aie toujours les ressources pour produire en permanence au maximum de sa capacitĂ©.
  • 46. GBP-LPM – 1 ÈRE EDITION – Juin 2012 46 3 Subordonner les autres activitĂ©s Ă  la contrainte Dans un troisiĂšme temps, toutes les Ă©tapes du processus en amont de la contrainte doivent ĂȘtre rythmĂ©es en fonction de la capacitĂ© de la contrainte, afin de ne pas prendre trop d’avance (inutile de prendre une avance qui ne pourra ĂȘtre absorbĂ©e). 4 Ajuster la performance de la contrainte Dans un quatriĂšme temps, une fois le processus optimisĂ© et rythmĂ©, il est temps d’analyser l’étape- contrainte pour identifier les actions possibles permettant d’augmenter ses capacitĂ©s de production. Il faut souligner qu’il n’aurait pas Ă©tĂ© opportun d’essayer d’augmenter la capacitĂ© de la contrainte avant mĂȘme d’avoir optimisĂ© le processus global. 5 Recommencer depuis l’étape 1 (si nĂ©cessaire) Une fois les quatre premiĂšres Ă©tapes terminĂ©es, il est possible de revenir Ă  l’étape n°1, pour essayer d’identifier une nouvelle contrainte principale qui limite notre nouveau processus optimisĂ©.