"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.
"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
"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
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
Libellés :
Conférence,
Entreprise,
Personnel
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 nhé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.
"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 nhé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.
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
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
Libellés :
Méthode,
Organisation,
Personnel
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."
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 ?
(...)
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 ?
(...)
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.
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
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.
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
Libellés :
Méthode,
Organisation,
Personnel
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
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
Libellés :
Méthode,
Organisation,
Personnel
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
Réalisée par Roberta Faulhaber (Facilitation Visuelle)
"Un manager qui n'est pas cru est cuit !" Philippe Vivien
Libellés :
Entreprise,
Méthode,
Organisation,
Personnel
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.
« 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
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
Libellés :
Méthode,
Organisation,
Personnel
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.
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).
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.
Ps : ce fichier vous
sera délivré contre une modeste obole dont le montant est laissé à votre
appréciation.
Libellés :
Méthode,
Organisation,
Personnel
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.
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
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.
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.
“Une petite impatience ruine un grand projet.” Confucius
Libellés :
Méthode,
Organisation,
Personnel
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
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.
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
"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
Libellés :
Méthode,
Organisation,
Personnel
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.
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
"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
Libellés :
Méthode,
Organisation,
Personnel
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
Sortir du cadre - dessin
"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.
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
- 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
Libellés :
Coûts,
Livres,
Méthode,
Organisation,
Personnel
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.
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 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
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
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
Libellés :
Entreprise,
Livres,
Méthode,
Organisation
Inscription à :
Articles (Atom)




















