Business Analysts: comment gérez-vous les réorganisations de vos contributeurs?

Aujourd’hui, je voudrais partager avec vous l’une de mes réflexions concernant l’impact de réorganisations internes sur les contributeurs d’un projet: les risques sont majeurs, et je vais vous expliquer pourquoi dans cet article.

Pour vous situer le contexte, je travaillais sur un gros projet de transformation, impliquant des centaines de collaborateurs transnationaux, la redéfinition de leurs processus métier, ainsi que la digitalisation des outils de travail, et la redéfinition en profondeur des équipes (nouveaux rôles et responsabilités, changement des périmètres professionnels, des lieux de travail, des collègues etc).

Pour mener à bien la phase d’élicitation, c’est-à-dire le recueil d’une information exhaustive, fiable et vérifiée, et réfléchir à la redéfinition des processus-cibles, j’étais épaulée par de nombreux contributeurs métiers. Ceux-ci étaient des collaborateurs sélectionnés au début du projet pour leur niveau d’expertise élevé et leur rattachement organisationnel et géographique – il fallait en effet faire intervenir des représentants de toutes les équipes touchées par le besoin de changement.

Comme pour tout projet d’envergure, celui-ci était découpé en work packages, chacun travaillant sur un périmètre dédié, qui sur les processus métiers, qui sur la digitalisation des outils informatiques, qui sur l’organisation des rôles et compétences, qui encore sur le pilotage et le suivi de la performance.

La difficulté sur ce genre de projets complexes est, entre autres, de faciliter la communication entre work packages, de manière à éviter le travail dit « en silo ». Si on veut faire une analogie avec un projet informatique, la bonne communication entre work packages correspond à l’instant de vérité de la phase d’intégration. Quand bien même chaque module, chaque composant logiciel aura été développé parfaitement, quand bien même les tests unitaires se seront déroulés avec succès, si les interfaces ne savent pas communiquer entre elles ou que cela génère trop d’erreurs, le projet sera tenu en échec.

Sur ce projet, côté communication, je devais fournir pas mal d’énergie à me tenir au courant des modifications des jalons du projet, et des évènements clés qui pourraient impacter mon périmètre. J’avais intégré cela comme une contrainte, à savoir que je devais aller chercher l’information plutôt que d’attendre qu’elle ne vienne spontanément à moi (l’importance de la communication dans un projet n’est toutefois pas l’objet de cet article).

Sachant cela, lorsque j’ai appris par hasard que l’ensemble des collaborateurs étaient conviés à un « Change management day », je suis allée à la pêche aux informations pour me procurer les présentations Powerpoint diffusées aux équipes métier.

Cette grand’ messe était particulièrement importante pour les collaborateurs, car c’était la présentation officielle de la réorganisation, et donc de la nouvelle place de chacun dans l’organigramme.

Lorsque j’ai indiqué à mon client que j’aurais bien aimé être tenue informée des détails de la réorganisation, celui-ci m’a répondu, étonné et de toute bonne foi, qu’il ne voyait pas en quoi cela pouvait impacter mon travail (la redéfinition des processus métier).

Les liens entre réorganisation et qualité de l’élicitation et de la définition de la solution cible me paraissaient pourtant évidents… mais force était de constater que cette connaissance était due à mon expertise de Business Analyst. Mon client, peu au courant des tenants et contraintes de ce métier, n’avait pas perçu à quel point ce manque de communication pouvait plomber la définition de la solution cible.

Pour réussir à recueillir des informations exhaustives, fiables et vérifiées, il existe de nombreuses techniques. Une fois que vous avez une idée claire de la situation existante, vous pouvez en évaluer les limites, les inconvénients, les points positifs, et réfléchir à ce qu’il est possible d’améliorer.

C’est ainsi que se dessinent progressivement les contours d’une solution cible, que ce soit une solution informatique ou un changement organisationnel, ou encore la redéfinition de processus métier.

Dans le cas de mon projet, les contributeurs que je sollicitais “brainstormaient” par session de 2 heures. Ils étaient impliqués car ils savaient que ce qu’ils redéfinissaient ensemble, ils allaient devoir l’appliquer dans leur quotidien professionnel.

Quand on sélectionne les contributeurs d’un projet, une bonne pratique est de s’assurer qu’ils se sentent responsabilisés par le changement qu’ils redéfinissent. En d’autres termes, ce ne seront pas d’autres collègues qui auront à travailler avec les nouveaux processus et procédures, mais eux-mêmes. Mieux vaut dans ce cas bien réfléchir pour ne pas en payer le prix plus tard!

La réorganisation qui venait d’être annoncée rebattait les cartes :

• Certains des contributeurs changeaient de périmètre et n’auraient plus à appliquer les nouveaux processus.
• D’autres auraient à les appliquer mais sur d’autres produits, qu’ils ne connaissaient pas encore bien.
• Enfin, certains collaborateurs rejoindraient l’équipe concernée par la redéfinition des processus, mais n’étaient pas contributeurs.

Est-ce que vous percevez le changement de dynamique ?

• Pour les premiers, ils n’auront pas à utiliser la solution cible, et en raison de la réorganisation, ils doivent être rapidement opérationnels. A votre avis, sur quoi ces collaborateurs vont-ils désormais focaliser leur attention ? La prise en main de leur nouveau poste ou la redéfinition de processus qui ne les concernent plus directement ?
• Pour les seconds, la méconnaissance des nouveaux produits qu’ils vont devoir gérer est un frein à leur apport en tant que contributeur. Pourquoi ? Parce qu’ils ne savent pas si ces nouveaux processus en cours de définition sont également applicables à leur périmètre élargi. Or, quand on ne sait pas, on ne prend en général pas la responsabilité de valider de nouvelles solutions.
• Enfin, la troisième catégorie peut, a priori, ne pas sembler être une contrainte majeure. En effet, ces nouveaux collaborateurs (plus exactement, des collaborateurs déjà en poste, mais à d’autres responsabilités) pourraient tout-à-fait prendre acte des nouveaux processus et les appliquer en l’état. Oui, mais. Mais ce sont peut-être des collaborateurs expérimentés, qui ont une expertise sur des processus en amont ou en aval de ceux redéfinis. N’ayant pas participé aux avancées progressives du groupe de travail initial, il leur faudra du temps et un accompagnement au changement pour abandonner leurs biais liés à leurs anciennes habitudes. A moins qu’ils aient d’autant plus de mal à accepter la réorganisation qu’ils ne se seront pas sentis reconnus dans leur expertises (pourquoi ne sont-ils pas inclus dans le groupe de travail, eux?). Quoi qu’il en soit, ces collaborateurs font désormais partie de la dynamique du projet, à court, moyen ou long terme.

Ce que je veux vous montrer, c’est qu’une réorganisation ayant lieu en cours de projet a toujours des implications humaines et émotionnelles fortes, qui vont bien au-delà de l’expertise métier apportée par les contributeurs.

Les ignorer, c’est mettre un gant sur une blessure à la main, en se disant que puisqu’on ne la voit plus, elle n’existe plus.

Dans un projet, la qualité de l’élicitation et de la définition de la solution cible dépendent largement des contributeurs et rien n’empêche de faire évoluer les groupes de travail si la situation change.

Aussi prenez le temps, en tant que Business Analyst, mais également en tant que chef de projet ou responsable de service, de réfléchir aux impacts projets et aux risques résultant d’une réorganisation.