Manager un projet - influencer l'organisation

04 mars 2017

"Le project management n'a pas réalisé sa promesse"

J'écoute ce responsable de formation au management de projet, nous sommes en conversation avec un technico-commercial en change management. Au décours de notre échange d'expériences, le responsable de formation assène : "le project management n'a pas réalisé sa promesse". 

Le PMBOK a d'emblée mis au centre des préoccupations du management de projet l'atteinte des objectifs business. La majorité des projets a plutôt livré les pré-requis techniques et laissé les collaborateurs s'en débrouiller. Or, certains objectifs sont atteints à la condition que les collaborateurs changent leur façons de travailler. Bien qu'équipés des pré-requis techniques, par manque d'accompagnement, les collaborateurs sont restés à leurs anciennes pratiques et les objectifs business n'ont pas été atteints. Ce qui passa inaperçu des project managers à qui personne n'a demandé, jamais, de revenir mesurer l'impact de leur projet sur le business. De toutes façons, ils étaient occupés au projet suivant.

Ainsi, le PMBOK promettait que les projets bien gérés contribueraient à l'atteinte des objectifs business, et la promesse est, la plupart du temps, non tenue. L'on pourrait excuser le PMBOK : après tout, la livraison était "good, fast and cheap".

De même, nous formons des milliers de project managers à de nouveaux outils, à de nouvelles postures de leadership sans autorité hiérarchique. Nouveaux outils ? Facile, l'organisation acquiert les licences et, au mieux, forme à leur utilisation les project managers. Nouvelles postures ? Difficile tant que l'organisation n'est pas prête à accueillir ce changement. Frustrations pour les project managers, progrès minime de l'organisation..., autre promesse non tenue.

Non pas que ce soit une absence totale de succès. De même que ISO se propose d'étendre les meilleures pratiques des génies aux collaborations ordinaires, nous proposions de transformer les pratiques à grande échelle. Nous promettions dans nos formations que le plus grand nombre pourrait jouer le rôle de PM ; or, c'est principalement des cas particuliers, des personnes spécifiquement douées que nous avons lancées avec succès. Peu de collaborateurs, des progrès somme toute lents et difficilement discernables.

Alors, à quoi sert le change management ? Quelle est sa promesse ? Comment la tient-il ?

La promesse du change management : des changements que les collaborateurs mettent en oeuvre, beaucoup de collaborateurs, rapidement, avec efficacité. Many, quickly, well. Et des objectifs business enfin atteints.

Alors, change management sans project management ? Oh que non. C'est plutôt jambe droite et jambe gauche, inséparables, coordonnées, aussi solides l'une que l'autre, qui font le marcheur.

Et donc, au-delà des plans d'accompagnement du changement, comment tenir une telle promesse ? C'est l'apport du Modèle ADKAR.

(à suivre)


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.

06 février 2016

Comment une maquette m'a redonné espoir.

J’étais un peu désespéré au début. Je n’ai pas tout vu. Un peu comme si je rentrais dans une forêt et que je m'y égarais : où sont les clairières ? Cette clairière où je m’étais retrouvé, comment y retourner ? J’avais cru comprendre que c’était derrière tel arbre, mais non, ce n’est pas tel arbre ! J’avais cru que c’était ça, mais non, ce n’était pas ça. Je commençais à désespérer vu l’ampleur de mon ignorance, vu l’ampleur de mon travail à combler mon ignorance pour devenir assez compétent et créer des formations.

Je suis toujours surpris qu’on demande à un vulgum pecus qui est depuis 20 jours sur le projet, de créer des formations sur la base des connaissances accumulées, compilées et organisées par des dizaines de consultants qui travaillent depuis 10.000 jours sur la question ; ça me dépasse. Bref, fermons la parenthèse.

Du coup, me voilà très embêté dans cette forêt. Je me dis, oulah ! je suis incertain de ma capacité à faire, si jamais je livre quelque chose qui me convient à mon avis et qui ne convient pas à leur avis, je n’aurais que ma fierté dans laquelle me draper, je pourrai leur dire : Vous n’avez rien compris, je suis un bon consultant qui a fait ce qui est bon pour vous, les uns et les autres disent que c’est bon pour vous, prenez tous les bouquins machins et si vous n’êtes pas convaincus, c'est que vous êtes mauvais ; vos gueules, je m’en vais, vous êtes indignes de moi.

Du coup, me suis-je dit, comment est-ce que je pourrais me rassurer en leur présentant quelque chose qui les satisfasse à la fin ? Eh bien, en leur présentant le plus tôt possible quelque chose qui ressemble à ce qu’ils auront à la fin.

Et puis, me suis-je encore dit, on me ressasse qu’ils sont surbookés, qu’ils ne sont pas disponibles pour répondre à mes questions, Xave fait un tir de barrage pas possible, je n’arrive pas à accéder à ces gens-là, ce qui est très différent de la façon dont normalement je procède. Et donc, je n’ai pas l’autorisation de leur prendre du temps pour qu’ils m’expliquent, je suis sensé tout découvrir sur les livres ou plus exactement sur ce qu’ils ont écrit, et pour moi, comme je l’ai dit à Xave, c’est comme si elle me disait de réaliser une formation à la langue basque en ayant d’un côté un dictionnaire basque-français et de l’autre une grammaire basque.

Comment est-ce que je pourrais amener ces gens surbookés à contribuer, bien qu’ils soient surbookés ? Comment est-ce que je pourrais faire pour sortir de cette forêt avec un plan, ou plus exactement pour créer un plan de cette forêt ? Peut-être que je pourrais cartographier un bout de cette forêt ? Cartographier un bout restreint mais cartographié profondément, de sorte que là-dessus je pourrais trouver des motifs répétitifs, des éléments qui vont me simplifier la compréhension de cette forêt, des chemins, etc. ? 

Et me rappelant que je travaille dans le milieu automobile, je me suis dit : proposons une maquette, puisque c’est comme ça qu’ils font quand ils travaillent sur un nouveau véhicule. Et du coup, ça a été accepté. Et ça a fonctionné. Et, là où je ne pouvais obtenir une journée, j’ai réussi à collaborer avec eux une heure, je les ai amené à spécifier ce qu’ils voulaient pour la maquette. Je leur ai dit : Ce que vous spécifiez pour la maquette, ce sont en fait les spécifications pour le produit final et j'en prendrai une partie seulement pour la maquette.

Ca collait avec ce à quoi je m’étais engagé : produire quelque chose sans que ce soit de grande tenue, j’allais dire, sans que ce soit de grande qualité, mais non, la qualité c’est juste la conformité aux attentes. Donc il suffisait que je les amène à attendre quelque chose du grade d'une maquette et que je livre la maquette, et la qualité de la maquette serait à 100%, c'est à dire 100% conforme au grade annoncé.

Ils se sont mis à contribuer, je leur ai livré la maquette, avec l’aide de personnes complètement surbookées mais qui me voyant dans cet état se sont crues obligées de m’aider. Donc, j’ai créé un besoin et ça a fonctionné, et ça a même dépassé mes attentes, ils étaient contents du résultat, ils étaient rassurés et moi aussi, et puis je ne m’attendais pas à ça mais ce que j’ai produit va être utile à d’autres maquettes. Par exemple, j’ai produit un module PauvrePoint et il est question d’en faire du e-learning, ça va être partiellement réutilisé pour faire une maquette de formation à distance. Et sur la base de cette maquette, j’ai atteint un autre objectif important pour moi : apprendre la façon dont je peux travailler et estimer le temps que ça va me prendre. Le faire sur une maquette m’a permis de voir avec qui, avec quoi, avec quelle méthode je dois travailler pour produire quelque chose qui vaille le coup.

Donc, je suis très content. Je me fais la réflexion qu'une fois encore, lorsque dans un projet je me demande si la décision que j’envisage est bonne ou si ça vaut le coup de réfléchir plus avant à une opportunité, je me demande : à combien d’objectifs cette décision permet-elle de répondre ? Si elle ne répond qu’à un objectif, je me dis, bof, il y a certainement mieux à faire. Si elle répond à deux objectifs, je me dis, bon, ce n’est pas bien excitant, il y a mieux à faire. Si elle répond à trois objectifs, là je me dis, ça commence à être intéressant, quatre objectifs il faut le faire, cinq objectifs il n’y a rien de mieux à faire que ça.

Et j’avoue que je suis très heureux de cette approche de la maquette : plusieurs objectifs atteints ? On y va !

02 février 2016

Pourquoi Agile est-il respectueux ?

Très intéressant, le time-boxing. Parce que ce que j’ai réussir à faire, c’est à satisfaire mon client avec une Logan, versus l’insatisfaire avec une Rolls, en tout cas avec une Rolls à mes propres yeux, avec beaucoup plus d’efforts, avec beaucoup plus de temps, et donc avec beaucoup plus de frustration.

C’est peut-être ça, l’approche Agile : c’est mouiller le client et de livrer dans un time-box de deux mois, par exemple, un time-box où la seule chose qui est vraiment fixe, c’est l’équipe qui développe à plein temps, et en même temps l’équipe s’engage à livrer en temps et en heure et c’est le contenu qu’on va faire varier avec l’aide d’un représentant des utilisateurs, le "Product Owner", le "Responsable du Produit". C'est lui, le Responsable du Produit, qui réalise l'analyse Pareto et dit : c'est ceci qu'il faut livrer en premier, c'est cela qu'il faut livrer plus tard.

Je trouve que c’est très honnête vis-à-vis des personnes, l’approche Agile. Lorsque je collaborais à des projets en cycle en V, c’était logique : on déploie ce qu’on a testé, on teste ce qu’on a développé, on développe ce qu’on a conçu, on conçoit ce qu’on a défini. Alors Monsieur le Client, définissez ce que vous voulez et dans un an, nous vous livrerons ce que vous souhaitez.

C’est déjà violent, le discours du cycle en V, parce que ça paraît si logique que c’est comme si j’entendais en sourdine le message : Si vous n’êtes pas d’accord avec ça, Monsieur le Client, c’est qu’il vous manque une case.

De toutes façon, le discours "définissez ce que vous voulez et on vous le livrera", je trouve ça très injuste parce qu’en réalité, non, je ne crois pas que les utilisateurs sachent ce qu’ils veulent. Ils savent déjà difficilement ce qu’ils font et par ailleurs ils ne savent pas vraiment ce qu’ils devraient faire pour que ça fonctionne mieux. Ils sont insatisfaits de leur présent et ils sont incertains de leur avenir. Leur dire : décrivez-nous ce que vous voulez faire, c’est impossible pour eux, c’est les mettre dans la quadrature du cercle. C’est les torturer. C’est très peu honnête.

Alors que la méthode Agile glisse les utilisateurs dans la peau du futur, les opérateurs s’aperçoivent très vite de ce qu’ils veulent avec les mains sur l’outil. Voilà.

11 juin 2015

Une forme équilibrée de pouvoir cultivant la liberté par le relationnel

"Une forme équilibrée de pouvoir cultivant la liberté par le relationnel." Linda Kohanov, Comme les Chevaux, Ensemble et Puissants, Le courrier du Livre, Paris, 2013, page 241.

Longtemps j’ai cru montrer ma valeur en amenant les gens à contrecarrer le cours naturel, ajoutant au succès sueur et mérite. Ma patte était là. Si les choses se passaient naturellement, n’étais-je point inutile ? Il me fallut des anicroches, un séisme et quinze ans pour me rendre compte combien j’étais narcissique et nuisible.

Se rendre disponible à ce qui est, utiliser les forces en présence et accompagner l’énergie dans un résultat non pour les personnes concernées mais avec elles. C'est tellement plus efficace. Et agréable. C'est du moins mon expérience.

Posté par RetourExperience à 00:29 - - Commentaires [0] - Permalien [#]
Tags : , , , ,

02 mai 2015

Mesurer les résultats business de nos projets informatiques n'est pas une évidence

Philippe G., chef de projet informatique dans une banque : Non, nous ne mesurons pas les résultats business de nos projets, il n'y a pas besoin de le faire et ça ne nous gêne en rien. Tout de suite après un projet, il y en a un autre à lancer, et les projets se succèdent. De toute façon, nous sommes à la traîne des besoins des utilisateurs, hélas. Nous sommes trop peu nombreux à l'informatique pour répondre à toutes leurs demandes. Cela fait que, lorsque nous leur livrons une application informatique, ils se jettent littéralement dessus.

Et si s'interroger sur les résultats business des projets, c'était risquer de s'apercevoir qu'on ne travaille pas sur les bons projets ? Ou bien que nos applications informatiques sont utilisées par une faction des utilisateurs à qui elles sont destinées ? Voire, qu'on est trop nombreux à la DSI ?

Cela vaudrait le coup d'ouvrir une cellule d'identification des idées et initiatives avant qu'elles ne deviennent projets, en même temps qu'une cellule d'évaluation des projets côté business.

17 mars 2014

Initiation : why bother ?

We read in a PMI-like test : Which phase of the project life cycle typically has the highest uncertainty and risk associated with it ?

  1. Initiation.
  2. Development.
  3. Execution.
  4. Conclusion.

Jumping right on the planning phase lets most of the uncertainty unsolved. So, let's deal with it from the initiation--the very purpose of the present blog.

Posté par RetourExperience à 10:41 - - Commentaires [1] - Permalien [#]

13 novembre 2013

Projet 1.2. De l'objectif à ce qu'il reste à développer (conception)

Hypothèse / affirmation - savoir. Concevoir le livrable avec les utilisateurs du livrable. Viser le juste nécessaire : c'est ça qui a de la valeur - ce qui est en plus sera considéré comme trop cher, toujours.

Outil - savoir-faire. Approche objectifs donc rôles donc besoins donc fonctionnalités donc situations d'usage donc reste-à-développer.

Goal-to-FeatureGraph-FR

1. Exprimer les objectifs, ceux de l'initiative.

  • réaliser une piste cyclable entre les différents bâtiments de l'usine afin de décongestionner les voies et parkings.

2. Identifier les rôles, ceux sur lesquels l'objectif a un impact.

  • les utilisateurs des vélos,
  • ceux qui les maintiennent en état et les réparent,
  • ceux qui les achètent,
  • ceux qui circulent dans l'usine à pied,
  • ceux qui circulent en voiture, en camion,
  • ceux qui surveillent la santé des salariés,
  • ceux qui communiquent à propos l'usine.

3. Recueillir auprès des parties prenantes leurs besoins quant à chaque rôle.

  • Les utilisateurs souhaitent éviter d'arriver en nage et de devoir prendre une douche à leur arrivée à destination,
  • ceux qui maintiennent les vélos en état souhaitent limiter le nombre de réparations triviales, les crevaisons, par exemple.

4. Décrire les situations d'usage de chaque rôle à propos de chaque besoin.

  • les utilisateurs des vélos souhaitent un parcours le plus direct entre deux points, évitant les arrêts (stop, feux) et les changements brusques d'altitude pour éviter de transpirer dans les côtes et de se refroidir dans les descentes ;
  • ceux qui les maintiennent en état et les réparent souhaitent le moins de crevaisons possible, d'où des pistes cyclables faciles à nettoyer (des bouts de verre, des clous, etc.) et sûres (éviter de passer sous les arbres à feuilles mortes, éviter les points où le vent s'engouffre et déséquilibre les cyclistes, etc.) pour limiter le nombre de vélos hors service à un instant t.

5. Déduire des situations d'usage les fonctionnalités du produit/service qui répondent aux attentes, lesquelles sont optionnelles (on pourrait s'en passer) et lesquelles sont à développer en priorité.

  • une voie principale et des raccourcis balisés,
  • une règle de priorité des vélos sur les voitures (sur la piste cyclable) et des piétons sur les vélos (dans les clous),
  • pas plus de 3% de pente quitte à serpenter
  • une assistance électrique sur les vélos,
  • le passage d'une machine de nettoyage de rue une fois par semaine de décembre à août et deux fois par semaine de septembre à novembre,
  • des pneus increvables, 
  • une manche à air aux points dangereux pour signaler un vent violent.

6. Définir le reste-à-développer, c'est à dire les livrables à développer et livrer en priorité pour fournir les fonctionnalités à développer en priorité.

  • un plan de masse avec les tracés des voies et les points dangereux,
  • des panneaux de signalisation à installer le long des voies,
  • des seaux de peinture spéciale voirie (non glissante pour les deux-roues),
  • le marquage des pistes cyclables,
  • trois manches à air,
  • un article dans la feuille de chou locale pour présenter la réalisation, etc.

Expérimentation - savoir-être. Concevoir les livrables avec les utilisateurs des livrables - et valider, valider, valider.

Bertrand. J'avais fait hier soir une analyse exhaustive - du moins, je croyais. PM. Que s'est-il passé ? Bertrand. J'ai présenté mes résultats aux collègues et, un quart d'heure après, il ne restait rien de ma pièce montée. PM. En quel sens ? Bertrand. Eh bien, mes idées n'étaient pas mauvaises, mais les collègues les ont arrangées, précisées, chacun s'en est emparé pour son métier à lui, son rôle à lui. PM. Qu'est-ce que ça te fait ? Bertrand. Je me sens fatigué de mes recherches nocturnes et déçu qu'elles n'aient pas survécu à la confrontation. PM. Fatigué et déçu. Bertrand. Oui. Cela dit, ce qu'il en sort, c'est plutôt bien : ça sort de chez eux, au moins. PM. Ils se sont approprié ta démarche. Bertrand. C'est bien ça, ils se sont approprié la démarche et sont allés un cran plus loin, vers des développements que je n'avais pas prévus. PM. Cela prend une tournure inattendue. Bertrand. Disons que ce n'est pas ce que j'avais en tête initialement. PM. Eh bien, allons-y avec eux, puisqu'ils sont du voyage.

Références - savoir. APTE, Analyse de la valeur, ADKAR, Agile-Scrum.

Bertrand de la BRETESCHE, La Méthode APTE, Analyse de la Valeur, Analyse Fonctionnelle, Editions Pétrelle, 2000. Voir aussi http://cabinet-apte.fr/

Parties prenantes - responsabilité. Utilisateurs.