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 ?


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à.