les signatures manuelles sont dépassées ! Ou peut-être pas ?

En lisant l’article de Tim Ingram-Smith sur PMHUT, j’ai essayé de comparer son vécu avec ses clients externes à mon expérience en informatique interne en entreprise. En fait, je dois reconnaître que notre position de collègues-à-collègues entre informaticiens de l’entreprise et utilisateurs business en lieu et place d’une relation client-fournisseur entre deux entreprises change quelque peu la donne, mais pas autant que l’on pourrait le penser de prime abord.

l'importance des signatures manuelles sur les projets

Les projets les plus réussis sur lesquels j’ai travaillé avaient des objectifs très clairs, documentés par écrit et un engagement fort du management, ou bien une très forte proximité développement-utilisateurs pour les développements en mode prototypage ou incrémental (avant que la terminologie « Agile » soit si largement utilisée). Ce fut par exemple le cas lors de l’implémentation d’un progiciel de gestion intégré (Enterprise Resource Planning – ERP) au niveau mondial en 18 mois dans une grande multinationale. Le directeur du programme (dont je dirigeais le PMO) s’est assuré de cette clarté d’objectifs en les documentant et les faisant signer par le comité exécutif du programme et par son sponsor, le directeur financier de l’entreprise.Cette initialisation du programme a été l’un des éléments fondateurs de notre réussite : Elle nous a fourni un périmètre clair, des objectifs agréés et mesurables, des moyens définis et approuvés aussi bien pour les ressources internes qu’externes, et des engagements de support au processus de management du changement par le top management.

Ce programme de déploiement d’ERP comportait également un large volet optimisation et unification des processus et réorganisations des fonctions cœur de métier de la finance. Tous les processus financiers redéfinis par l’équipe projet furent signés manuellement par les responsables métier de l’entreprise (contrôleurs financiers des pays, des régions et centraux; responsables de la comptabilité, de la facturation, des achats…).

une signature manuelle reflète à mon avis un engagement bien plus fort qu’un email d’approbation

Personnellement, avant de signer manuellement un document, je le lis de manière très attentive. Souvent, je demande à un expert du domaine de mon équipe de vérifier le contenu technique ou métier. Car mon sentiment reste qu’une signature manuelle a plus de valeur qu’une approbation électronique. Je réalise qu’il s’agit très certainement d’une perception erronée puisque de nos jours de simples SMS peuvent être considérés comme preuves devant un tribunal, mais je ne suis certainement pas le seul à être victime de cette perception. Cela changera-t-il avec la génération Y née avec Internet et les communications mobiles? Peut-être, mais pas si sûr…

Comme Tim le mentionne dans son article, les tentations sont nombreuses de démarrer sans signature formelle. Nous les voyons également sur les projets internes, notamment l’excuse des délais imposés, la pression du management et des collègues, et la peur de laisser des employés inoccupés en attendant la signature.

1. délais imposés

Toujours de mauvaises raisons ! Avez-vous déjà entendu : “Toute proposition de solution qui ne peut être prête pour le 1er janvier ne nous intéresse pas !”. J’ai été témoin, et même partie prenante je le reconnais, de nombreuses décisions de projets et de solutions techniques basées essentiellement sur des critères de disponibilité prévisionnelle.

Certaines autres solutions auraient certainement mieux répondu aux besoins business mais semblaient nécessiter trop de délais. En informatique, un exemple typique est d’essayer à tout prix de réutiliser une application développée pour un but précis dans d’autres circonstances et pour d’autres objectifs. “Cette application marche bien en Europe, il n’y a pas de raison pour qu’elle ne marche pas en Asie où nous commercialisation les mêmes produits…”. En effet, cela peut paraître à la fois logique et séduisant:

• moins de développement et de tests,
• disponibilité des compétences,
• rapidité d’obtention de la solution…

Hélas, le temps d’adaptation de la solution au nouveau contexte est trop souvent sous-estimé et, à l’inverse, l’adéquation de la solution aux besoins de ses futurs utilisateurs est largement sur-estimée : une prise en compte limitée des contextes, des marchés, et des différences culturelles. Il en résulte le plus souvent une insatisfaction des nouveaux utilisateurs et des délais de mise en service qui, au final, se rapprochent d’autres solutions qui auraient pu être sélectionnées sans ce focus initial sur les délais.

2. pression du management et des collègues

Là aussi, même si ces pressions partent de convictions sincères des personnes de supporter la “meilleure solution”, elles sont souvent le résultat de vues fragmentaires de la situation ou des objectifs d’ensemble du projet. Elles sont aussi teintées de considérations plus terre à terre de disponibilité des compétences requises pour chaque solution, de luttes de pouvoir interne, de désir de développement de nouvelles compétences dans son département, d’affectation des ressources au niveau du portefeuille global de projets... On ne peut les ignorer, mais elles ne doivent pas obscurcir notre vision et nous éloigner des critères agréés de choix de la meilleure solution pour le projet.

3. ressources disponibles

Autre élément que Tim mentionne dans son article et qui est très important : le sentiment de devoir à tout prix utiliser les ressources disponibles et non affectées est très fort et assez légitime du point de vue du management de l’entreprise. Mais, du point de vue du projet: ces ressources ont-elles les compétences requises ? Sinon, combien de temps faudra-t-il passer à les former et cela est-il même faisable ? Si elles sont disponibles et ont les compétences, est-ce une raison suffisante pour démarrer sans approbation formelle du projet ? Mon expérience sur le sujet reste mitigée.

En fait, si l’on se connait bien et qu’une confiance réciproque forte existe entre business et informatique, on peut démarrer des projets de tailles raisonnable, des prototypages, du développement incrémental sans signature formelle et en mode développement “agile”. Mais, sur tout gros projet informatique, cela vaut le coup de sécuriser les approbations de toutes les parties avant de démarrer sous peine de devoir faire, défaire puis refaire, ce qui aurait été réalisé sans alignement total sur les objectifs (tant est que l’on en ait encore les moyens).

Comme le disait l’un des consultants senior avec lequel j’ai eu la chance de travailler :“Si vous ne prenez pas le temps de bien faire les choses dès maintenant, dites moi quand vous prendrez le temps de les refaire ! Car, n’ayez aucun doute, il vous faudra les refaire.”

Michel

Crédit photo : © Onidji - Fotolia.com