Accompagner un changement - situations typiques

03 décembre 2016

Hors soutien du management, point d'utilisateur

Gérard dirige des projets dans l'automobile, des projets de conception et de réalisation de parties complexes d'un véhicule : le tableau de bord. Conversation avec son manageur :

Manageur : Félicitations pour ton projet, vous avez livré avec 114 jours d'avance sur le planning, contre 90 jours de retard en moyenne pour ce genre de projet. Comment avez-vous fait ?

Gérard : Le facteur-clé, c'est que l'équipe a utilisé l'application PDM (Product Development Management), tout simplement.

Note : L'application PDM en question est une base de données dans laquelle les concepteurs et les fabricants partagent les fichiers techniques des pièces fabriquées : conceptions 3D, dessins 2D, dossiers réglementaires, etc.

Manageur : Ah oui, c'est vrai, l'application PDM, c'est ton dada !

Gérard comprend que l'organisation considère l'application PDM comme une option, sans plus. De fait, parmi les collaborateurs ciblés, seuls 20% utilisent l'application PDM, les autres restent adeptes d'un tableur bien connu pour son excel-lence. 

Hélas, le projet d'une nouvelle version de l'application PDM suit le même chemin : un déploiement inspiré de la croyance "bonne application + bonne formation = bonne utilisation".

Le Modèle ADKAR® est non seulement opérationnel, il est prédictif. Commanditaires silencieux (conscience nulle), management juste informé (désir mou), donc : la nouvelle application restera le dada de certains, non le standard de tous.

Posté par RetourExperience à 12:25 - - Commentaires [0] - Permalien [#]
Tags : , ,


23 juillet 2015

"La multiplication des chefs de projet est une catastrophe managériale majeure", affirme le sociologue François Dupuy

Lu sur le site de l’Usine Nouvelle, article de posté par Christophe BYS le 16 janvier 2015, http://www.usinenouvelle.com/article/la-multiplication-des-chefs-de-projet-est-une-catastrophe-manageriale-majeure-affirme-le-sociologue-francois-dupuy.N307730

En substance, François Dupuy développe l'idée que les organisations suscitent des chefs de projet pour faire de la transversalité là où prospèrent les silos, en vain.

Expérience personnelle : former ces mêmes chefs de projet aux yakafokons du management de projet donne rarement les résultats escomptés. Illustration de l’illusion commune à laquelle j’ai initialement sacrifié : le produit est bon (en l’occurrence le management de projet transversal), la formation est bonne (donnée par les bons experts), alors l’exécution suivra. Or, l’exécution suit rarement, parce que l'environnement des chefs de projet n'est pas prêt à les suivre.

François Dupuy propose d’aborder le sujet par un trio de prémisses : les gens sont intelligents, les gens font selon ce que leur environnement promeut, les gens évitent ce que leur environnement sanctionne. Dès lors, si l’environnement ne promeut pas la coopération et sanctionne les erreurs individuelles, multiplier les chefs de projet revient à uriner dans un stradivarius—ainsi qu'à décourager les violonistes et faire fuir les auditeurs.

Examinons les trois prémisses une à une.

  1. Les gens sont intelligents. OK, car s’ils sont stupides, autant adopter directement la dictature : je sais, vous faites. Mais nous savons ce qu’endurent les dictateurs.
  2. Les gens font selon ce que leur environnement promeut : si l'antiquaire donne $10 pour chaque papyrus, le berger rapporte plusieurs manuscrits de la Mer Morte car il a déchiré au préalable celui qu'il a trouvé. Cas cité par Rolf Dobelli dans « The Art Of Thinking Clearly ».
  3. Les gens évitent ce que leur environnement sanctionne : les préparateurs de l'avion collaborent avec leur coordinateur au sol aussi longtemps que c'est lui/elle qui assigne bons et mauvais points. Dès lors qu'une réorganisation prive le coordinateur au sol de ce levier de sanction, les coordinations se grippent et les vols prennent du retard. Cas Air France cité par François Dupuy dans « Sociologie du Changement ».

Du coup, l’introduction du management de projet invite à se poser la question suivante avec les parties prenantes : Pourquoi adhérer à une pratique qui désigne plus sûrement le coupable ? Un plan de projet clair et suivi ne pointe-t-il pas les responsabilités sans ambigüité ? Les coupables ne sont-ils pas sanctionnés ? Alors, résister à l’application du management de projet apparaît comme une stratégie intelligente : un plan de projet obscur et difficile à suivre est dans l'intérêt des acteurs dépourvus de maîtrise de leur environnement. De plus, le flou - et l’extrême précision, à l’effet identique - ouvrent des perspectives de négociation, d’arrangements. 

Il y aurait donc résistance intelligente à l'implantation du management de projet. Alors, que faire ?

Je puis me tromper, mais je suggère ces quatre points :

  1. Clarifier avec les commanditaires ce qu'ils veulent voir changer dans leur environnement. Des projets imprévisibles, des pénalités de retard, des collaborateurs burn-out, une image désastreuse ? Puis examiner avec eux quel management de projet est propre à répondre à ces attentes. Enfin, inviter les commanditaires à communiquer leur vision avec force et clarté aux manageurs, aux experts et aux chefs de projet.
  2. Passer de la formation "Yakafokon du management de projet" à la facilitation d’un groupe managers + experts + chefs de projet, donner aux chefs de projet en formation les moyens de se susciter un commanditaire/sponsor dans l'objectif d'initier un management de projet juste nécessaire. Cette approche part du terrain vers les décisionnaires (bottom-up).
  3. Former les stagiaires au management d’une initiative, c’est à dire d’une idée encore à préciser qui génèrera un projet (ou pas) mais qui transformera l’environnement de façon durable et efficace pour un mieux produire et un mieux-être au travail.
  4. Accompagner chacun selon le Modèle ADKAR®.
    .

En tous cas, c’est dans cet esprit que j’anime les sessions de management de projet qui me sont confiées.

02 juin 2015

GED (gestion électronique des documents) et management du changement

Je me demande si des éditeurs d'applications de gestion électronique des documents (GED), entre autres, n'auraient pas intérêt à proposer une prestation d'accompagnement au changement.
De fait, je rencontre deux collègues d'une entreprise du CAC40 qui évoquent ce projet de GED livrée il y a deux ans mais terriblement sous-utilisée et les objectifs manqués d'économie et d'efficacité.
Peut-être la démarche de management du changement a-t-elle été proposée, mais j'entends que rien n'a été réalisé en accompagnement. En tous cas, le constat est là :
En substance, 50% des personnes utilisent la GED mais encore à 50% des capacités d'icelle, chacun utilise ses propres arborescences pour classer les documents.

Pour la petite histoire, certains habitués des projets PLM (Product Lifecycle Management) parlent du syndrome 20-20-100 : 20% des utilisateurs ciblés utilisent l’outil PLM, 20% des fonctionnalités sont utilisées, 100% du budget du projet est consommé avant la fin...

Les disques virtuels de stockage restent utilisés et donc maintenus, malgré leur désordre tel que nul ne sait vraiment où trouver quoi s'il n'est introduit dans les arcanes.
N'est-ce pas un cas d'école pour le management du changement ?
Ne serait-ce pas dans l'intérêt des éditeurs de faire en sorte que le produit installé à grands frais ne déçoive pas leurs clients dans le court et moyen terme - une non-productivité devenue notoire de leurs produits devrait durcir leurs relations commerciales, non ? 

13 février 2015

Un changement d'outil informatique chez mon loueur de voiture

On loue des voitures depuis un siècle. Les loueurs de voiture utilisent l'informatique depuis des lustres. Ce mardi après-midi, j'entre dans la casemate de mon loueur préféré, ma pré-réservation à la main. 3/4 h plus tard, la responsable d'agence me remet un contrat rédigé de sa blanche main après que l'opérateur ait épuisé ses tentatives et sa patience sur le système. Et vendredi, au retour de la voiture, c'est une impression brute, au format interne à la société de location, qu'elle me tend après 20 minutes de lutte avec le système. Trois jours plus tard, je me connecte au site internet pour récupérer ma facture pour remboursement de note de frais et le système répond : "Nous n'avons pas trouvé de facture". Fiasco.

Que s'est-il passé ?

Les informaticiens centraux ont changé l'application informatique durant le week-end précédent, les deux opérateurs dans la casemate ont été formés la semaine d'avant et pourtant plus rien de fonctionne comme ils l'attendaient, les deux super-utilisateurs de la région sont débordés d'appels et renseignent au compte-goutte. Retour au mode dégradé, papier-stylo.

Qu'en tirer comme enseignement ? Selon la grille ADKAR® :

Conscience du changement ? Dans la casemate, aucun des employés n'a justifié le changement style "ils ont fait ça pour telle raison". Ou bien ils l'ignorent, ou bien ils n'y croient pas.

Désir du changement ? Les employés y gagnent pour l'instant des ennuis - et encore, à l'instant "t", j'étais le seul client. Je ne veux pas imaginer ce que ça a donné lorsque le dernier train du soir a déversé une douzaine de cadres dynamiques en attente de leur voiture de location.

Connaissances ? Les employés compulsent le support de cours qui leur a été remis la semaine précédente et ravivent leurs souvenirs comme ils peuvent.

Capacités ? Ces deux personnes sont à égalité de connaissance et de pratique, pas de super-utilisateur parmi eux ; les lignes téléphoniques des formateurs sont occupées, un seul appel aboutira, celui passé à une autre casemate de la région, là aussi dépourvue de super-utilisateur.

Renforcement ? Les opérateurs me disaient : "Depuis que notre informatique a été concentrée en Angleterre, ils nous font des modifications comme ça sans qu'on sache vraiment pourquoi". Il n'y a donc pas de renforcement ?

Je m'adresserais bien à la société de location de voiture pour débriefer avec elle de cet épisode. Change Management : business d'avenir ?