L’implémentation dans un projet : pour quoi faire ?

L’implémentation, c’est ce qui permet à une installation, plein succès technique, de contribuer au succès business du projet et à son succès humain. Pourquoi s’en préoccuper ? Voyons cela de plus près, en utilisant l’approche des 5 « pourquoi ». En descendant l’arbre des causes jusqu’aux racines, découvrons les freins au succès business d’un projet et les réponses qu’apporte le Modèle ADKAR^®.

Une histoire d’implémentation pour commencer

Chez cet équipementier automobile, l’implémentation d’un PLM (Product Lifecycle Management) avait pour objectifs d’accélérer le passage à la production, de diminuer les coûts de conception et d’augmenter la marge de l’entreprise en diminuant les occasions d’erreurs et les pénalités qui vont avec.

Problème : 5 ans après l’installation du PLM et sa mise à disposition des équipes, les résultats sont loin des espérances. Pourquoi ? parce que 6 personnes sur 7 continuent d’utiliser Excel ; seulement 1 personne sur 7 utilise le PLM.

Ah! ne serait-ce pas du fait que le PLM installé il y a 5 ans est trop lourd, trop lent, trop… ? Qu’à cela ne tienne, pour atteindre les objectifs business ci-dessus, développons et installons un PLM de dernière génération !

Pertinent ? Suffisant ? possible, en effet. Pourtant, avons-nous fait le tour des causes profondes de l’échec de l’implémentation du PLM il y a 5 ans – car il faut bien appeler cela un échec – afin de mieux implémenter la version miracle promise par l’éditeur ?

Une installation sans impact sur aucun utilisateur ?

D’habitude, les projets définissent des problèmes, conçoivent des solutions, développent des outils et les installent, les mettant à disposition des utilisateurs, c’est à dire de « ceux qui font ». Pourquoi toute cette énergie (et ces coûts) ? Pour un mieux-être de l’Organisation : moins de coûts, ou plus de revenus, ou les deux. C’est l’arithmétique originelle : profit = revenus – coûts.

L’idée même d' »initiative business » est d' »obtenir tel résultat business en réalisant tel projet »

D’un côté, l’installation (d’un produit, d’une application, d’un processus, d’un outil, etc.) est du ressort du projet, lequel a des objectifs techniques que les chefs de projet résument en cette lapidaire formule : good, fast and cheap ! D’un autre côté, l’implémentation permet à l’installation de déboucher sur un succès business et sur un succès humain. Je tiens cette dichotomie installation-implémentation de l’approche AIM Accelerating Implementation Methodology.

Or, l’utilisateur, qu’en fait-il, de l’outil mis à sa disposition ? Les objectifs business du projet peuvent-ils être atteints si l’utilisateur, finalement, utilise peu, ou mollement, et lentement, ce que le projet a mis à sa disposition ? On a vu que, dans l’exemple ci-dessus, le produit PLM fonctionne. Mais, faute d’utilisation effective, son installation n’a pas permis de réduire les temps, d’augmenter les marges, etc.

Un cas particulier peut se présenter : l’outil na pas changé, ou que le changement que le projet apporte est transparent pour son utilisateur. Dans ce cas, l’implémentation se confond avec l’information : « Nous avons fait quelque chose pour vous, sans impact sur vous ». En clin d’oeil aux temps anciens : « dormez, braves gens ».

Mais quid des projets qui, en vue d’atteindre les objectifs business, consistent à mettre des outils, processus, techniques et autres à disposition d’utilisateurs ? Qu’en est-il, si ces derniers doivent, en les utilisant, changer quelque chose à leurs habitudes ? Changements d’habitudes sans lesquels les objectifs ne seront pas atteints !

Donc, il y a bien deux impacts distincts : l’impact du projet sur les personnes, et l’impact des personnes sur l’atteinte des objectifs business. Pour vous aider dans cette dialectique, découvrez la fiche Projet-Objectifs-Particularités-Personnes.

L’implémentation au crible des 5 « pourquoi » (et bien plus)

Admettons que l’installation se passe à merveille, que l’équipe projet ait formé les utilisateurs-clés, à charge pour ces derniers de former leurs collègues. Sera-ce suffisant ?

Pour l’exercice, je propose de revenir au constat du projet PLM en exergue. Nous faisons le bilan 9 mois après l’installation du PLM. Malgré l’importance de l’investissement, malgré les efforts de formation consentis par l’équipe d’installation, le sponsor constate que les objectifs du PLM n’ont pas été atteints. Pourquoi ?

Je vous propose une enquête rétro-active, en remontant le temps et l’arbre des causes. Alors, oui, de fait, les étapes chronologiques, celles du Modèle ADKAR^® en particulier, apparaîtront à rebours : d’abord la dernière, puis la précédente, et ainsi de suite jusqu’à la première.  Suivez le guide !

Clarifier les indicateurs.

Constat #1. Si, les progrès sont réels, les objectifs sont bien atteints ! Ce qui manque, ce sont les chiffres pour le montrer. Les indicateurs n’opèrent pas. Pourquoi ?

C’est que, l’installation passée,  les indicateurs n’ont pas été relevés au cours du temps. Pourquoi ?

Parce que les superviseurs ignorent les indicateurs qu’ils doivent relever chaque jour, semaine, mois. Pourquoi ?

C’est du fait que les indicateurs n’ont pas été définis au départ, ni intégrés aux communications et aux formations.

Moralité : définir les indicateurs du succès dès l’amont, proposer des kits aux superviseurs et, de la part du sponsor, exiger leur reporting hebdomadaire, mensuel, trimestriel.

Aider le sponsor à renforcer l’adhésion des utilisateurs.

Constat #2. Après un engouement réels, les utilisateurs ont abandonné le nouvel outil et sont retournés à leurs usages antérieurs. Ils n’adhèrent plus. Pourquoi ?

Eh bien, les utilisateurs concernés, questionnés, ignorent à quoi leurs efforts ont servi. Alors, l’outil précédent était bien pratique, n’est-ce pas, et son utilisation bien maîtrisée, et les utilisateurs ont repris leurs habitudes d’avant l’installation.

Moralité : obtenir du sponsor qu’il prenne la parole pour un message de renforcement. Après tout, c’est lui qui a lancé le projet, le préférant à d’autres. M’inspirant des basiques de la communication de couple (sic), je suggère ceci :

• Bravo : vous avez atteint ces objectifs ambitieux !
• Merci : je salue vos efforts, notre Unité Business vous doit beaucoup.
• Pardon : tout ne s’est pas aussi bien passé que nous l’aurions voulu, mais nous avons appris et nous sommes d’ores et déjà meilleurs.
• S’il vous plaît : poursuivez sans mollir sur le chemin du progrès, il reste beaucoup à faire.

C’est l’objet de l’étape Reinforcement (renforcement) du Modèle ADKAR^®.

Soutenir les utilisateurs et les aider à régler les problèmes.

Constat #3. Sortis de formation, les utilisateurs ont rencontré des difficultés :

• ça ne fait pas ce que ça devrait et ça fait ce que ça ne devrait pas.
• le système induit des conséquences cachées qu’il faut résoudre.
• nous pensons à des cas nouveaux qu’on aimerait bien que ça traite, désormais.

Ils se sont tournés vers leurs superviseurs, vers les utilisateurs-clés, vers le centre d’appel et le support niveau 2, en vain. Ils n’ont pas trouvé comment régler les problèmes du quotidien. Pourquoi ?

En fait, désillusions et découragement ont sapé le moral des troupes :

• les superviseurs ne s’attendaient pas à tenir ce rôle de soutien précis, d’écoute éclairée,
• les utilisateurs-clés ont été phagocytés par un projet nouveau,
• le centre d’appel ne disposait d’aucune base de connaissance (« knowledge base »),
• et le support niveau 2 apportait leur expertise ce qui doit fonctionner, pas sur le reste.

Moralité : accompagner toute l’Organisation dans l’écoute active du terrain, le coaching des utilisateurs, la prise en compte rapide du retour d’expérience de chacun.

C’est l’étape Ability (habileté, savoir-faire) dans le Modèle ADKAR^®.

Mettre en place le dispositif humain et technique adéquat : oui, c’est une dépense post-installation. Pour cette raison, l’équipe projet n’y a peut-être pas pensé. Ou plutôt, si, l’équipe projet y a pensé, comme condition du succès, mais hors budget projet. Elle l’a mise dans les mains de la « maîtrise d’ouvrage », côté business, donc, sous le paragraphe « implémentation ». Bien vu.

Former les utilisateurs et, auparavant, leurs superviseurs.

Constat #4. Il s’avère qu’en dépit des efforts de l’équipe projet, certains utilisateurs (combien ?) sont passés à travers les mailles du filet de la formation. Pourquoi ?

Une première raison est celle-ci : les superviseurs de ces personnes ne leur ont pas donné leur aval pour quitter un moment leur poste en vue de la formation. Pourquoi ? Hélas, ces superviseurs eux-mêmes n’ont pas reçu l’information de leur propre manageur, ou toute autre embolie du système de communication… Si nous les écoutions, ces superviseurs nous diraient en substance : je n’ai pas compris ce qu’on y gagne en tant qu’équipe, ni ce que j’y gagne en tant que manageur – alors, votre formation ne pèse pas lourd face à une urgence client à traiter, un problème production à résoudre, etc.

Moralité : les superviseurs sont des collaborateurs comme les autres. Eux aussi ont besoin de comprendre ce qui est attendu d’eux, ce qu’ils y gagnent. Avec cette particularité : ils ont horreur d’en savoir moins que leurs collaborateurs, ou de l’apprendre après eux… Avant la formation, la communication descend la ligne hiérarchique, elle donne un coup d’avance aux superviseurs. Ainsi de la formation : les superviseurs sont nos premiers participants.

Ceci est un des aspects de l’étape Knowledge (connaissance) du Modèle ADKAR^®.

Organiser les conversations utilisateur-superviseur.

Constat #5. Qu’ils soient ou non participé aux sessions de formation, les entretiens avec les utilisateurs concluent que ces derniers restent bloqués sur leurs pratiques d’avant. Pourquoi ?

Interrogés sur leur perception de ce qui change pour eux, les utilisateurs manifestent qu’ils ne sont pas alignés avec leur superviseur : prudents, ils en restent à ce qui a fonctionné jusqu’à présent. Pourquoi ?

Justement, leurs nouvelles responsabilités, leurs nouvelles activités, ce qu’ils y gagnent… les utilisateurs n’ont partagé avec rien de tout cela avec leur hiérarchie. Pourquoi ?

Il s’avère que, si les conversations manageur-managé sur le sujet du changement en cours n’ont pas eu lieu au niveau des utilisateurs, c’est qu’elles n’ont pas eu lieu non plus plus haut dans l’organigramme… Chaque niveau hiérarchique est peuplé de personnes prudentes : si ce que j’ai à faire n’est pas clair, pourquoi risquerais-je un clash avec mon manageur en sortant des sentiers battus (qui ne nous ont pas si mal réussi jusqu’à présent, n’est-ce pas ?).

Moralité : comme pour le point de la formation, il nous revient d’organiser les conversations manageur-managé en mode descendant, top-down, de sorte que les manageurs aient toujours un temps d’avance sur leurs collaborateurs. Et comme chacun a son rythme d’adhésion à ce qui change dans son environnement, ce sont des conversations personnelles, personne à personne, que nous suscitons.

Il s’agit de l’étape Desire (envie de changer) du Modèle ADKAR^®.

Accompagner le sponsor dans l’explication publique du « pourquoi ».

Constat #6. Les utilisateurs ne comprennent pas pourquoi il faut faire différemment maintenant.

Certains, bien que briefés, formés, accompagnés et renforcés, trainent la patte sur le chemin de la nouveauté. Où achoppent-ils ?

Allant à leur rencontre, nous entendons qu’ils ne comprennent pas pourquoi on change ce qui a si bien réussi jusqu’alors – et que d’autres continuent à faire sur la place. Ils ne sont pas convaincus. Pourquoi ?

Il se peut que le message n’ait pas été clair.

Se pourrait-il que celui qui a pris la parole à ce sujet ait été clair, mais pas crédible ?

Moralité : nous prenons soin d’accompagner le sponsor de l’initiative business afin que ce soit lui qui prenne la parole, en personne, et explique pourquoi il lance le projet. Car c’est lui que tous considèrent comme légitime à dire où nous allons tous.

Il s’agit de l’étape Awareness (prise de conscience) du Modèle ADKAR^®.

Le Modèle ADKAR^® nous aide à manager l’implémentation.

Le Modèle ADKAR^® nous invite à des conversations selon une chronologie orientée hiérarchie, mais pas pour autant toujours descendante. Au contraire ! les échanges descendent et remontent les lignes hiérarchiques ! Voir ici le schéma des conversations.

Nous autres, responsables d’implémentation, entretenons des liens étroits avec l’équipe projet. Voir ici une séquence possible d’interaction et de coordination entre ces deux genres d’acteurs.

Pour aller plus loin

Le Change Management, ça fonctionne.

ADKAR^® et les termes « Awareness Desire Knowledge Ability Reinforcement » sont des modèles déposés de Prosci, Inc., Loveland/Fort Collins, Colorado, USA. Le Modèle ADKAR^® est utilisé avec la permission de Prosci, Inc.