Dans quelle mesure les personnes réagissent-elles avec agilité aux changements ?

Le point de départ de cet article est un grand projet de développement et d'introduction d'un nouveau logiciel SAP pour plus de mille utilisateurs dans une grande entreprise internationale.

Pour ce faire, certaines fonctionnalités essentielles pour le client ont dû être entièrement développées en plus des fonctionnalités standard déjà présentes dans le système, et les processus existants ont d'abord été analysés et en partie optimisés.

Les méthodes agiles sont sur toutes les lèvres et sont souvent présentées comme le "sauveur" de toutes sortes de problèmes connus dans les projets de développement de logiciels d'autrefois. L'approche relativement rigide et linéaire de la méthodologie (de projet) classique en cascade, qui consistait à passer de l'analyse des besoins à la définition de la solution, puis à la phase de développement et de test, souvent longue, en vue d'obtenir un résultat final entièrement défini dès le début du projet, comportait de nombreux risques de ne pas atteindre le résultat souhaité au final.

Trop d'imprévus pouvaient survenir pendant la longue durée du projet : Les exigences ne pouvaient pas être entièrement définies dans les moindres détails au début, les parties prenantes changeaient pendant la durée du projet, les technologies étaient déjà obsolètes à la fin du projet ou les exigences initiales avaient tout simplement changé pendant une longue phase de développement ou étaient soudainement devenues obsolètes.

L'approche itérative des méthodes de projet et de développement agiles promet une flexibilité et une sécurité nettement plus grandes pour pouvoir réagir aux changements qui surviennent.

Des cycles de développement courts, généralement d'une à deux semaines, permettent de définir et de livrer des paquets de développement gérables et moins complexes pour les "sprints" et de pouvoir réagir de manière flexible à l'évolution des exigences lors des revues de sprint récurrentes avec les donneurs d'ordre qui s'ensuivent.

On a presque l'impression que tout projet (de développement) organisé de manière agile devrait logiquement et automatiquement être un succès. Malheureusement, ce n'est pas le cas.

L'achèvement réussi des travaux de développement ne définit pas la réussite d'un grand projet de développement de logiciels. Le logiciel peut avoir été entièrement redéveloppé, adapté ou étendu en conséquence, aussi bien et de manière aussi ciblée que possible, pour aboutir à un résultat final fonctionnel, et les exigences des donneurs d'ordre peuvent également être pleinement satisfaites :

Le véritable succès du projet n'est atteint que lorsque le nouveau logiciel a été déployé avec succès dans l'entreprise et qu'il est accepté et utilisé par une grande masse d'utilisateurs.

L'introduction d'un nouveau logiciel s'accompagne généralement de l'introduction de processus nouveaux ou modifiés. Les processus qui sont vécus par des personnes ne peuvent toutefois pas être introduits ou modifiés de manière "agile", car les personnes sont toujours soumises à des vitesses de changement différentes.

Aucune méthode de projet ou de développement, aussi agile soit-elle, ne peut y remédier. Si le "facteur humain" n'est pas perçu et pris au sérieux à temps, même le projet logiciel le plus agile se soldera, dans le meilleur des cas, par un super logiciel qui plaira certes au donneur d'ordre et peut-être à quelques parties prenantes, mais qui ne sera pas du tout utilisé par la grande masse des utilisateurs ou seulement de manière inefficace.

L'expérience montre que le risque de réussite augmente avec la taille du groupe d'utilisateurs (ou de l'entreprise), car il arrive souvent qu'aucun groupe représentatif des utilisateurs finaux n'ait été impliqué dans les sessions de feedback des différents cycles de développement.

D'une part, dans la composition des parties prenantes, en particulier celles qui sont chargées des revues de sprint, on a tendance à choisir des collaborateurs déjà engagés et plutôt enclins au changement.

En outre, il s'agit tout simplement d'un problème de masse : avec plus de 1000 utilisateurs finaux concernés et éventuellement plusieurs processus concernés, il est très probable que le petit groupe de base auprès duquel un feedback est activement demandé pendant la phase de sprint ne soit tout simplement pas représentatif.

Que faire alors pour mener au mieux un projet de développement de logiciel avec un grand nombre d'utilisateurs concernés sur la voie du succès ?
De notre point de vue, il s'agit de combiner les avantages des méthodes modernes et agiles avec ceux des méthodes classiques de gestion de projet et de développement organisationnel : développer de manière agile, déployer de manière classique.

Dans le projet d'introduction de logiciel à la base de cet article, avec plus d'un millier d'utilisateurs concernés, on a eu recours à la procédure de projet Sirius, qui a fait ses preuves et qui combine les avantages de la méthodologie agile Scrum avec les procédures classiques de gestion de projet et la gestion des changements organisationnels.

Il s'agit de mettre en place le plus tôt possible plusieurs canaux de communication et d'interaction avec le plus grand nombre possible d'utilisateurs finaux (potentiellement tous).

Nous estimons que l'intégration de quelques "utilisateurs clés" sélectionnés ne suffit pas pour obtenir l'acceptation du nouveau logiciel à introduire et, le cas échéant, des changements de processus à venir. Il faut au contraire investir beaucoup plus - et ce dès le début du projet - dans les thèmes complexes de la communication et de la gestion du changement, qui sont souvent laissés de côté par manque de temps, d'argent et de ressources.

Il n'y a jamais trop d'informations et de transparence sur les changements à venir - seulement trop peu !

Phases de la méthodologie de projet Sirius

Concrètement, il s'est à nouveau avéré utile, dans le cadre du présent projet, d'accorder une attention toute particulière aux points suivants lors des différentes phases du projet :

Scoping

• Prenez le temps de définir la portée du projet de manière claire et précise ! Soyez très précis et concret. En fait, cela va de soi. Mais écrivez aussi explicitement ce que vous n'avez PAS dans la portée.
• Formulez les objectifs et les NON objectifs du projet - en plus de la portée du projet.
• Assurez-vous d'avoir convenu du champ d'application et des objectifs avec toutes les parties prenantes importantes.
• Communiquez la portée et les objectifs à chaque occasion. Introduisez chaque atelier par une courte diapositive expliquant une nouvelle fois ce qui est dans le champ d'application du projet et ce qui ne l'est pas.

Phase de conception

• Veillez à ce qu'un échantillon représentatif d'utilisateurs soit impliqué dans la phase de conception : les utilisateurs clés impliqués dans l'équipe centrale du projet ne sont généralement pas suffisants pour que tous les groupes d'utilisateurs soient suffisamment pris en compte lors de la conception. Pensez aussi explicitement aux équipes et aux utilisateurs d'autres régions - ceux-ci travaillent éventuellement différemment des experts affectés au projet et ont donc aussi d'autres exigences !
• Il est préférable d'organiser quelques ateliers de conception de plus plutôt qu'un de moins : il ne s'agit pas seulement de définir les exigences nécessaires pour le logiciel - les ateliers servent aussi de moyen de communication pour transmettre le projet et ses objectifs aux utilisateurs (clés).
• Intégrez activement et explicitement les utilisateurs très critiques : lors de la constitution des équipes de projet et des participants aux ateliers, on évite volontiers les collaborateurs considérés comme "difficiles". Il faut du temps et des efforts pour aller chercher les collaborateurs qui posent problème, mais vous serez de toute façon confronté à leurs objections au plus tard lors du déploiement. Mais à ce stade précoce, vous avez encore la possibilité de réagir activement et de modérer les objections.
• Pensez au comité d'entreprise. Ne le voyez pas comme un obstacle, mais comme une chance de gagner des points supplémentaires pour faire accepter votre projet.

Sprints de développement

Utilisez les revues de sprint pour ce à quoi elles sont destinées : Mettez le développement (partiel) livré à l'épreuve des attentes des utilisateurs vis-à-vis de la fonction livrée.

Ne réduisez donc pas le groupe de participants aux sessions de révision et n'intégrez pas uniquement les utilisateurs clés, mais invitez d'autres utilisateurs à participer aux sessions. Documentez la session de révision.

Dans ce projet, chaque revue de sprint a été réalisée et enregistrée sous forme de session web internationale. Vous donnez ainsi aux parties prenantes d'autres régions du monde la possibilité de voir la revue après coup. C'est nettement mieux que d'envoyer "seulement" un jeu de diapositives et un compte rendu.

Testez la (sous-)fonction livrée directement lors d'une phase de revue après la revue de sprint avec un groupe de test défini. Lors d'une réunion de revue de sprint, aussi longue soit-elle, vous ne remarquerez tout simplement pas tous les points.

Ce n'est qu'en "testant" le composant logiciel livré avec plusieurs utilisateurs que vous remarquerez les erreurs, les défauts de conception et les faiblesses conceptuelles.

Tests de processus et d'intégration

Testez le plus tôt possible une exécution complète du processus. Dès que la somme des développements partiels livrés à partir des sprints permet de tester un processus complet, testez-le également - à nouveau avec plusieurs utilisateurs. Ce qui a bien fonctionné dans les différents tests de sprint isolés ne doit pas automatiquement bien fonctionner dans le cycle de processus complet.

Étendez le groupe de testeurs pour les tests d'intégration et UAT finaux. Faites tester ici aussi les utilisateurs qui n'ont pas participé aux tests de sprint. On constate régulièrement que les utilisateurs qui ont participé à toutes les revues de sprint ne jugent plus le logiciel dans son ensemble de manière impartiale vers la fin.

Roll0ut

Pour le roll0out du nouveau logiciel, utilisez tous les médias modernes disponibles dans votre concept de formation. Outre le manuel obligatoire, créez des versions abrégées pour les fonctions essentielles dont les utilisateurs ont besoin dans leur travail quotidien typique.

Réalisez de courtes vidéos de tutoriel pour les fonctionnalités les plus importantes. Celles-ci n'ont pas besoin d'être produites à grands frais - au contraire, le fait que des "collaborateurs pour les collaborateurs" discutent de ces vidéos favorise l'acceptation.

Utilisez un point de collecte central pour toutes les informations relatives à votre projet - y compris les supports de formation, les FAQ, les tutoriels, les sessions web, les actualités, etc. Communiquez cette page, par exemple sur l'intranet, encore et encore pendant toute la durée du projet. Incluez le lien vers cette page dans tout matériel publié par votre projet.

Pour les formations, tenez compte des fuseaux horaires des collaborateurs dans les autres lieux. On a toujours tendance à oublier qu'une session web à une heure confortable pour nous en Allemagne se transforme en événement nocturne pour des collègues en Asie ou aux États-Unis.

Cela augmente nettement l'acceptation de votre projet si vous tenez activement compte de cette situation et si vous prévoyez explicitement des formations et des sessions d'information, même à des heures confortables pour les utilisateurs vivant à l'étranger.

Communication d'accompagnement, marketing & gestion du changement organisationnel : les activités de ce bloc sont toujours négligées, car aux yeux de beaucoup, elles ne sont qu'un poids inutile et un facteur de coûts. Or, c'est exactement le contraire !

C'est là que se décide si le projet sera finalement couronné de succès ou non :

Informez l'organisation du projet et de ses objectifs. Répétez cela régulièrement et rendez compte des progrès réalisés. Utilisez pour cela, surtout dans les grandes entreprises, tous les moyens à votre disposition.

Plus il y a de transparence, plus c'est facile pendant le déploiement. Dans le cas concret, outre des newsletters régulières, de courtes sessions d'information sur le projet ont été organisées chaque mois - pour tous les utilisateurs potentiellement concernés.

Tout le monde a pu participer. Les sessions ont continué à être enregistrées afin de permettre à tous les utilisateurs de les voir.

De plus, de grandes "fiches d'information" ont été affichées dans les locaux des équipes des différents sites, présentant de manière concise sur une page toutes les informations importantes concernant le projet. En outre, l'équipe du projet a rendu visite à de nombreuses équipes lors de leurs réunions d'équipe pour leur présenter le projet.

En ce qui concerne la communication, on ne peut que dire : Il n'y en a jamais trop ! Parlez autant et aussi souvent que possible de votre projet et des objectifs qu'il poursuit - commencez à le faire dès le lancement du projet.

Pensez au processus de changement par lequel chaque collaborateur doit et va passer. Essayez de lui fournir des informations aussi transparentes que possible.

Conclusion

Les méthodes agiles dans les projets de développement ont rendu beaucoup plus facile l'obtention du résultat final souhaité de manière ciblée. Cependant, l'achèvement du logiciel à la date limite X ne signifie pas automatiquement que le projet est un succès.

Ce n'est que lorsque les utilisateurs acceptent le nouveau logiciel et, dans l'idéal, le perçoivent même comme un soutien dans leur travail quotidien, que l'ensemble du projet peut être considéré comme une réussite - c'est en tout cas la conception du projet de Sirius.

Dès qu'il s'agit de personnes et de leur approche individuelle du changement, les méthodes agiles n'apportent qu'une aide limitée. Les personnes ne sont que partiellement "agiles" en ce qui concerne le changement.

Les méthodes de projet classiques offrent heureusement toujours des concepts pertinents et corrects dans ce domaine - il suffit de les appliquer sérieusement. Avec la bonne combinaison des bonnes méthodes pour le bon objectif, le prochain projet sera à nouveau un succès.