11 novembre 2016

Analyse de relations de travail à la lumière de l'incertitude des acteurs

Un projet met régulièrement les acteurs dans une situation nouvelle ; alors, s'il est vrai que chacun ré-évalue ses incertitudes et ses ressources, alors on peut s'attendre à ce que le comportement de chacun évolue au cours du projet.

Je fais l'hypothèse que les circonstances, les paramètres de la situation, expliquent mieux les mésententes dans une équipe projet que les psychologies en présence. Voilà ce que ça donne, dans l'analyse d'une situation conflictuelle de trois personnes : Xave, chef d'équipe, et Babeth et Olivier, ses collaborateurs.

En théorie, Xave, responsable d'équipe, devrait tancer Babeth du fait de sa faible productivité et louer Olivier du fait de la qualité de sa production. Or, c'est le contraire qu'on observe depuis quelques temps. Xave est piquante avec Olivier ; en même temps, elle se révèle patiente à l'égard de Babeth. Est-ce une question de personnes ?

Xave, 42 ans, se dit compétitrice dans l'âme, Olivier est un professionnel aguerri de 53 ans et Babeth, 57 ans, montre chaque jour combien elle est novice dans ce qui touche au projet et à la production. 

Et s'il s'agissait, pour Xave, d'une réaction à une situation de compétition ? Xave verrait en Olivier un compétiteur potentiel, et sur ce point Babeth la rassure tout-à-fait, aucune compétition entre elles deux.

J'aurais envie de demander à Xave quelle est son incertitude à elle. En tous cas, ni la qualité ni la rapidité de la production n'en font partie, sinon Babeth épuiserait la patience de Xave, ce qui ne se produit pas.

Peut-être Xave estime qu'à l'étape présente du projet, Olivier est plus nécessaire qu'elle au succès de l'équipe, parce que les livrables d'Olivier sont plus visibles ou plus attendus et les siens sont derrière elle. Si le chef de projet s'en aperçoit, Xave est sur la sellette. Aussi est-elle plus tendue vis-à-vis d'Olivier.

Pour autant, le raisonnement n'est pas déterministe, en ce sens que ce sont les acteurs qui, confrontés à l'évolution de leur situation, la ré-évaluent pour eux-mêmes. La conclusion qu'on pourrait tirer (je suis prudent) est : à changement de situation, changement probable de comportement. Autrement dit, les acteurs, loin d'être figés, sont en permanence susceptibles de s'ajuster.

Intéressant, non ?


01 novembre 2016

Comment faire pour qu’une nouvelle application informatique soit bien acceptée par les utilisateurs ? Un elevator pitch

1. Le problème, votre problème, comme une histoire (savez-vous que...)

J'ai assisté à une conversation entre un manageur et son collaborateur :

Manager - Peux-tu STP me donner la nomenclature de l'assemblage que tu viens de terminer ?

Collaborateur - Oui, bien sûr, tout de suite en format tableur.

Manageur - Euh, non, dans la base de données, plutôt !

Collaborateur - OK, dans ce cas je te la donne demain soir. Tu sais, la base de données, c'est long.

Manageur - Ah ! J'en ai besoin tout de suite, alors je préfère que tu me la donnes tout de suite en format tableur.

Savez-vous que 50 à 75% des applications informatiques ne sont pas utilisées par leurs utilisateurs ? Ceux-ci s’habituent au projet informatique comme à un mal nécessaire. L’organisation s’adapte à son environnement à pas lents, coûteux et à contrecœur.

2. Comment le problème est résolu à ce jour.

  • Souvent, le commanditaire s’adresse aux gens concernés au cours du lancement du projet ;
  • des super-utilisateurs sont invités à collaborer à la conception de la solution informatique ainsi qu’aux tests ;
  • l’équipe projet de développement informatique forme les utilisateurs ;
  • le help-desk répond aux questions des utilisateurs.

Tout cela est nécessaire mais insuffisant, si on juge par les résultats.

3. Ce que vous proposez comme solution.

Il a été montré que pour faire adhérer des collaborateurs à de nouveaux outils, il faut que ceux-ci...

  • comprennent le besoin de changer,
  • comprennent ce qui change pour eux personnellement,
  • acquièrent la compétence sur les nouveaux outils,
  • résolvent les problèmes au quotidien et
  • soient remerciés et encouragés par le commanditaire du projet.

Ce que je propose, c’est de réussir à ce que 80% des utilisateurs ciblés utilisent effectivement la nouvelle application informatique.

Je collabore avec l’équipe projet qui conçoit, développe et déploie la solution informatique, et avec l’équipe de support Métier, même après la fin du projet.

Plus spécifiquement :

  • je détermine avec le commanditaire en quoi le changement d’habitudes de travail est essentiel pour atteindre les objectifs du projet ;
  • j’organise les conversations nécessaires avec le commanditaire, les manageurs de proximité et les collaborateurs
  • j’assure le déploiement de la formation aux nouveaux outils auprès des manageurs de proximité et des collaborateurs
  • je mets en œuvre le coaching sur site pour résoudre les problèmes au quotidien
  • j’organise avec le commanditaire le renforcement des nouvelles habitudes de travail en montrant l’atteinte des objectifs du projet

4. Le bénéfice pour le client, pour la personne à qui vous parlez.

  • l’atteinte des objectifs pour lesquels l’investissement avait été lancé,
  • une expérience collective du succès utile au lancement des projets suivants, 
  • une organisation plus agile

5. Comment vous vous différenciez des autres prestataires.

  • J’aide tous les interlocuteurs à prendre leur part dans le succès du projet auprès des utilisateurs
  • Je collabore côté Métiers en lien étroit avec l’équipe projet informatique
  • Je module l’approche en fonction de la situation en suivant le Modèle ADKAR®

6. L’action à laquelle vous invitez votre interlocuteur.

Auriez-vous un moment pour évoquer un projet en cours d’application informatique qui, alors qu’il est stratégique, pourrait être mal accepté, et considérer ensemble comment le faire réussir ?

Vendre une caractéristique, un avantage ou un bénéfice ?

Il me revient ce mardi soir un brin de notre conversation hier, où tu évoquais, camarade, que tous les consultants à qui tu pourrais t'identifier ont pour caractéristique qu'ils sortent des big four (ou big five, je ne sais plus).

J'y pense maintenant par analogie à l'aspirateur. Lorsque Dyson s'est penché sur le marché, tous les aspirateurs avaient pour caractéristique qu'ils avaient un sac.

Je crois me rappeler d'une conversation avec un collègue commercial qu'un produit a caractéristique, avantage et bénéfice. Selon lui, un client achète un produit en raison du bénéfice qu'il en tire, non en raison de la caractéristique du produit. L'exemple qu'il a pris était celui-ci : tel client-ci achètera ce véhicule break-là parce qu'il lui permet d'aller à la pêche trois week-ends par mois (bénéfice), du fait qu'il engloutit toutes les courses du mois dans son coffre (avantage), du fait de ses 650 litres de contenance (caractéristique).

Si tu t'essayais à te comparer à ces consultants ex-big four, que dirais-tu que sont tes caractéristiques, tes avantages et les bénéfices possibles pour ton client ? (cela dit, il me semble me souvenir que seul le client est à même de définir pour lui-même les bénéfices ; en même temps, quels bénéfices tes clients précédents ont-ils eus à faire affaire avec toi ? ça vaudrait le coup de l'évoquer).

Voilà mes pensées captées au vol. La vente est assez loin de mon métier, aussi je te prie d'excuser mes approximations et raccourcis.

Je peux me tromper, mais je pense qu'il serait intéressant de rencontrer certains de ces consultants, à qui tu poserais ces trois questions :

  • Qu'est-ce que vous faites ?
  • Qu'est-ce qui est difficile ?
  • Avec qui travaillez-vous ?

Lesdits consultants pourraient accepter de te répondre d'autant plus aisément que tu les choisirais assez en dehors de ta zone d'expertise, ou de chalandise.

Bon courage, bonnes rencontres !

31 octobre 2016

Pourquoi se préoccuper du démarrage du projet

Dans un examen de travail du PMI (Project Management Institute, association professionnelle des chefs de projet dans le monde), nous lisons cette question-ci : Quelle phase du projet est typiquement la plus grevée d’incertitudes et la plus risquée ? Est-ce :

  1. Le démarrage ?
  2. Le développement ?
  3. L’exécution ?
  4. La conclusion ?

Eh bien, la réponse attendue est : le démarrage. Cette période de l’initiative où les parties prenantes se mettent d’accord sur l’intérêt du projet à venir, cette période qui prendra fin avec leur approbation de la charte du projet.

L’idée est la suivante : bondir sur la planification nous amène à laisser les plus grandes incertitudes non résolues. D’autant que, les témoignages convergent, une fois le projet lancé, l’on perd de vue son objectif.

Une autre question du même questionnaire de travail du PMI:

Quel est la période la plus cruciale pour vérifier les parties prenantes du projet et leurs intentions ?

  1. Lorsque la complexité du projet augmente ?
  2. Durant la phase de planification ?
  3. Durant la phase de démarrage ?
  4. Après que le plan de projet a été finalisé ?

Réponse de la communauté des chefs de projet du PMI : même si l’on garde un oeil sur les parties prenantes durant tout le projet, c’est durant la phase de démarrage que scruter les parties prenantes est le plus crucial.

Qu’est-ce à dire, si je suis propulsé dans un projet qui a démarré sans moi ? Eh bien, plutôt que de plonger dans la planification, je ferais mieux de commencer par analyser les parties prenantes.

Pour une prise de contact efficace par courriel

Michaël, pour ta recherche d'emploi, il y a, dans la droite ligne de l'auteur de référence (en ce qui me concerne), Richard Nelson BOLLES (Cf. son livre What Color Is Your Parachute?) deux plans dont nous venons de parler au téléphone, celui du courriel de prise de contact pour solliciter un entretien et celui du projet professionnel sensu stricto à développer au cours de l'entretien, sous forme d’elevator pitch.

Pour découvrir l'outil elevator pitch dans le nouveau site projet-initiative101.com

Pour le courriel de prise de contact, viser un courriel que tu liras à voix haute (exercice utile) en 2 minutes ou moins :

Bonjour, M/Mme XYZ. 

Je vous contacte de la part de (Untel).

Je fais... (mon parcours professionnel, d'où je viens--avec un verbe d'action (je fais aboutir les projets de mes clients depuis 199.) plutôt qu'un titre (je suis chef de projet) qui ne parle pas à tous de la même façon).

Je souhaite faire... (mon projet professionnel, idem un verbe d'action (je souhaite aider mes collègues à réussir leur projets au moindre coût en s'appuyant sur leur environnement et sur la décomposition structurée du travail) plutôt qu'un titre (je souhaite devenir consultant) qui ne plaît pas à tout le monde).

A cette étape de mon projet professionnel, je recueille le retour / feedback de professionnels pour le confronter au réel et l'affiner. 

(Untel) m'a recommandé de m'adresser à vous. Auriez-vous 20 minutes à m'accorder prochainement, afin que je vous expose mon projet et que vous disiez ce que vous en pensez ? Je précise que je ne sollicite ni stage ni emploi ni mission d'aucune sorte, juste votre feedback personnel.

Formule de politesse / Signature

 

Voici le brouillons des courriels que j'ai envoyés par saut de puces jusqu'à la personne qui avait le pouvoir et le désir de m'embaucher, pour information :

Mme R.,

Je vous contacte de la part de D. T.. Lucie, mon épouse, est invitée à travailler un an à la clinique M. dans le service de D. S. et nous l'accompagnons tous, nos trois enfants et moi-même. Nous prévoyons de nous rendre sur place en éclaireurs Lucie et moi dans la semaine du 14 juin.

Pour ma part, je fais aboutir des projets informatiques depuis 19 ans et ai reçu la certification Project Manager Professional en 2000, délivrée par le Project Management Institute basé en Pennsylvanie. Je travaillais alors chez IBM France. De plus, je forme des étudiants au référentiel PMI et j'aide des professionnels à réussir dans leur rôle de chef de projet, notamment ceux dont ce n'est pas la compétence première.

Durant cette année à Rochester, MN, je souhaite contribuer utilement à un ou plusieurs projets comme chef de projet, dans la planification, l'exécution ou la surveillance et le contrôle de ce(s) projet(s).

Je serais heureux de connaître votre avis sur la faisabilité de mon souhait et sur mon approche.

Puis-je vous demander vingt minutes de votre temps prochainement, au téléphone, à une heure de votre choix compte tenu du décalage horaire de 7 heures ?

En vous remerciant par avance, etc.

Voir aussi cet autre exemple de courriel pour solliciter un entretien-réseau dans le nouveau site projet-initiative101.com

 

Nota Bene : à tout contact généré par cette approche, tu dois répondre par un courriel de remerciement dans les 24 heures.

 

 


A qui vendre le management du changement ?

Comment faire pour que les gens de l'Informatique, de l'outil, livrent des applications utilisables ? Ergonomiques, certes, et aussi utilisables dans la vraie vie.

Comment faire pour que les gens des métiers utilisent les applications ?

Sabine, analyste métier dans une équipe d'informaticiens : C'est simple, ce que veut le promoteur du projet informatique, ce sont des équivalents-temps-plein en moins. 

S'il en est ainsi, je comprends que l'application ne soit pas utilisée par les utilisateurs dont elle menace l'emploi. La démarche menace l'emploi. De quel emploi s'agit-il, de qui ?

David, consultant en management de projet : Souvent, les commanditaires des projets ignorent combien coûte le projet et combien il est sensé rapporter ; alors, pourquoi le lancent-ils ?

Je risque une réponse : parce qu'en échange d'un os à ronger, l'Informatique produira des économies en équivalents-temps-plein. Même si c'est difficile à quantifier, ça vaut le coup d'essayer.

Du coup, à qui vendre le management du changement ? Quelle incertitude pertinente pour quel acteur le management du changement maîtrise-t-il ? Commencer par étudier les incertitudes des acteurs en présence.

Côté Métier, 

  • l'opérateur ? 
  • le super-utilisateur ?
  • le superviseur ?
  • le responsable business ?
  • le Directeur des Opérations ?

La mission, parce que la mission donne l'impulsion vers le long terme et soulève des problèmes à moyen terme et occupe à manager la nouveauté à court terme.

Côté Informatique,

  • le développeur ?
  • le manager ?
  • le chef de projet ?
  • le chef de service ?
  • le Directeur Informatique (CIO) ?

18 octobre 2016

Changement, moral, coach et supervision

Mon épouse prend la responsabilité d'un service au sein d'un centre de recherche médicale. Elle rencontre des gens, elle ouvre des armoires et découvre... un sentiment de découragement. Trop de choses à faire, trop de dysfonctionnements, l'équation paraît sans solution.

Ce matin, au petit-déjeuner, nous cherchons à comprendre la situation, à évaluer l'impact du changement sur le moral de l'acteur engagé. Il y a bien un point où le moral atteint son point bas. Patienter dans la tourmente, rester toutes antennes dehors et faire confiance en la situation et en soi-même, c'est plus facile avec quelqu'un à qui en parler.

Cette conversation me fait me rendre compte de ceci : faire équipe avec un coach, pratiquer la supervision, ça devrait faire partie du job de responsable d'équipe. J'ai vécu cela dès mes missions chez IBM Learning Services en ingénierie de formation et, à l'époque, je pensais que c'était du "nice-to-have". En fait, j'avais bien de la chance. L'essentiel m'a été donné lorsque j'en ai eu besoin.

Posté par RetourExperience à 08:31 - - Commentaires [0] - Permalien [#]
Tags : , , , ,

02 octobre 2016

Des boulots pour occuper les gens ?

David GRAEBER, auteur entre autres de "Dette : 5000 ans d'histoire" constate "l’hypertrophie du temps de travail qui veut que nous travaillons beaucoup pour des boulots dont une grande partie ne sert à rien d’autre qu’à occuper les gens". Je rapproche ça du constat de mes collègues informaticiens : entre 50 et 75% des applications informatiques que nous livrons sont inutilisées.

Qu'est-ce à dire ? En développant ces applications informatiques, en accomplissant ces projets, nous sommes-nous consacrés à des choses sans autre utilité que celle de nous occuper sainement ?

Si oui, alors poser la question de l'utilité d'une initiative avant d'en faire un projet est un problème. Comme est un problème de mesurer la différence qu'a faite une application informatique quelques mois après sa livraison. En effet, si nous renonçons à faire un projet parce qu'il est inutile, si nous montrons que 50% à 75% de nos livraisons sont inutiles, qu'adviendra-t-il de notre emploi ?

L'approche projet - ADKAR® promeut cette question initiale et cette revue post-démarrage. Et donc menace, d'une certaine façon, notre emploi. C'est ainsi que je m'explique la bonne foi de mon collègue informaticien dans une banque : jamais nous ne mesurons la différence qu'a faite un de nos projets.

En soi, les raisons sociales (le maintien de l'emploi) me paraissent légitimes. En même temps, le coût écologique de cette suractivité à haute technologie me semble démentiel.

Tout un système est à l'oeuvre. Il favorise les technologies les plus coûteuses et se pare d'écologie à la marge. Exemple : la HD, Haute Définition. Des mégapixels de clichés envoyés par des réseaux énormes sur ces serveurs colossaux dans des datacenters pharaoniques - mais refroidis de la plus écologique des façons. Tous les acteurs s'entendent et se renforcent les uns les autres. Les capacités croissent. Et l'utilité ?

Pour aider les gens à interroger leur modèle, il me semble qu'il faut aborder la question de l'emploi. Par exemple, qu'est-ce qui garantit que j'aurai un emploi si je quitte le bateau de la HD ? Ou celui du développement d'applications inutiles ?  Ou celui de l'accumulation d'informations superflues ? 

Est-ce la même situation pour la recherche de la Qualité ? Amis de Toyota, vous assortissez votre recherche Qualité par la promesse qu'il y aura toujours de problèmes, de toute façon, et donc aucun chômage pour ceux que passionne leur résolution.

Alors, que dire à ceux qui s'inquiètent et avouent : "nous voulons bien nous centrer sur l'utile au nom de l'écologie mais quid si nos emplois disparaissent ?"

Là, je sèche. Une idée ?

07 septembre 2016

A personal insight in Project Management, presentation to Master's Degree students in Agricultural Engineering, Lille.

Pascal’s short resume:

I have been leading initiatives and projects from 6 to 6000 persons-days.

I have trained over 1,200 people responsible for initiatives and projects

since my certification as a professional Project Manager in Year 2000 (PMP®).

I am a Prosci certified change management practitioner since 2014. 

Pascal’s beliefs:

I believe that this Earth is the best we have!

I believe that we have all that is necessary in the here and now to improve our working methods.

I believe we can succeed in our initiatives by applying the basic essentials, and

I believe we can save time and energy which can be dedicated to other aspects of our life.

This is why I spread the word about project management, this is why I train people as project managers, this is why I woke up this morning, not to teach you about project management tools and techniques, but to tell you about 7 lessons we project managers have in mind as we’re leading a team.

In one word : NEW

Project is about delivering something NEW.

Story. At Prisunic, in 1992, I was assigned the task of installing a brand new payroll application to replace an in-house 25 year-old program. The payroll rules would not change at all. Just the application. I started studying the existing program with its sole conceptor/designer/programmer/maintenance specialist. This man was a dinosaur, he had been developping and maintaining the whole program alone for the last 25 years. I was impressed by his fait: a whole payroll program, no bug left... However, this man would retire within 6 months and his retirement put the payroll operations at risk: no more evolution would soon be possible. I was about to replace his program by another one, a program that could be taylored to accomodate future changes in regulations or business rules. That was « new », the only thing I was there for.

Image: an old man, alone, is starring at his achievements and he is about to leave. Up to his followers to take care of the old stuff!

So, project is about delivering something EW.

Delivering the same thing with the same people working with the same routines, this is what operations are about.

New to whom? Not necessarily new to everyone.

How new? 100% new? No, not necessarily entirely new.

So, NEW. And so what?

Is it something that we can do now?

What sense does it make to design, develop, deploy something new to people?

In two words : REDUCE UNCERTAINTY

I guess that nobody is delighted with uncertainty.

Story. This time I was presenting the IBM application to the sales managers of Volkswagen dealerships. The project was about putting a computer on the salesmen’s desks to help them sell cars and loans. The audience was not happy with that project : they were supposed to sell the computer aided sale process to their salesmen. That day, they couldn’t see any reason why they would succeed. The product was not making sense to them, the project was bringing a lot of uncertainty into their relationships with their salesmen, on their performance to come. I was soon like a child in the lions’ den, about to be torn apart. Then my correspondant on the client’s side, a respected professional, jumped on stage and took the lead: everyone was calm again within a minute.

Image. A worried old woman. Nobody is delighted with uncertainty.

We, actors, aim at reducing our own uncertainty. By which means, usually?

            By organization

            By routines

            By alliances

A project starts with more uncertainties, it raises the uncertainty level

            Whom for? Stakeholders!

            Who are the stakeholders?

            Which uncertainties are relevant for them?

We as professionals are supposed to reduce relevant uncertainties for anyone involved in the project.

            Why? To have some power; to be recognized as value actors

            How? Let’s start with listening, and then let’s write down a project CHARTER.

                        Document needs, constraints, objectives, everything that matters to reduce uncertainty on the client’s side and on your own side.

In three words : GOOD , FAST, CHEAP

Project management typically is about managing 3 parameters: scope, time and cost.

Story. It was back in the late 1990’s. I was proud of my project plan. It was about training 10.000 people about how to use Windows 3.11. Most people had never been exposed to PCs. I’ve been working on the training plan with 4 specialists. After I presented the plan to the steering committee for validation, I was expecting many a remark but I only got this one: Pascal, you said you would do it for 7 million Francs, do it for 5. All I found myself able to do was to answer: yes. On my way back to the office, I was devastated: how would the team react? I told them. They just said: OK, Pascal, let’s clean expensive things out of scope until we hit the 5 million limit. So did we. No more color prints, no more on-site coaching, but more participants in the training room, shorter sessions, handouts focused on the mere essentials. At the end of the project, people were able to use Windows 3.11, not as quick as we imagined, but they did. Facing a shortage of budget, we had arranged a new  scope and a new timeframe. As one side of the magic triangle was redefined, we had to redefine the two others as well.

Image. On the forefront, people lying on the grass reading books and victorian houses in San Francisco, all about old technology. Well, let’s question ourselves : how better, faster, cheaper do we actually do with nowadays technology?

So, project management typical 3 parameters are scope, time and cost.

Very soon we are asked to evaluate how good, fast, cheap the product will be;

Very soon we are asked to evaluate how good, fast, cheap the PROJECT will be.

Can a project be (absolutely) good, fast and cheap?

What is it for a project to be good?

            Relevance to users, relevance to business

            Scope is grade. A Rolls Royce is a high-grade car. Logan is a low-grade car.

            Quality is conformance to requirements. Better a 100% functional used Logan than a Rolls-Royce of which the air-conditioner is out of order.

What is it for a project to be fast?

            The right time. Time-to-market. Time-to-implementation.

What is it for a project to be cheap?

            Who said it was the expected cost from the beginning?

                        About estimates? Accuracy versus precision.

            Who pays for the project costs?

Can a project be simultaneously good and fast and cheap?

This magic triangle will evolve.

Anyway, just pick two parameters, and prepare your sponsor to accept the rest.

In four words : DELIVER TOGETHER WITH METHOD

Story. As a project manager, I was chairing my first core-team meeting in that project. My so-called Technical Director, somebody new to me as I was new to everyone around, started with « we cannot proceed with the roll-out as long as the Microsoft patch XYZ-666 is not installed on server 5, 7 and 9 ». I said to myself, What is he talking about ? who cares about that detail not relevant until we roll-out in 6 months ? does he want to impress me ? I started heating up inside, I was about to retaliate, when a light bulb went on in my mind. He was showing how detail-oriented he was, whereas I was helicopter view-oriented: just the opposite ! I laughed at myself and cooled down. Had I not been aware of the cognitive differences, I could have hurt that colleague, I could have looked like a jerk, and I could have put the project at risk, and I could have lost my job.

Image: passers-by and their shadows, late in a sunny afternoon. People come to the project with their past history (of failure and success), and with their cognitive capabilities. All those things are like shadows we may not pay attention to.

Deliver quickly.

Better deliver quick and (reasonably) dirty than deliver excellent and late. Why?

            Reality check

            Let the user play with the mock-up and discover what they really need!

Together

Prevent yourself from doing things alone.

Make sure you align with others frequently

            a full time project team should stand-up meet ¼ hour every day

            a part time project team should meet for a workshop 1 hour a week

With

Better « with » than « for ». People you do things for are bound to be forCED to accept things from you. For=Force/Power

Try this at home. With=collaboration

It’s about personal energy mating with group energy, too. Groups are made of individuals, and people are affected one person at a time, everyone his/her own way.

Method

Even somebody without method comes at the table with their know-how at something they have been successful at in the past. With people come their methods like shadows.

Discuss the methods, question the methods, elicit one method in common and follow the method.

Some methods may account for some failures, by accident; having no method is a recipe for failure, by nature.

In five words : COMMIT TO MAKE USEFUL DIFFERENCES

Story. I was interviewing a colleague in 2014. She was an consultant working in the IT department of a large purchasing business unit. She told me they had a recent survey showing that 75% of the user-oriented applications they have delivered on operations for the two last years have no user at all. Nobody would use 3 applications out of 4. I was shocked. I started asking anyone I could encounter about their own statistics and, suprisingly, everyone confirmed that more than half of the delivered user-oriented applications are not used. As if they do no difference.

Image. A woman is walking towards a large, old tree. What difference does the tree do to the woman, like beauty or shadow or fruit or anything else (species it helps shelter, chemicals it synthetizes, etc.)? How long did it take the tree to make that/those difference(s). What did it take its environment like patience and care to allow this tree to deliver today? What does it take for this difference to last until the next big thing comes out?

What questions may we derive from this?

Make a difference? To whom?

Making usefull differences is somehow different from "making differences (= the ones that we're introducing) useful")

Commit

What does a project team commit to?

            Good – fast – cheap triangle

            Best effort?

In six words : WHO SHALL SAY : WHAT A SUCCESS !?

Story. I was the only customer at the auto rental’s desk that Tuesday afternoon, and it took them 45 minutes to serve me, due to a change IT guys have made in the front-desk system over the past week-end. It was Tuesday and the operators were struggling with the new interface. They tried to get some help over the phone, but in vain. Key users were overwhelmed. And guess what, a dozen customers were about to come by the last train to pick their car at the rental desk. For the management, the front-office project was a success. At the same time, the end-users were scared to death.

Image. A hiker springs over a mountain pass. She looks happy, she runs out of the valley over the pass, however she’s alone. Is she happy, actually ? Or is she fleeing from a danger back to her safe place? How do we make sure that people use what we deliver ? How can we help them be happy as they start dealing with our solution ?

The stakeholders again.

What happens for stakeholders when you launch an initiative ? How could you make it for the stakeholders to succeed with what you are about to deliver to them? According to the ADKAR© Model, there are 5 steps :

            Awareness

People who’ll live with your solution should first get from the big boss why there is a need for change, why we can’t stay were we are, etc.

            Desire

People who’ll live with your solution should then have a conversation with their supervisors: what’s in it for me and for us? What’s the difference with my responsiblities and my activities?

            Knowledge

People should learn how to use your solution.

            Ability

People should get help from you and their supervisors to solve their problems as they are using your solution.

            Reinforcement

People should get from the big boss encouragements and congratulations, as confirmations that their effort was meaningful and successful.

In seven words : WHAT CAN GO WRONG WILL GO WRONG

Story. As a project manager, I was facing sort of bad-mood people who unfortunately was key to the success of the project: he would be responsible for the Knowledge Base of the future unified Service Desk and Hot-Line. My perception was: this guy’s absence of team spirit puts the developments at risk as certainly as rain is wet. I asked myself: should I send a request for hiring cooler a resource to do the job? As I was weighing the pros and cons of the replacement option, it became clear that the time frame was too short for any newcomer to successfully cope with the Knowledge Base within the project time-frame. So, I once again decided to stick to the metholology and to invite the team do the Work Breakdown Structure exercise in the next couple of days. Every single teammember would breakdown his/her deliverables and explain his/her job to the team.

At first, our friend escalated my decision but his manager said: please do what Pascal said. So, he reluctantly followed the crowd and this is what happened: while he was presenting the breakdown of his activities to the rest of the team, all of us could tell how central his job was: with him, we could succeed (with possible shine on him), without him, we should fail (with probable shame on him). And we told him so. That very day, he decided to teamwork the best he could and he did a great job. The exercise of the WBS (Work Breakdown Structure) helped convert a risk into an opportunity. Basically, this is what project management methodologies are about: convert risks into opportunities.

Image. Large, rainy cloud over a sunny land. It’s about to rain some time, sooner or later in our latitude. As you’re planning for some outdoor activity on next week-end, and the weather is of utmost importance to the success of what you’re planning for, what do you do? You get some weather forecast. And you proactively get ready today for what is likely to come tomorrow.

There are risks. Thinks that can go wrong will go wrong, Murphy said. It’s a question of time.

For us project managers, it’s about anticipation, and at the same time we’re not to anticipate everything. People expect us to take care of what can go wrong and to fix what is going wrong already. The trick is to have energy left as we are fixing what’s going wrong. We should devote that energy into anticipating what is important to the client and to us all, into converting risks into opportunities.

Well, that’s about it.

16 juin 2016

Manageurs, que faire des problèmes ?

Dans la littérature, il est montré que lorsque le management punit l'erreur, les auteurs d'erreurs se taisent de peur d'être punis et que, ce faisant, ils donnent à l'erreur, à leur cor défendant, un grand avenir. En effet, il faudrait parler de l'erreur pour la résoudre et communiquer avec ceux qui sont susceptibles de la reproduire.

Il me revient ce soir ce que j'ai lu du Toyota Production System, à savoir que le Lean Management suppose des manageurs qui acceptent les problèmes et apportent leur soutien à celui ou à celle qui divulgue un problème. Sans quoi, il pourrait en être du problème comme de l'erreur et le Lean Management ne saurait prendre.

Je peux me tromper, mais il me semble que, si elle se sent menacée d'être punie comme mauvaise ouvrière, la personne qui découvre un problème a deux options raisonnables : 

  • pallier le problème qui continuera de se produire et d'occuper à sa résolution ladite personne
  • résoudre le problème par devers elle sans rien communiquer tant qu'il n'est pas résolu

En attendant, quels problèmes restent ainsi cachés ? J'imagine assez bien une file de problèmes qui attendent que celui de devant soit résolu pour apparaître, comme il en est de mes erreurs de développement lorsque le programme s'arrête sur un bug en amont qui, de fait, masque ceux qui sont tapis, patients, en aval du programme.

L'idée du Lean Management est qu'une organisation se porte mieux et soutient mieux ses collaborateurs en apportant des solutions aux problèmes qui surgissent. Sans la bienveillance des manageurs, les collaborateurs risquent fort d'adopter une attitude d'éleveur de problèmes plutôt que d'élever des solutions.

Je me rappelle cette anecdote : un américain est nommé à la tête d'une usine de production Toyota aux USA. Son expérience chez Ford sous le bras, il déclare à son mentor japonais, fier comme tout : Premier mois de production, aucun problème à signaler ! Le nippon de répondre : C'est anormal, vous n'avez pas été attentif à ce qui se passe en réalité ; il n'y a pas de production sans problème !