La conduite du changement fait partie du travail d’un chef de projet. « Conduite du changement » ? Il s’agit tout au plus d’accompagner tout changement interne à l’entreprise amené par l’utilisation voulue d’un nouveau processus, nouveau produit, ou nouvel outil. On parle également de gestion de la complexité, gestion en milieu incertain (le milieu incertain étant l’humain). Par exemple, le changement se faisait dans les décénnies précédente par un processus en V : on partait d’un besoin, on faisait l’étape de conception, on trouvait une solution complète, on la mettait en oeuvre, puis après moultes phases de vérifications, tests et autres, on l’applicait. C’était trop brusque, et souvent cette brutalité a amené d’énormes pertes financières.

La solution aujourd’hui est souvent appelé « méthode agile » (Wikipedia), de laquelle on peut au moins admettre qu’elle en est inspirée. Le principe : plutôt qu’un long processus, l’idée est d’avancer à petits pas, par petites itérations. Faire des tout petits V, en quelque sorte.

Et surtout, se reposer souvent le problèmes des causes. Il est arrivé souvent qu’à la fin du projet, on ait perdu de vue le but initial du projet, et donc que l’on avance sans trop savoir vers où. Donc trois choses sont à ne jamais oublier : CAUSES, FAITS et OBJECTIFS. La solution peut évoluer, mais les trois éléments pré-cités doivent toujours être vu et revu afin d’éviter de partir dans de mauvaises directions.

De même, il faut bien partir sur des bases saines. Et cela passe par se mettre d’accord sur ce qui est un fait. Ne pas le confondre avec une opinion ou un sentiment (qui pourraient ne pas être partagé par tous, ni être fondé).

1. Une fois le projet de changement proposé, il est fondamental de se reposer la question : « le projet de changement est-il nécessaire ?« . (c’est en quelque sorte le « Pourquoi » du projet).
2. « Le Projet de changement est-il utile ? » (c’est le comment). Ne pas oublier que très souvent, 80% des objectifs peuvent être atteints en éliminant 20% des causes (loi de Pareto).
3. « Le Projet de changement est-il vraiment intéressant ? » (Problème de la mise en place de la solution par rapport aux individus dans l’entreprise. Vont-ils accepter ce changement ?)

Un des problèmes liés à la gestion du changement qui revient souvent est celui de la réticence de certains employés qui voient dans ce changement la perte de leur utilité (et donc une menace pour leur emploi). Un changement développe des craintes, mais celles-ci ne sont jamais mises sur la table, car très souvent elles ne sont pas avouables. Un changement amenant très souvent un changement de pouvoir (au sein même de l’entreprise), celui-ci peu dès lors rencontrer des obstacles inattendus (des employés qui font du zèle dans leur opposition à ce changement). Ne pas perdre de vue d’ailleurs que beaucoup de pouvoirs dans l’entreprise sont détenus de manière officieuse : l’assistant du patron, par exemple, gère l’emploi du temps de celui-ci. Elle a donc un pouvoir non négligeable.

En terme d’informatique, on peut noter que le management classique est basé sur la transmission des informations. Or, les nouveaux SI permettent une révolution de ces hiérarchies, avec des transmissions d’ordre et d’information du haut vers le bas, directement. A ce niveau, le management ne sert donc plus à grand chose. C’est cette idée (pas forcément justifiée, car très simpliste), qui peut amener de leur part une grande réticence à un changement.

Ainsi, et pour finir, pour la gestion d’un changement, rien ne vaut une envie des employés à utiliser un nouvel outil. Ainsi, le mieux est que l’outil soit testé sur un groupe représentatif de personnes, et que celles-ci fasse envie aux autres employés dans l’utilisation de ce logiciel. De cette façon, les employés se l’approprieront volontairement (le changement ne sera alors pas vu comme une contrainte), et se passera d’autant mieux.