Les 3 piliers du développement professionnel

savoir savoir-faire savoir-être


"Parler est une nécessité, écouter est un art !!" Goethe

Citations sur la conduite du changement :

La conduite de changement exige souvent un gros effort de communication. Pour appuyer ou illustrer votre discours, je vous propose quelques citations. Vous pouvez les commenter et nous faire partager les vôtres.

Changement


"Le progrès ce n'est rien d'autre que la révolution faite à l'amiable." Victor Hugo

"C'est contre le vent, et non dans le sens du vent que les cerfs-volants volent le plus haut." Winston Churchill

"Il faut prendre très tôt de bonnes habitudes surtout celles de savoir changer souvent et facilement d'habitudes." Pierre Reverdy

"Ce n'est pas seulement le monde qu'il s'agit de changer, mais l'homme." André Gide

"Un objectif bien défini est à moitié atteint." Abraham Lincoln

"L'art le plus difficile n'est pas de choisir les hommes mais de donner aux hommes qu'on a choisis toute la valeur qu'ils peuvent avoir." Napoléon Bonaparte

"Certains déclarent que le succès ne peut naître que de l'exploitation de circonstances favorables. il faut donc, d'abord, les provoquer." Charles de Gaulle

"La gloire des grands hommes se doit toujours d'être mesurée aux moyens dont ils se sont servis pour l'acquérir." La Rochefoucauld


"Dans la vie, il y a deux catégories d'individus : ceux qui regardent le monde tel qu'il est et se demandent pourquoi. Ceux qui imaginent le monde tel qu'il devrait être et qui se disent : pourquoi pas ?" Georges-Bernard Shaw

"Il faut mieux penser changement que changer le pansement." Francis Blanche

"Celui qui a un « Pourquoi » qui lui tient lieu de but, de finalité, peut vivre avec n'importe quel « Comment »." Friedrich Nietzsche

"Seuls les bébés mouillés aiment le changement." Daniel Kahneman

"Le grand art, c'est de changer pendant la bataille. Malheur au général qui arrive au combat avec un système." Napoléon Bonaparte

"Rien n'est permanent, sauf le changement." Heraclite d'Ephese

"Le monde déteste le changement, c’est pourtant la seule chose qui lui a permis de progresser." Charles F. Kettering

"Les choses ne changent pas, change ta façon de les voir, cela suffit." Lao Tseu

Multipliez les ruptures !

Aujourd'hui les innovations incrémentales où les produits sont améliorés progressivement ne répondent plus aux besoins des entreprises (l'espérance de vie des « vaches à lait » sont plus courtes). Les entreprises ont besoin de nouveaux produits et services pour continuer leur progression et pour certaines, pour survivre. Bien-sûr les innovations de ruptures ont toujours existé mais aujourd'hui, le rythme s'accélère. Les entreprises ont besoin de se différencier de leurs concurrents et de prendre une longueur d'avance pour éviter de se battre sur un marché concurrentiel où le prix est maître.

Pour aider les entreprises en manque d'innovation de rupture, il existe des méthodes qui les guident à imaginerles produits ou les services de demain.

Une de ces méthodes se nomme la théorie C-K. La semaine dernière, j'ai pu assister à une présentation participativede cette méthode organisée par le Cnam et Stereolux : les réveils créatifs. À titre d'exemple, nous avons planché en groupe sur l’idée d'un "stylo innovant". Les résultats furent assez étonnants et abondants, en seulement une heure de temps. Cette méthode permet des espaces de réflexion en passant des Concepts aux Connaissances (Knowledge)et vice-versa pour découvrir des champs inexploités et des produits innovants. Elle nous force à avoir un double regard pour imaginer l'inconnu en passant par les phases : impensable, impossible, imaginable, faisable.

Je ne vais pas ici vous présenter cette méthode car je préfère vous orienter vers deux sources qui expliquent bien très cette théorie, de manière complémentaire :

 - La fabrique de l'innovation de Gilles Garel et Elmar Mock

 

- First Steps in Fielding C-K Theory de Philippe Blanchard et Patrick Corsi (https://itunes.apple.com/fr/book/first-steps-in-fielding-c/id684752910?mt=11 ) - gratuit sur ipad

« Faites quelque chose que les gens veulent … Rien n'a plus de valeur qu'un besoin insatisfait en train d'être satisfait. Si vous trouvez un problème que vous pouvez réparer pour un grand nombre de personnes, vous avez déniché une mine d'or. » Paul Graham

Retour sur l'histoire d'un grand projet réussi - Livre

Je vous livre ma dernière trouvaille : une analyse du fonctionnement du chantier de la Tour Eiffel, organisation remarquable à plus d'un titre pour la réussite de ce projet.

"Piloter un projet comme Gustave Eiffel. Comment mener un projet contre vents et marées".  Anne Vernès Eyrolles


La tour Eiffel est une œoeuvre collective grandiose. Sa construction fut un projet conséquent et risqué (300 mètres de haut et 26 mois de construction). Pour autant, elle fut terminée à temps pour l'exposition Universelle de 1889.

Le chef d'orchestre de cette réussite est bien évidement l'ingénieur Gustave Eiffel qui a développé ses propres principes pour atteindre son objectif.

Il avait notamment opté pour une Organisation et Constitution des équipes originales :

    - la structure de l'organisation était composée d'équipes de 4 à 5 personnes gérées par un responsable. Les responsables étaient très pointus dans leur domaine et faisaient preuves d'agilité managériale (forte collaboration avec les autres équipes). Avant d'être choisi pour cette fonction, les postulants devaient réaliser un stage d'intégration pour valider les compétences techniques et comportementales. Gustave Eiffel avait défini clairement 3 qualités indispensables : l'agilité (technique et comportementale), la prudence et l'exemplarité.

Il pratiquait une communication ouverte et transparente :

    - Pour répondre à certaines critiques, le chantier étaient ouvert à tous et Gustave Eiffel demandait à ses collaborateurs de devenir les ambassadeurs du projet.

Il valorisait le rôle des membres du projet :

    - Gustave Eiffel n’hésitait pas féliciter ses équipes et à les mettre en valeur dans ses discours. Il précisait des exemples et des faits qui avaient contribué à l'avancement du projet et à la parfaite coordination entre les équipes. En fin, il célèbrait la fin du projet avec ses équipes en leur délivrant des signes de reconnaissances.

Ces points sont les secrets de la réussite de tout projet.

« Il faut mieux penser changement que changer le pansement. » Francis Blanche.

Donner du sens à vos projets ?


Angela Lee Duckworth lors de sa conférence TED explique que la réussite repose sur la ténacité. Je suis assez d'accord avec elle, seulement, elle n'explique pas comment obtenir cette persévérance.


Je crois avoir la réponse à cette question. Pour faire preuve de ténacité, il faut mettre du sens, accorder de la signification à nos projets. Viktor E. Frankl nous explique dans son livre « Découvrir un sens à sa vie » que la motivation principale de l'individu n'est pas la volonté de plaisir ou de la volonté de puissance, mais la volonté de sens. Une citation de Nietzsche résume assez bien cette idée : Celui qui a un « Pourquoi » qui lui tient lieu de but, de finalité, peut vivre avec n'importe quel « Comment. »"



Nous avons besoin d'une raison pour décider d'agir et de passer à l'action. Plus la raison sera grande plus notre ténacité sera forte.

Cette idée de quête de sens est utile pour nos propres projets mais elle peut être aussi profitable pour des projets collectifs.

Souvent dans les entreprises, les projets s’enchaînent sans que les "décideurs" ne prennent le temps d'expliquer aux équipes les raisons qui les motivent. En donnant de la signification aux projets, vos collaborateurs seront également moins réfractaires au changement parce que ces décisions leur auront été expliquées.

En résumé pour obtenir l'adhésion et la persévérance des équipes sur un projet, il y a tout intérêt à expliquer les raisons et/ou la signification de l'objectif à atteindre.

L’IBM i : un « Future System de niche » ou un système du futur ? - Lettre RePeGlio


A l’occasion du 25ième anniversaire de l’IBM i, nous pensons qu’il est nécessaire de revisiter l’histoire du S/38 car comme dit le proverbe: « si tu veux savoir où tu vas, regardes d’où tu viens ». Le système S/38 ancêtre de l’AS/400 et de l’IBM i, est l’héritier d’aucun système connu (voir schéma). D’où la question centrale : pourquoi le management d’IBM a-t-il eu l’idée saugrenue de créer de toute pièce en 1975 un système propriétaire totalement incompatible, encore aujourd’hui, avec les mainframes et les moyens systèmes, aussi bien ceux d’IBM que ceux de la concurrence?

Cette énigme *extrêmement intéressante* a aiguisé notre curiosité. Nous avons mené une enquête pour nos lecteurs de la lettre RePeGlio. Commençons par écarter l’explication de Frank Soltis, à laquelle nous avons cru un moment mais qui nous parait raccourcie.

Frank Soltis tente de justifier les singularités de l’AS/400 par l’isolement de la ville Rochester dans le Minnesota. Le laboratoire de Rochester, dit-il, n’avait pas réussi à embaucher des diplômés de la côte Est, de sorte que les créateurs du S/38 ne connaissaient rien à l’architecture des ordinateurs et sont partis de ce fait d’une conception radicalement nouvelle. Toujours selon Frank Soltis, le S/38 ne serait pas une décision du management d’IBM mais aurait été créé à partir d’un budget supplémentaire car, ajoute Frank Soltis, il est plus facile de se faire pardonner après coup que de demander.

Cependant, il existe une autre version sur l’origine du S/38. Un petit Flash-back comme au cinéma s’impose:
    Au début des années 70, IBM avait financé un projet gigantesque appelé « Future System ». Ce projet ultra stratégique avait été conduit par le vice-président d’IBM de l’époque John Opel. Ce qui avait justifié ce projet était l’avenir très sombre que les experts prédisaient aux mainframes. A l’époque, tous les experts (envieux ?) prétendaient que les mainframes d’IBM étaient des dinosaures qui seraient inéluctablement balayés par les systèmes plus simples et beaucoup moins couteux de la concurrence. Le « Future System» avait justement pour vocation de simplifier l’architecture des mainframes et diminuer les coûts de fonctionnement de façon drastique en partant de concepts révolutionnaires (qui vous sont familiers), dont:
    • « single-level store » espace adressable unique ou mémoire virtuelle afin d’accéder aux objets et à la base de données de façon uniforme en faisant abstraction de la notion d’adresse.
    • Base de données intégrée.
    • Utilisation des API afin de rendre le software indépendant de la technologie.
   
Le projet « Future System » fut interrompu en 1975. Ce système qui devait remplacer les mainframes était incompatible avec les mainframes System/370 alors en usage. En effet pour migrer vers « Future System » les clients auraient dû réécrire les applications. Les objectifs étaient trop ambitieux pour les processeurs de l’époque. Surtout, la fin des mainframes, régulièrement annoncée comme étant inéluctable, n’eut jamais lieu. Contre toute attente, non seulement les mainframes ne furent pas inquiétés par les concurrents, mais au contraire les clients demandaient à IBM seulement des investissements dans les systèmes existants, ce qui fut fait, et non une rupture technologique majeure. (Comme les clients S/36 qui demandaient eux aussi la continuité, il fut proposé finalement une émulation 36 avec l’AS/400).



En 1975, selon nous, le management d’IBM a dû statuer entre deux impasses. En effet, abandonner « Future System » c’était perdre les investissements et compromettre l’avenir d’IBM. Cependant réaliser « Future System » mainframe aurait pu déstabiliser le marché existant qui n’était pas demandeur. Selon nous le management d’IBM a tranché pour une solution de transition, à savoir construire un système simplifié (bridé ?) pour PME, qui ne ferait surtout pas d’ombre aux mainframes, mais qui mettrait réellement en œuvre les concepts d’avant-garde « Future System ». Cette solution alternative avait l’énorme mérite de garder la technologie de rupture vivante, avec pour avantage une capacité de réactivité en cas de retournement du marché (allez savoir ce que peuvent manigancer en secret les concurrents dans les laboratoires?).

Selon nous, le système S/38, connu sous le nom d’AS/400 et aujourd’hui IBM i, est issu du projet « Future System » tout simplement parce qu’il en revendique tous les concepts de base. De plus, notons que le Future System fut officiellement arrêté en 1975, date à laquelle le laboratoire Rochester a embauché des milliers de personnes des quatre coins d’IBM afin de créer la machine S/38 sortie en 1979. Comme par un « heureux hasard », la fin de l’un correspond au début de l’autre. Selon Gérard Dréan qui a travaillé au projet Future System, le S/38 n’est rien d’autre, je cite : « qu’un Future System de niche ».

Nous savons que le marché mainframe est surtout un immense marché captif de renouvellement. Les mainframes (hardware, services et stockage) représentaient en 2012 : 25% du chiffre d’affaires mais 40% des bénéfices d’IBM. Pas mal pour des systèmes dont l’architecture a été conçue dans les années 60 ! (avec d’énormes investissements cependant.) Nous comprenons pourquoi IBM souhaite brosser ce marché dans le sens du poil tout en gardant l’IBM i sous le coude (mais avec le risque de faire passer le S/38 et ses descendants pour une sorte d’épée de Damoclès suspendue au-dessus de la division la plus profitable, d’où peut-être les histoires à dormir debout du bon Docteur Soltis ?).

Dans le contexte des années 70, il était normal qu’une compagnie de la stature d’IBM investisse massivement en recherche et développement avec Future System pour contrer toute menace. Le retrait de Future System pour mainframe parait lui aussi fondé étant donné la stabilité tout à fait surprenante du marché mainframe. La création qui fait suite en 1975 du S/38 pour PME à partir des concepts Future System était audacieuse et avait du sens. Ce ne sont pas les clients IBM i qui s’en plaindraient. Ce fut rétrospectivement une décision pertinente.

Voici un simple avis d’un expert indépendant à prendre comme tel: si le Cloud Computing est LA rupture technologique du siècle, IBM pourrait bien ressortir l’IBM i étant donné son architecture multi-tenant natif intégré (mutualisation native entre utilisateurs dynamiquement connectés des fichiers + programmes depuis le S/38).

Tous les logiciels SaaS à la pointe du Cloud: Google Aps et SalesForce sont multi-tenant fichiers+programmes mais moyennant une expertise difficile à maîtriser (gestion des méta data par tenant) donc *un surcoût important* au niveau du développement des applications. Sur IBM i, il suffit de compiler le programme, l’IBM i fait le reste à l’exécution lorsque l’utilisateur ouvre une session et appelle le programme. Chaque session est un travail qui prend en charge les méta data associées à l’utilisateur.

Concrètement si un utilisateur lit à l’instruction 1000 la commande 00150 pendant qu’un autre utilisateur lit à la même instruction 1000, du même programme partagé, la commande 00789, les données des commandes 00150 et 00789, sont mémorisées à l’exécution respectivement dans des méta data associées aux deux travaux (utilisateurs). Cette gestion est automatique sur IBM i à l’exécution, alors que les méta data par utilisateur *sont à la charge du programmeur* pour les autres OS lorsque les développeurs se trouvent dans l’obligation d’écrire des programmes online multi-tenant (mutualisés) pour le Cloud.

Etes-vous d’accord si je vous dis que nous ouvrons/fermons des sessions dynamiques online avec un browser depuis plus de 30 ans ? Oui, ami lecteur, toutes nos applications RPG héritées depuis le S/38 sont multi-tenant natif fichiers+programmes. Autant dire que nos applications RPG valent potentiellement de l’or (or brut cependant). En fait Future System était un système génial trop en avance pour son époque. Cependant l’époque avance et nous rattrape...

Pour paraphraser Antoine de Saint-Exupéry : « Pour ce qui est de l’avenir, il ne s’agit pas de le prévoir, mais de le rendre possible. »

 Jean Mikhaleff/RePeGlio

Vous êtes libres de cliquer sur notre site : www.repeglio.com
Vous aimez l'IBM i? Vous êtes bienvenu :
Un commentaire? Abonner quelqu'un? Une question?  jean@repeglio.com

Comment être plus efficace dans la planification d'un projet ?

Tout le monde le sait, avant de commencer un projet, il faut réaliser un certain nombre de tâches dont la planification du projet. La planification sert à ordonner dans le temps des opérations pour atteindre un objectif. Elle est également utile pour déterminer une estimation de la charge et du délai du projet.

ft planning projet


La planification est incontournable dans la phase de préparation d'un projet. Malheureusement, nous n’utilisons pas assez notre expérience collective pour la construire. Nous avons tendance à refaire des planifications pour chaque projet car nous pensons que les projets sont uniques. Certains diront qu'ils réutilisent leurs plans de projets pour en faire d'autres mais cela reste une démarche personnelle  et non collective.

Même si les projets sont uniques en soi, il existe des typologies de projets en fonction de leur objectif. Par exemple, les projets de développement de logiciel et les projets de déploiement ont des designs (conceptions) différentes. Par contre pour chacune de ces typologies de projets, nous pouvons définir une liste de choses à faire pour réaliser le projet et atteindre son objectif. Nous pouvons même faire encore mieux en planifiant ces différentes tâches à faire, puis en leur affectant des charges et les compétences nécessaires à leur réalisation.

Ainsi vous allez pouvoir construire des modèles de plan de projet en fonction des types de projets que vous réalisez et gagner beaucoup de temps dans les phases d'étude de vos projets. Bien évidement, une fois créés, ces modèles restent des canevas. Vous pouvez leur apporter des adaptions en fonction des spécificités du projet.

Avec le temps, vous allez même pouvoir les améliorer avec les retours d’expérience de vos projets et gagner en efficacité...

« Ne pas planifier, c'est programmer l'échec. » Winston Churchill

Management, formation et travail en équipe - Robert Stahl - Livre

Penser le temps à l'envers ? Redevenir acteur de nos projets plutôt que de les subir ? Progresser dans nos capacités à travailler en équipe pour passer de la juxtaposition de compétences - qui alimente les querelles d'égo - à de véritables dynamiques collectives pertinentes ?

Autant de sujets abordés dans le livre de Robert STAHL, Management, formation et travail en équipe - Pratiques issues du coaching et de l’intelligence collective, Préface d’Yves GONNORD, Postface d’Hervé SERIEYX, Collection « Le management en pratique », Éditions DE BOECK 2013.

Un livre très en résonance avec la réflexion de Peter Drucker citée dans ce blog : "Le meilleur moyen de prédire l'avenir, c'est de l'inventer."



Extrait :


Introduction : un livre pour l'action - pourquoi attendre demain ?

Un colibri, lors d'un feu de forêt, fait des allers-retours à la source d'eau pour éteindre l'incendie.
Tous les autres animaux de la forêt, atterrés, la regardent brûler et observent le colibri s'affairer.
Puis le tatou moqueur lui dit : «Tu perds ton temps, ce n'est pas avec ces quelques gouttes que tu vas arrêter le feu, colibri !».

Le petit oiseau lui répond : «Je le sais, mais je fais ma part».
Légende amérindienne

J'ai écrit ce livre pendant plusieurs mois sans vraiment savoir quelle forme il aurait en définitive. Je travaillais de manière circulaire, ou en spirale - comme je l'évoquerai plus loin - et c'est devenu... ce qu'il est aujourd'hui : un livre à destination des enseignants/formateurs... ET à destination des dirigeants/ managers. Il s'adresse à ces deux publics : une véritable gageure !

La question m'avait été posée en cours d'écriture par un ami : «À qui le destines-tu ?», et j'avais alors été bien en peine de lui répondre...

La question s'est posée ensuite lors de la sollicitation des éditeurs : pour quelle collection ? «Entreprise» ? «Management» ? «Efficacité professionnelle» ? «Pédagogie» ? «Formation» ? «Sciences de l'éducation» ? «Développement personnel» ?... Chaque catégorie semblait exclure de fait les lecteurs des autres catégories !

La réponse est venue d'une enseignante de français à qui je faisais lire une première version de ce livre. «Je suis tout à fait intéressée à le lire : figure-toi que mon mari a été promu manager après une formation trop légère et, quand il me parle de situations qui lui posent problème, il s'étonne que l'enseignante que je suis puisse avoir des réponses pertinentes à lui proposer !»

Je ne cherche pas ici à convaincre qu'il s'agisse du même métier : les deux domaines sont bien distincts. Mais, à y regarder de plus près, les liens sont multiples :

- L'enseignant a bien une mission d'animation et de «management» d'apprenants dans leurs parcours, et des groupes qui lui sont confiés.
- Le manager est a priori là - est-ce vraiment a priori ? - pour faire grandir ses collaborateurs et faire progresser ses équipes, pour leur permettre de mettre le meilleur d'eux-mêmes et de leurs talents au service de l'entreprise et de ses «clients».

Au fil de l'écriture de ce livre, je constatais que des réflexions faites dans l'un de ces deux domaines étaient systématiquement applicables dans l'autre, et réciproquement : des outils, processus et postures particulièrement pertinents dans la pratique de ces deux métiers, qui changent vraiment la manière... de les pratiquer.

II y a surtout un point où le manager et l'enseignant se rejoignent. L'un comme l'autre sont confrontés à la dimension du collectif :
- Comment rendre actif un collectif d'apprenants pour qu'ils deviennent experts du domaine qu'il revient à l'enseignant... d'enseigner ?
- Comment rendre actif un collectif de collaborateurs pour qu'ils soient plus que des intelligences juxtaposées ?
(...)

Le site de Robert Stahl  "rs3c"

"Enthusiam without knowledge is like running in the dark." Inconnu

Utilisation de la méthode ASIT pour innover ou pour résoudre un problème



"Le meilleur moyen de prédire l'avenir, c'est de l'inventer." Peter Drucker

Retour vers le futur grâce au retour d'expérience...

Depuis vingt que je travaille de près ou de loin sur des projets, je n'ai jamais vu de ReX. Rassurez-vous, il ne s'agit pas d'une race canine disparue. Je fais référence ici aux retours d'expériences réalisés en fin de projets. Ces ReX doivent permettre de mettre l'accent sur les bonnes et les mauvaises (activités/pratiques ?) qui ont été mises en oeuvre durant le projet. Cette analyse menée au terme du projet permet d'apprendre de ses expériences et donc de faire mieux pour les projets futurs.

Malheureusement toutes les excuses sont bonnes (mauvaises !) pour éviter cette tache finale : pas le temps, un autre projet doit débuter, nos remarques ne seront pas lues ou encore, méconnaissance de ce qu'est un retour d'expérience, etc.

Toutes ces excuses ne tiennent pas pour plusieurs raisons :
- pas le temps : ce n'est perdre du temps que de tenter d'améliorer notre connaissance sur la façon dont nous gérons des projets. De plus, il ne s'agit pas d'une tache complexe mais de faire ressortir les points forts et les points faibles du déroulement du projet. Et pour les faiblesses, il faudra trouver de nouvelles façons de faire ou des orientations différentes mais en général, nous y avons déjà réfléchi.
- inutile car pas exploité : si vous investissez un minimum de temps et en rendant vos ReX lisibles, tous les chefs de projets y trouveront un intérêt : cela leur évitera de tomber dans les mêmes pièges que ceux décrits...
- méconnaissance de la pratique "ReX" : il suffit de sensibiliser les chefs de projet aux avantages qu'ils pourront en tirer.

On peut avancer que si les retours d'expérience ne servaient à rien, l'armée arrêterait sans doute de faire des débriefing après une opération. Les débriefing miliaires sont tout simplement des retours d'expérience d'actions.

Retour d'expérience


Pour faire simple, vous pouvez organiser vos retours d’expérience en réalisant une réunion de 1 à 2 heures, en vous focalisant sur les points suivants :
- Les choses à Faire,
- Les choses à Garder,
- Les choses à Arrêter.

Avec cette manière de faire, nous n'avons plus d'excuses : le "ReX" est simple, rapide et efficace.

"Je suis toujours prêt à apprendre bien que je n'apprécie pas toujours qu'on me donne des leçons." Winston Churchill

Comment redresser un projet ?

Au vu du nombre de projets mis en échec (projets en échecs ou abandonnés 62% - Cabinet Standish Group 2009), vous avez sûrement eu à gérer des projets qui partaient à la dérive. Certains diront qu'ils ont toujours respecté les délais et les budgets de leurs projets. Peut être, mais ils les ont certainement respectés après avoir revu les prévisions initiales, à plusieurs reprises. Tous les chefs de projets sont confrontés un jour ou l'autre à ce type circonstance.

Alors comment faire pour gérer cette situation ?

Si votre projet part à la dérive, il est temps de réagir ! Si vous ne faites rien, il est fort probable que vous soyez le premier à en subir les conséquences. En effet votre direction sera obligée de réagir à un moment donné pour sauver les apparences et vous risquez de payer l'addition. Comme pour les équipes de sport dont les résultats sont mauvais, les dirigeants risquent de vouloir changer l’entraîneur. Mais, contrairement à ce que l'on croit, ce type de décision ne permet pas de gagner du temps : cela en fait surtout perdre car la ou les causes du dérapage du projet ne seront pas résolues pour autant. Le projet poursuivra sa dérive tranquillement .

Plus vous attendez pour réagir, plus il sera difficile d'en parler et de trouver les réelles causes de vos difficultés.

Si vous réagissez à temps, il n'y a pas d’inquiétude à avoir. En général, les choses ne se passent pas comme prévu. Même avec un bon plan de projet, vous aurez toujours des imprévus qui viendront ruiner vos efforts. En prenant les choses en main, vous allez montrer votre professionnalisme et vous allez certainement arrêter la chute ou en réduire les effets.

Une des premières choses à faire est de connaître vos marges de manœuvre. Pour cela, il vous faudra allez voir le « sponsor » du projet pour lui expliquer la situation et lui demander quels sont les niveaux de latitude en terme de budget, délais et de périmètre fonctionnel (exigences).

Il ne s'agit pas seulement de demander une "rallonge" pour terminer le projet car si vous ne changez rien, votre marge sera vite consommée.

Il faudra établir un diagnostique le plus juste possible et sans concession de la situation. Pour cela, vous pouvez vous appuyer sur l'aide d'une personne externe, qui établira un bilan. Après cet audit, il s'agit d'établir un plan de redressement en prenant en considération les marges de manœuvre négociées avec le « sponsor ». Il faudra également distinguer les causes structurelles (problème d'organisation) des causes conjoncturelles (liées aux circonstances). Cette distinction vous aidera à définir un plan d'actions efficace. Il faudra également penser à remobiliser vos troupes.

En enfin, il vous faudra rétablir la situation en surveillant rigoureusement les résultats positifs et négatifs de votre plan de redressement et en communiquer les bénéfices au « sponsor ».

Voilà, pas de solution magique mais plutôt de bon sens. Attention toutefois, il peut arriver qu'un projet ne puisse pas être redressé car ses fondements ou ses hypothèses n'étaient pas correctes dès le démarrage. Dans ce cas, il est peut être préférable d’arrêter pour repartir différemment.


« L'arbre qui naît tordu ne redresse jamais son tronc. » Zoé Valdés 

La réunion visuelle - réalisé sur IPAD

Faire de vos reunions une expérience différente


Réalisée par Roberta Faulhaber (Facilitation Visuelle)

"Un manager qui n'est pas cru est cuit !" Philippe Vivien

Arrêtez de donner des gifles !

Dans toutes organisations, les objectifs sont d'apporter aux clients ou aux usagers un service (ou produit) de qualité à un prix attractif dont le délai de livraison est le plus court. Les services informatiques n'échappent pas à ces objectifs mais ils ont de grosses difficultés à les atteindre.

Les projets dérapent … les coûts et les délais sont rarement respectés. Le nombre d'incidents augmente ou en tout cas ne diminue pas. Tout cela se traduit par une mauvaise image de l'informatique : trop cher, pas assez rapide, ne marche jamais correctement …

Il n'est pas facile d'atteindre les objectifs précédemment cités car ils ne vont tous dans le même sens. En effet, il est plus facile d'améliorer la qualité si vous n'avez pas de contrainte de coût. Pour autant même sans cette contrainte de coût, il n'est pas garanti que la qualité augmente. De même, la qualité a différentes formes en fonction de la perception de chacun. Comment savoir si vous répondez correctement aux attentes de vos utilisateurs ou des métiers ?

Un des moyens de répondre à cette question est d'être attentif aux incidents et aux réclamations de vos utilisateurs. Vous y trouverez une mine d'informations pour améliorer votre qualité et le niveau de satisfaction de vos utilisateurs. La plupart des services informatiques gèrent les incidents et tentent de trouver rapidement des solutions pour dépanner leurs utilisateurs. Par contre, les services informatiques s’arrêtent le plus souvent à la correction des symptômes sans aller au fond des choses : la cause.

Ce mode de fonctionnement ne permet pas de diminuer le nombre d'incidents et l’énergie nécessaire à leur traitement. Des ressources sont occupées à traiter des anomalies au lieu d'apporter de nouveaux services aux utilisateurs.

Pour gérer efficacement les problèmes, vous pouvez utiliser les outils des 5 pourquoi et le PDCA de Deming (Plan Do Check Act). Les « 5 pourquoi » vous permettrons d'identifier la cause du problème et le PDCA vous permettra de mettre en œuvre vos solutions pour traiter le problème à la racine.

La Gifle est un film de Claude Pinoteau (1974)

« Imaginez chaque incident comme une gifle que vous allez donner à un client en lui recommandant d'acheter ailleurs et de le faire savoir à tous les gens qu'il croise. » Le management Lean – Michael Ballé et Godefroy Beauvallet

7 erreurs à éviter pour un entretien d'embauche (Informaticien)


Vous souhaitez des conseils pour votre entretien d'embauche alors cette video est faite pour vous ...
Yves Gautier, Coach en entretien d'embauche, vous présente dans cette video les 7 erreurs à eviter et vous donne ses conseils pour être plus efficace



Vous pouvez retrouver Yves Gautier sur son site : Entretien d'embauche TV

"L'art de la réussite consiste à savoir s'entourer des meilleurs." John Fitzgerald Kennedy

Quel est votre niveau de maturité dans la gestion de vos fournisseurs ?

Pour mesurer votre niveau de maturité, il existe un référentiel « eSCM » (eSourcing Capability Model) développé par l'université de Carnegie Mellon (Pennsylvanie). Cette université est également auteure du référentiel CMMI (Capability Maturation Model Integration).

Ce référentiel a été développé pour améliorer les relations entre les clients et les fournisseurs dans un contexte informatique. Il est composé de deux volets : la partie "client" (eSCM-CL : Client Organizations) et la partie "fournisseur" (eSCM-SP : Service Provider). Ces deux volets sont complémentaires et cohérents.

En plus de définir les bonnes pratiques dans la gestion la relation Client-Fournisseur, il permet d'évaluer l'aptitude d'une orgnisation dans la gestion de cette relation selon 5 niveaux.

Niveau 5 : Maintenir l'excellence,
Niveau 4 : Accroitre proactivement la valeur,
Niveau 3 : Gérer la performance de sourcing,
Niveau 2 : Gérer le sourcing de façon cohérente,
Niveau 1 : Gérer empiriquement le sourcing.

Si vous n'avez engagé aucune réflexion sur la bonne gestion de la relation Client-Fournisseur, vous êtes au minimum c'est-à-dire au niveau 1.

eSCM-CL extrait


Pour vous aider à vous auto-évaluer, j'ai réalisé un tableau Excel reprenant 17 domaines (neuf domaines de pratiques permanentes et huit domaines liés au cycle de vie d'un projet de sourcing) et les 95 pratiques associées sur le volet CL. (Je n'ai pas abordé l'autre volet concernant les fournisseurs).

eSCM exemple de Graphe SI

Si vous souhaitez obtenir ce fichier de diagnostique pour vous auto-évaluer, vous pouvez me contacter en utilisant le lien en-dessous de mon profil « Me contacter » en précisant l'objet de votre demande. Ce fichier ne remplace en rien un audit réalisé par un expert du référentiel mais il peut vous donner une idée de votre niveau d'aptitude à maitriser les relations à vos fournisseurs.

Exemple de resultalt eSCM SI

Ps : ce fichier vous sera délivré contre une modeste obole dont le montant est laissé à votre appréciation. 

5 minutes pour comprendre comment respecter les délais avec la "Chaine Critique" - TOC


Vidéo de présentation de la Chaine Critique par Philip Marris (MarrisConsulting)

La durée des projets en moyen baissée de 39%



"Les prévisions sont difficiles, surtout lorsqu'elles concernent l'avenir." Pierre Dac

Trouvez la raison et vous aurez la solution !

Il y a quelques temps lors d’un comité de direction, nous discutions d’une fonction de l’entreprise qui ne répondait plus à nos objectifs. L’idée de base était de dire qu’il fallait changer de logiciel pour gagner en efficacité. 

Après réflexion, je pense que nous avons brûlé des étapes dans notre prise de décision. Nous sommes passés d’un problème constaté à une décision de changer d’outil sans se poser les bonnes questions.

Le fait de changer d’outil peut ne pas répondre à notre problème. 

Quelle est la cause de ce manque d’efficacité ? (organisation, procédure, formation, informatique,…) Si l’outil n’est pas la cause de ce problème alors le fait de le changer ne répondra pas à nos attentes avec le risque de dégrader encore plus la situation actuelle.

Un logiciel reste un outil pour nous accompagner et nous aider à réaliser une tâche. Nous confondons souvent les moyens avec les solutions. Les moyens peuvent répondre en partie à des problèmes mais sur la base d’une solution adéquate. Il faut d’abord trouver une solution au problème et après trouver les moyens à mettre en œuvre.

Etapes de résolution : 
- Définir le problème (qui, quoi, où, quand, comment, combien et pourquoi : QQOQCCQ) 
- Préciser les enjeux, 
- Identifier les contraintes.


SI Resolution de problèmes


Outil d’aide à la résolution : Le Diagramme d’Ishikawa (ou arrêtes de poisson) recense les causes aboutissant à un effet. Son analyse permet une aide à la décision pour corriger un dysfonctionnement.

« Un problème sans solution est un problème mal posé » Albert Einstein

Parallèle entre gestion de projet et le référentiel ITIL


Faire un parallèle entre ces deux systèmes n’est certainement pas académique mais il répond à certaines interrogations et incompréhensions. Le référentiel ITIL est souvent perçu par les équipes des études ou du développement comme "générateur" de bonnes pratiques pour les équipes de production.

Dans ce schéma, vous verrez que la gestion de projet intervient dans les processus du référentiel ITIL pour la réalisation de nouveaux services et pour apporter de la valeur aux métiers. ITIL est un référentiel des meilleures pratiques pour le domaine de l’informatique et il préconise bien évidement d’utiliser une "méthode projet" pour réaliser de nouveaux services. La gestion de projet quant à elle, peut être utilisée dans l’informatique mais aussi dans bien d’autres domaines pour réaliser un produit ou un service.

SI ITIL et Gestion de projets



“Une petite impatience ruine un grand projet.” Confucius

Autour du S.I. - Recueil


Autour du SI” est mon deuxième recueil, réalisé à partir des articles écrits pour mon blog. Il reprend les articles sur mes réflexions et expériences de manager et des outils pour développer son efficacité.

L’informatique est un domaine particulier où les informaticiens doivent bâtir le système d’information de demain tout tant en maintenant le système existant, de manière opérationnelle. Au cours de nos études, nous avons appris à analyser, à programmer et à résoudre des problèmes mais on ne nous a pas appris à concilier des demandes à priori contradictoires comme gérer le quotidien et prévoir le futur.

Aujourd’hui, les entreprises demandent beaucoup aux informaticiens pour différentes raisons : les technologies évoluent de plus en plus vite, les marchés changent rapidement et constamment, les utilisateurs en veulent plus avec des moyens plus faibles, etc.

Dans ce contexte, il est important de développer son efficacité dans différents domaines comme le management et la finance pour relever ces challenges.

Dans ce recueil, vous trouverez 51 articles empreints de bon sens et de conseils pour améliorer au quotidien votre activité de manager dans le domaine IT. Il est composé de 5 parties : Réflexion générale, Management, Budget, Projet, Support et Efficacité.

En le lisant, vous trouverez certainement des réponses à diverses questions comme : "comment respecter son budget" ou en encore "comment tenir les délais sur un projet". Il peut se lire de différentes manières soit du début à la fin, soit en piochant les sujets en fonction de vos préoccupations.

Ces articles ont été écrit sur une période de 5 ans pendant laquelle j’ai pu tester efficacement mes méthodes. Je ne sais pas si vous aurez la même réussite que moi en appliquant ces conseils mais le seul moyen de le savoir est de les appliquer. Je ne vous demande pas de me croire mais d'en faire l'expérience. Alors, à vous d'essayer ...

Projet : les 7 conseils à suivre ...

Il y a 8 ans avec ma femme, nous avons décidé de nous lancer dans un joli projet de construction de maison. Vous trouverez dans cette histoire toutes les erreurs à ne pas commettre dans la réalisation d’un projet .

Ecouter le besoin du client
Pendant la phase d’étude, nous expliquions au constructeur comment nous envisagions notre maison. Le constructeur concrétisait nos idées sur plan pour ensuite réaliser un devis. Cette phase a duré environ deux mois. Nous avons reçu une dizaine de plan qui n’étaient pas conformes à nos souhaits. Au final, nous avons réalisé une partie des plans et nous avons demandé directement un Rdv avec le dessinateur du constructeur.

Rédiger le contrat sans erreur
Une fois d’accord sur les plans et le contenu du contrat, le constructeur a rédigé le permis de construire en notre nom. Après lecture, nous nous sommes aperçu qu' un grand nombre d' erreurs grossières jalonnaient le document ; la plus drôle (et la plus légère aussi) était que l’ adresse de la maison n’était pas la bonne ...

Vérifier et valider les détails techniques
Pour notre maison, nous souhaitions un chauffage au gaz de ville. Le commercial nous avait assuré que le réseau de gaz passait juste devant notre future maison et que cela ne posait aucun problème, ce que nous ne pouvions vérifier, ne disposant d' aucun document de propriété. Il nous a même signé un papier pour obtenir un prêt spécifique auprès de GDF. En cours de la construction, Gaz de France nous signalait que le réseau de gaz s' arrêtait 100 mètres avant notre terrain, pas 2 ou 3 comme le commercial l' affirmait . La différence financière n’est pas négligeable...

La main d' oeuvre la moins chère n' est pas la moins coûteuse
Notre constructeur, pour augmenter sa marge, "tirait les prix vers le bas" et il faisait travailler certains artisans qui n' avait pas pour préoccupation de rendre un travail de qualité . Trois artisans des artisans qui ont travaillé à la construction de notre maison ont finalement "déposé leur bilan". Le constructeur a été obligé de trouver d’autres artisans dans l’urgence. Dans ce cas, les tarifs sont souvent peu négociables .

Conserver tant que possible la même équipe projet
Pendant la construction, nous avons eu six conducteurs de travaux. Suivi de chantier ??

Rectifier les erreurs quand elles apparaissent
Un des nombreux conducteurs de travaux avait l’habitude de nous dire quand nous lui faisions une remarque : « Quand vous achetez une voiture, vous n’allez pas sur la chaîne de montage pour savoir comment elle est réalisée. »

Toujours écouter son client
Il faut toujours écouter son client même s’il a tort et essayer de le comprendre. Il faut garder une communication et éventuellement lui expliquer ses erreurs. Cela permet de ne pas recevoir de courrier en recommandé.



Pour finir, le construction s’est terminée avec quatre mois de retard (nous avons fixé nous-même la date de livraison). Le constructeur nous a payé des pénalités pour ce retard . Si vous voulez réussir vos projets, vous pouvez suivre ces conseils :
  • Ecouter le besoin du client,
  • Rédiger le contrat sans erreur,
  • Vérifier et valider les détails techniques,
  • Le moins cher n’est pas le moins coûteux,
  • Conserver tant que possible la même équipe projet,
  • Rectifier les erreurs quand elles apparaissent,
  • Toujours écouter son client.
"La science des projets consiste à prévenir les difficultés de l'execution." Vauvenargues

Comment vendre un service ? - Recueil


Vous souhaitez doper votre activité commerciale ou encore améliorer votre recherche d’emploi alors n’hésitez plus, achetez mon recueil “Comment vendre un service ?”.

Pour seulement un 1€, vous trouverez 19 pistes pour améliorer votre performance. Ces conseils sont simples et efficaces, et ils vous permettront un retour sur investissement important.

PS : Classé 19ème des ventes (Kindle) sur Amazon dans la section Commerce

"Si je lis un livre à 20$ et qu’il me donne une bonne idée, je fais une des meilleures affaires de tous les temps." Tom Peters





Catégorisez vos projets ! - PMO



Il existe différentes manières de catégoriser vos projets en fonction des objectifs et du moment. Si votre objectif actuel est d'optimiser votre porte-feuille de projets, je vous propose de le catégoriser selon deux axes :
  • Le niveau de volatilité des besoins,
  • Le risque et l'impact du projet sur votre entreprise.
En fonction du projet, les besoins peuvent être plus ou moins changeant dans le temps. Par exemple, un projet sponsorisé par le service Marketing aura un périmètre fonctionnel très volatile car il devra s'adapter rapidement aux marchés (la concurrence et aux clients). Au contraire, un projet lié à votre activité de base sera plus stable.
De même, le niveau de risques et d'impact pour votre entreprise pourra être différent selon le projet. Un projet de changement de système métier sera très risqué. A l'inverse, le développement d'un outil de gestion des notes de frais sera moins risqué et impactant.
Ces deux critères vous permettront de classifier vos projets pour optimiser au mieux vos ressources, qui sont souvent limitées. Avec cette catégorisation, vous allez pouvoir adapter l'organisation des projets en assouplissant ou pas votre méthode de projet et vous allez pouvoir adapter le cycle de développement des projets en fonction de l'agilité souhaitée.

PMO projets


Les différents cas de figure :
1 = Une gouvernance forte avec un pilotage serré en utilisant une méthode agile (mettre les moyens),
2 = Une gouvernance forte avec un pilotage serré en utilisant une méthode classique de développement,
3 = Une gouvernance plus légère en faisant confiance à des chefs de projet junior en utilisant une méthode agile,
4 = Une gouvernance plus légère en faisant confiance à des chefs de projet junior en utilisant une méthode classique.

"Le succès n'est pas le clé du bonheur. Le bonheur est la clé du succès. Si vous aimez ce que vous faites, vous réussirez." Albert Schweitzer

Faites une pause !


Des études réalisées par le professeur Gloria Mark ont montré que les salariés changent de tâches en moyenne toutes les 3 minutes. Entre les mails, le téléphone, les SMS, les dossiers à traiter, le collègue qui vous raconte la dernière réunion, votre patron qui vous pose une question et bien d'autres choses, vous passez votre temps à zapper d'une tâche à une autre. Il est vrai que notre cerveau est capable de gérer plusieurs choses en même temps mais à des niveaux de concentration différents. Nous pouvons marcher et téléphoner en même temps. Par contre, notre attention n'est focalisée que sur une seule chose.

Même si ce mode de fonctionnement qui consiste à "zapper" continuellement peut paraître productif, il n'est pas efficace car il génère trop de périodes de latence non productives (exemple : reprendre le fil de ses idées sur un dossier après un coup de téléphone).

D'un autre côté, notre efficacité augmente quand nous nous accordons des pauses régulières en nous évadant de notre travail. Une étude menée sur 300 salariés à l'université de Melbourne montre que la productivité des employés qui utilisent Internet au bureau pour des raisons personnelles augmentent de 9%.

La raison en est simple : notre attention est limitée dans le temps. Nous avons besoin de faire des pauses pour recharger notre attention.


Productivité informatique


En résumé, le multitâche est un mythe. Pour être efficace, nous devons travailler sur une seule chose à la fois mais nous devons également nous accorder des pauses régulières pour augmenter notre concentration. 

"Le temps n'est pas une courbe lisse mais une série de cahots, de bonds et de pauses." Niall Williams

Les 7 indicateurs magiques !


Toute organisation a besoin de savoir si elle travaille dans le bon sens. Pour une DSI, je vous propose 7 indicateurs pour mesurer votre efficacité. Bien sur, il en existe bien d'autres et je vous invite à nous les faire partager en laissant un message.

J'ai choisi 7 indicateurs car selon les études de Mr Miller (1), le nombre 7 correspond approximativement au nombre maximal d'éléments qu'un esprit humain est capable de traiter et de percevoir simultanément. De ce fait, ils correspondent parfaitement aux besoins d'indicateurs sur un tableau de bord pour mesurer votre activité.

1 - Votre part d'innovation : le taux du budget IT consacré aux projets novateurs
2 - La patience de vos utilisateurs : le temps moyen d'attente entre un incident (demande) et sa résolution
3 - Votre ponctualité : le nombre de projets respectant les délais
4 - Votre disponibilité : le temps moyen d'indisponibilité des services
5 - La taxe de votre encadrement : la masse salariale de l'encadrement
6 - Votre alignement : le nombre de projets en cours qui sont liés aux priorités de votre entreprise
7 - La sainte trinité : les indicateurs de délais, de qualité et de budget de votre plus gros projet en cours

Indicateurs Système d'information



"Baromètre : instrument ingénieux qui indique quelle sorte de temps nous sommes en train de subir." Ambrose Bierce

(1) Mr George Miller – The Magical Number Seven, plus or minus two

Dailymotion - dessin


"Ce n'est pas parce que les choses sont difficiles que nous n'osons pas, mais parce que nous n'osons pas qu'elles sont difficiles." Sénèque

Quelles sont vos références ? Un complément à votre CV...



Comme les entreprises, vous pouvez vous aussi réaliser une fiche de synthèse qui présente les logos des sociétés avec lesquelles vous avez travaillé :

SI Références

"Il n'y a qu'une façon d'échouer, c'est d'abandonner avant d'avoir réussi." Olivier Lockert

Sortir du cadre - dessin

Autour du SI Créativité

"On aura beau nous expliquer quel est le goût du fruit du baobab, rien ne remplacera sa saveur. Le pont entre le savoir et le non-savoir est fait de notre expérience et de notre compréhension." Le petit prince au bureau - Borja Vilaseca

Productivité n'est pas synonyme d'efficacité en informatique.


La productivité est liée à la production d'un bien. En général, elle correspond au nombre de produits réalisés par unité de temps. Ce ratio est très intéressant pour mesurer une activité repérable avec très peu d'incertitude, comme par exemple la fabrication de produits.

En revanche, l'activité informatique n'est pas une activité de production pure. Si nous considérons, par exemple, le domaine des études et des projets, l'activité de conception possède un niveau d'incertitude élevé. Pour le support et la maintenance, l'activité cette fois correspond à de la résolution de problèmes. La résolution d'incident peut être répétitive (exemple : débloquer un compte) mais en général, les problèmes restent  uniques dans leur résolution avec une période d’analyse plus ou moins longue en fonction du dysfonctionnement.

Malheureusement, nous mesurons encore trop souvent les activités informatiques par des ratios de productivité. Même si, au sein des activités informatiques, il y a des tâches répétitives, elles ne sont pas les plus nombreuses. Et quand elles sont récurrentes, nous cherchons à les automatiser comme les tests de “non régression”.

L'utilisation de ce ratio nous pousse à maximiser l'utilisation des ressources. Or, ce modèle de performance est une illusion de performance pour le développement de produits. Selon Stefan Thomke (professeur à Harvard) et Donald Reinertsen (président d'une société de consulting), la qualité et l'efficacité des résultats décroissent inévitablement lorsque les responsables saturent l'emploi du temps de leurs collaborateurs. A l’origine de ce manque d’efficacité, se trouvent la variabilité et l'incertitude liées aux projets, qui engendrent des retards. Donc pour limiter ces retards, il faut des capacités "tampon" : nos systèmes de contrôle nous poussent à faire le contraire en utilisant au maximum la capacité de nos ressources.

Efficacité Informatique
tiré de HBR de mai-avril 2013

Voici quelques pistes pour améliorer votre efficacité sur les projets :
- accroitre les ressources de manière sélective au niveau des compétences saturées,
- limiter le nombre de projets en fonction de vos capacités,
- mesurer l'efficacité de vos équipes "projet" en fonction des objectifs de cout, de délai et de qualité,
- adapter vos méthodes projets en fonction des risques et de l'impact du projet,
- utiliser le management visuel pour rendre visible les points de saturation,
- essayer d'autres méthodes comme la "chaîne critique".

"Je trouve fascinant que la plupart des gens planifient mieux leurs vacances que leur vie. Peut être parce qu'il est plus facile de s'évader que de changer." John Rohn

Communication informelle - dessin


"Soyez vous-même, les autres sont déjà pris." Oscar Wilde

Le mail dans le mail


Une étude réalisée par Mattitiyahu Zimbler et Robert Feldman (université du Massachusetts Amherst) a montré que les gens mentent cinq fois plus souvent en écrivant des mails qu’en discutant (les yeux dans les yeux). Il faut également noter que d’autres études avaient montré que la plupart des gens mentent au moins une fois lors d’une conversation de dix minutes.




Cette information est tirée de la revue Harvard Business Review dans son édition français parue ce jeudi en collaboration avec Prisma Media.

Stage pour gérer les personnalités difficiles - dessin


"Ne soyez pas irremplaçable. Vous ne pourrez être promu si vous ne pouvez être remplacer." Anonyme

Pour faire plus avec moins - dessin


"Mon emploi est très sécurisé : personne d'autre n'en veut." Richard Templar

"Apportez-moi des solutions, pas des problèmes."  Margareth Thatcher

La crise et les cadres - dessin


"On a déjà pensé à tout. Le problème, c'est d'y penser à nouveau." Goethe

La pensée aux prises avec l'informatique - Livre Gratuit

Laurent Bloch nous propose un de ses livres en libre téléchargement : Systèmes d'information, obstacles et succès

Merci à lui car ce geste est relativement rare.

Ps : paru en 2005 aux Editions Vuibert

"Penser contre son temps, c'est de l’héroïsme. Mais le dire, c'est de la folie." Eugène Ionesco

Pression Budgétaire - Dessin


"Seuls les bébés mouillés aiment le changement." Daniel Kahneman 


Une méthode pour Le transfert de compétences


Dans le livre « la pratique du lean mangement dans l’IT », j’ai appris l’existence d’un outil simple et extrêmement efficace pour former les équipes et les rendre autonomes. Cet outil présente les principes pragmatiques d’un bon transfert de compétence en appliquant la répétition et la pratique. Il s’appelle TWI (Transfert Within Indusdry). Ses principes sont appliqués de longue date chez Toyota mais ils ont été inventés au Etat-Unies pendant la seconde guerre mondiale. En plus de vous apporter une méthodologie pour former vos collaborateurs, TWI pourra vous emmener plus loin si vous souhaitez l’appliquer complètement.

Cette méthode comporte trois volets :
- Instructions de travail
- Méthode de travail (trouver des améliorations)
- Relation au travail

Les principes sur la formation se trouvent dans le volet sur les instructions de travail dont je vous livre les grandes lignes :
- Vous montrez et expliquez ce qu’il faut faire,
- Recommencez en expliquant comment contrôler la qualité,
- Recommencez en expliquant pourquoi cela est important,

Puis, vous faites faire les tâches et, suivant les trois premières étapes, vous corrigez les dérives et les erreurs éventuelles. Et enfin, vous laissez faire de manière autonome en surveillant.

SI L'OPÉRATEUR N'A PAS APPRIS, LE FORMATEUR N'A PAS ENSEIGNÉ

Pour en savoir plus, vous pouvez lire ce livre (uniquement en anglais) :  



"L'homme honorable commence par appliquer ce qu'il veut enseigner ; ensuite il enseigne." Confucius