La gestion du changement pour gestionnaire de projets (partie 2)

Ce billet ci est la suite de celui-là.

L’implication précoce & soutenue des utilisateurs

Il est illusoire de croire qu’on puisse définir le cahier de charges d’un projet en vase clos, en excluant du processus ceux qui sont le plus directement concernés: les utilisateurs. Cela peut sembler l’évidence même mais détrompez-vous: Il n’est pas rare, bien au contraire, de voir une équipe réduite élaborer le cahier de charge sans consulter les utilisateurs. Cela s’explique sans doute par le fait que l’impulsion initial d’un projet ne provient souvent pas des utilisateurs concernés, trop occupés avec les détails opérationnels, mais est souvent le fait des « têtes pensantes » de l’organisation. Entendons par là la haute direction, la direction des départements concernés ou encore le département de marketing, voir celui des ventes. La frénésie qui entoure le lancement d’un projet et l’illusion, souvent contreproductive, que l’avenir de l’organisation dépend d’une livraison accélérée du produit, contribuent à exclure les utilisateurs du processus, eux dont l’implication ne fait souvent que retarder le projet (du moins c’est l’illusion facile). Après tout, qu’apportent-ils de plus à la compréhension des besoins réels de l’organisation?

Dans les faits, les utilisateurs apportent souvent une compréhension plus fine des considérations opérationnelles. Ces considérations sont souvent négligées par les stratèges qui préfère regarder l’ensemble de l’œuvre d’une certaine hauteur (tout à fait appropriée, par ailleurs), perdant ainsi de vue ces détails que les utilisateurs, eux, comprennent.  Or ce sont souvent ces détails qui occasionnent le plus de problèmes lors de l’implantation d’un système, surtout s’ils ont été négligés.

La participation des utilisateurs aux processus de conduite du projet ne s’arrête pas à la compréhension des besoins, mais se doit d’être continue jusqu’à la clôture du projet. Sans vouloir être cynique, et de manière parfaitement compréhensible, des utilisateurs qui se sentent consultés, informés et de manière générale impliqués dans la définition, planification et conduite d’un projet tendent naturellement à être beaucoup plus coopératifs et ouverts au changement qui survient en aval du projet. Après tout, le produit alors livré est entre autre le reflet de leurs propres préoccupations et il serait mal avisé d’opposer à la toute fin une résistance au changement annoncé sans avoir annoncé leur couleur en cours de projet. Et si la couleur est annoncée, elle peut alors être prise compte dans l’exécution du projet.

De manière pratique, l’implication des utilisateurs passe en général par la nomination d’un nombre limité de « super-utilisateurs ». Ceux-ci représentent collectivement les différentes perspectives ou spécialisations des utilisateurs, assurant ainsi que tous les points de vue sont bien considérés.  On choisira en général des individus experts en leur domaine, respectés par leurs pairs, ouvert à participer de manière constructive au projet, sans pour autant attendre de docilité de leur part. Au contraire, il est parfois payant d’enrôler un utilisateur à priori récalcitrant, dans la mesure où il accepte de collaborer de manière constructive. Il n’est pas d’argument de vente plus convaincant auprès des utilisateurs que la profession d’un des leurs ayant été volontaire et sincèrement converti.

Si l’impulsion initiale du projet ne provient pas des utilisateurs eux-mêmes, ceux qui en sont responsable doivent expliquer les objectifs du projet aux utilisateurs en même temps qu’à toutes les autres parties prenantes, dont l’équipe projet elle même. Il arrive parfois dès cette étape que les utilisateurs puissent proposer une ou des alternatives plus simple pour satisfaire aux objectifs. Sinon, le projet poursuit sur sa lancée.

Les supers-utilisateurs auront diverses responsabilités. Ils représenteront leurs pairs à la table du projet et feront valoir les préoccupations de tous les utilisateurs. Afin de bien comprendre ces préoccupations, ils devront non seulement se baser sur leur propre expérience, mais aussi expliquer la teneur du projet à leurs pairs, consulter ces derniers et finalement relayer le sentiment général des utilisateurs à la table du projet afin qu’il en soit tenu compte.

Le mandat des supers-utilisateurs s’échelonnera sur toute la durée du projet et la charge de travail qui leur incombera dépendra de la nature du projet: plus le projet est susceptible d’impacter les processus et procédures d’affaire, plus les supers-utilisateurs devront être impliqués. Sur les gros projets il peut être nécessaire que certains d’entre eux soit complètement détachés de leurs fonctions habituelles pour la durée du projet afin de participer de manière soutenue aux volet analyse d’affaire, communication et tests. Sur les plus petits projets, ils seront appelés à participer à certains ateliers d’analyse d’affaire, à certaines séances d’information, à toutes les démos du produit, ainsi qu’aux séances de tests et formation. Cela pourrait alors représenter de 10% à 90% de leur temps selon les choix que fait l’équipe de direction du projet dans l’organisation de celui ci.

La question du jour:

Vos utilisateurs sont-ils souvent impliqués dès les premières étapes de vos projets? Selon vous? Selon eux? Trouvez-vous que le prix à payer pour impliquer les utilisateurs ainsi que je le propose est trop élevé? 

À suivre dans cette série

1. Introduction: qu’est-ce qu’on vise?
2. Ce numéro
3. Communication et transparence
4. Une bonne analyse d’impacts opérationnels
   
5. Les tests d’acceptation
6. La formation, initiale et continue
7. L’apport d’Agile à la gestion du changement

La gestion du changement pour gestionnaires de projets (partie 1)

Il est un gestionnaire avec des années d’expérience derrière la cravate. Il a livré de nombreux projets. Il était en général responsable du volet technique, c’est à dire de la réalisation du produit ou système. Voilà maintenant qu’on lui demande non plus seulement de développer le produit mais aussi de voir à son implantation. Il croit que déployer et implanter sont synonymes. Pourtant plus d’un an après la date de clôture annoncée il est encore aux prises avec de sérieux problèmes d’adoption qu’il ne s’explique pas…  On lui avait pourtant parlé de « gestion du changement », mais pour lui ça rime avec « gestion des demandes de changement »…  Ouille !

Clarifions d’abord ce qu’est la gestion du changement. La définition qui suit est la mienne, et je résiste à la tentation de vérifier la définition officielle qu’en font les véritables spécialistes en la matière. Car je m’adresse ici d’abord et avant tout à mes collègues gestionnaire de projets.

La gestion du changement consiste à satisfaire au mieux l’ensemble des conditions facilitant l’adoption éventuelle du produit d’un projet. La nature de ces conditions varie de l’une à l’autre mais va en général de l’implication précoce, soutenue et sous diverses formes des utilisateurs, à la formation adéquate de ceux-ci, en passant par une communication continue multidirectionnelle entre utilisateurs, équipe projet et autres parties-prenantes. Cette liste n’est évidemment pas exhaustive.

Notez que je n’inclus pas ici une compréhension empathique et exhaustive des besoins du client car je considère que celle ci relève plutôt de la discipline « analyse d’affaire », laquelle a sa propre catégories d’articles (à venir) sur ce blog.

Sans qu’il soit nécessaire pour un gestionnaire de projet d’être un expert en gestion du changement, il est néanmoins souvent indiqué que celui-ci maitrise et intègre dans sa pratique des éléments clés de gestion du changement, s’il souhaite réellement que le client considère le projet comme un succès, non seulement à court terme, mais surtout à long terme.

Dans cette série de billets, dont le nombre m’est encore inconnu, je choisis d’aborder seulement certaines pratiques élémentaires qui, à mon sens, relèvent de la gestion du changement et que tout gestionnaire de projet  devrait considérer et incorporer dans son art, à défaut d’engager un expert en gestion du changement, un luxe que peu de projet se paient.

Mais d’abord…

Qu’est-ce qu’on vise?

En général, lorsque je suis responsable non seulement du volet développement mais également de l’implantation d’un système, je refuse de conclure au succès du projet à la clôture de celui-ci et ce malgré toute les apparences. Dans un contexte d’implantation, seul le temps constitue un réel test de succès et il me faut en général revenir au client souvent plus d’un an après la conclusion du projet pour savoir si l’implantation perdure et si oui ou non un parle bien d’un succès.

Je n’ai jamais tenté de quantifier le succès d’une implantation, mais en toute modestie je dois admettre que je ne me donnerais jamais la note de 100%. Ce qui me console c’est que je n’ai jamais vu une implantation le moindrement complexe qui soit un succès total. Les variables de l’équation du succès sont simplement trop nombreuses, variées, et pour plusieurs, incontrôlables. Mais je me risque tout de même à vous proposer quelques métriques:

• Le système implanté un an plus tôt fait-il encore partie du décor? Non? Ouch! -100% (à moins que le décor lui-même n’existe plus, et à condition que sa disparition ne soit pas due à l’échec de l’implantation :-))
• En sondant les utilisateurs eux-mêmes, quel est le degré d’enthousiasme par rapport à l’implantation?
  • J’utilise toujours l’expression « adoption enthousiaste » au début d’un projet d’implantation, lorsque j’explique mes objectifs personnels aux utilisateurs. Je ne manque évidemment pas de faire rire de moi, mais tout en sachant que ce but est un peu utopique, il a le mérite de constituer une cible claire.
• Les utilisateurs maitrisent-ils bien les procédures modifiées ou ajoutées dans le cadre de l’implantation.
  • Observe-t-on beaucoup d’erreurs d’utilisation du système? Quelles fonctions semblent le plus problématiques/complexes?
• Observe-t-on beaucoup de tentatives de contournement
  • Quelles fonctions mériteraient d’être mieux adaptées à la réalité du terrain
• Les nouveaux rapports découlant de l’implantation ont-ils amélioré la prise de décision?
  • Ces rapports sont-ils effectivement produits et utilisés par la direction?
  • Ces rapports apportent-ils une information qui n’était pas disponible auparavant?
• L’implantation s’est-elle traduit par un gain de productivité et d’efficacité?
• L’implantation contribue-t-elle de manière positive à la stratégie de l’organisation?

À compléter par le lecteur… Que pensez-vous des critères ci-hauts? Lesquels souhaiteriez-vous ajouter?

Dans la suite de cette série de billets, j’aborderai les aspects suivant de ce que je considère est une gestion élémentaire du changement, des points applicables par tout gestionnaire de projets.

1. Ce numéro.
   
2. L’implication précoce et soutenue des utilisateurs
3. Communication et transparence
4. Une bonne analyse d’impacts opérationnels
   
5. Les tests d’acceptation
6. La formation, initiale et continue
7. L’apport d’Agile à la gestion du changement