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