Il y a peu nous avons décrit une phase connue sous le nom de la vallée de la mort dans les projets de transformation (article que vous retrouverez ici). Dans cet article nous souhaitons partager avec vous ce que nous avons appris de cette situation en vous partageant quelques signes annonciateurs de cette période.
C’est le propre du projet que d’être incertain et de tomber sur des obstacles auxquels personne ne s’attendait (sinon il faut plutôt parler de procédure). Mais même si un projet connaît toujours des difficultés, certaines doivent vous mettre la puce à l’oreille car elles peuvent avoir d’énormes conséquences sur la suite du projet. Voici quelques uns des écueils à ne pas louper.
Un cadrage mal embarqué…
Surveillez de près l’implication des parties prenantes clés, en particuliers dans les phases de cadrage de la solution. Ces phases permettent d’analyser l’existant et formaliser les principes structurants de la cible. Il s’agit d’y faire prendre des orientations et donc de renoncer (André Gide : « choisir c’est renoncer »). Elles requièrent donc une implication totale des parties prenantes pour identifier tous les impacts des choix qui sont faits et éviter de faire machine arrière en plein milieu de projet.
Ce manque d’implication peut se manifester de plusieurs manières :
- Un manque d’intérêt des intervenants clefs pour le sujet ou un faible enjeu au sein de l’entité auxquelles ils appartiennent. Le symptôme ici, c’est qu’on vous répond toujours oui, sans jamais émettre de doute ou d’opposition.
- Des responsables décisionnaires peu impliqués : soit faute de disponibilité ou par frilosité politique ou managériale. Dans ce cas, on vous répondra : « Ça n’est pas important / Je verrai plus tard », « Il faut que j’en parle à mon chef », « C’est une question intéressante mais je ne peux pas me prononcer sur un arbitrage que je découvre en réunion » (et ce même si vous l’avez vu la veille en réunion de préparation)
- Des contributeurs opérationnels non représentatifs de la population impactée par le projet. Deux cas de figure peuvent se présenter : le chef ou l’expert est représentatif mais trop loin des réalités du terrain ; ou bien le représentant connait bien le terrain de son équipe de 5 personnes mais on lui demande de représenter une direction de 1000 personnes « par extrapolation ».
Attention à une phase de prototypage en trompe-l’œil !
La phase de prototypage permet d’établir les spécifications de la solution et de construire de façon itérative un prototype de la solution. Cette phase requiert également une implication particulière et de la prise de recul pour construire la solution la plus adéquate possible aux réalités et aux pratiques des utilisateurs finaux. Cette phase peut s’avérer être trompeuse lorsque les parties prenantes ne sont pas assez critiques des propositions faites par l’équipe projet. Que ce soit par politesse ou par affinité, on peut facilement déboucher sur une solution tendance mais peu adaptées aux enjeux terrain. Il est important de mettre vos utilisateurs clefs dans des situations concrètes, proche de leur réalité opérationnelle et de leur demander de manipuler eux même le prototype sur des cas réels. Bref de les forcer à mettre les mains dans le cambouis dès la phase de spécifications / prototypage. Sinon on reproduit sous une forme différente le syndrome du pavé de spécifications de 1500 pages que personne ne lira jamais. Là on aura le magnifique prototype que personne n’aura manipulé (à part les consultants) et la réalité va vous rattraper lors de la mise en place d’une phase pilote.
Des timings délicats
« Dans la vie tout est une question de timing », disait Franck Ntasamara. Cela se vérifie aussi dans le choix des jalons d’un projet de transformation. Les grands jalons d’un projet ne doivent pas être choisis au hasard ou en s’appuyant uniquement sur les dates de fin de réalisation des lots. Ils doivent faire l’objet de préparation et d’anticipation. Par exemple, la décision de lancer une expérimentation pilote doit se prendre relativement tôt (par rapport à son lancement) et doit faire l’objet d’une bonne préparation. Par ailleurs, la période de lancement de cette expérimentation est également cruciale. Il faut l’adapter en fonction du contexte de l’entreprise ou de l’entité cible (période de forte/basse activité, congés, vacances, etc.). Par exemple, la période d’été n’est pas propice pour une utilisation optimale d’un outil vu le départ en congés de nombreux agents.
Des surprises inattendues sur les postes de travail
Méfiez-vous de la prétendue uniformité de la configuration des postes des travail et des infrastructures bureautiques. L’utilisateur ne voit le résultat de votre projet que via son poste de travail. Il ne peut donc pas faire de différence entre ce qui relève du poste de travail, du réseau, des serveurs, de l’application, de la base données. L’utilisateur n’a également aucune visibilité sur la répartition des responsabilités entre les différents acteurs / composants du projet. Le responsable c’est le projet. Ces problèmes de poste de travail sont d’autant plus délicats à traiter qu’ils n’apparaissent généralement pas sur les postes et les environnements de développement de l’équipe projet. Cette situation peut rapidement entraîner un rejet de la solution et précipiter la vallée de la mort ou l’accentuer si le projet est déjà dans cette phase. Pour éviter cela, privilégiez toujours fortement les solutions Full Web. Méfiez vous des solutions « soit disant Full Web » mais dont on découvre en creusant le discours commercial, qu’elles peuvent nécessiter un minuscule applicatif client pour traiter tel ou tel cas parfois pas anecdotique du tout… (bref l’éternel problème de “la logistique du dernier kilomètre”).
Des impacts organisationnels plus importants que prévus
La mise en place de certaines offres de services impacte fortement les habitudes de travail et les pratiques quotidiennes. L’ergonomie de l’outil et de ses fonctionnalités est donc importante pour faciliter les changements de pratiques.
D’autre part, une offre de service a beau être large et complète, elle ne peut pas tout faire (ou pas tout bien faire). Il est important de rappeler avant le lancement de la solution ce qu’elle fait et ne fait pas. Si certains usages historiques ne sont plus possibles, il faut l’indiquer et indiquer le contournement associé. C’est toujours pareil : on patiente plus facilement quand on sait combien de minutes de retard a le train.
Par ailleurs, ces offres de services impliquent également une évolution des rôles, responsabilités et missions des différents acteurs. L’organisation doit y être préparée. Cette préparation passe par une définition claire et une communication efficiente sur ces nouveaux rôles et responsabilités. A ce stade, un important travail de conduite du changement doit être mené pour éviter un rejet pur et simple de la solution.
Conclusion
On le sait, la vallée de la mort est une période qui existe dans tous les projets de transformation. Elle peut être plus ou moins importante en fonction du contexte du projet. Même si elle est inévitable, son intensité peut diminuer si vous vous êtes préparés avec minutie en guettant les signes annonciateurs.
