importance des signatures formelles sur les projets

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

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. 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é critique à notre réussite: Il 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 que externes, et des engagements de support au changement du top management.

Ce programme de déploiement d’ERP comportait également un large volet optimisation et unification des processus et réorganisations des fonctions de la finance. Tous les processus financiers qui furent redéfinis par l’équipe projet ont été 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 beaucoup plus fort qu’un email d’approbation. Personnellement, avant de signer manuellement un document, je le lis de manière très attentive, même quand je demande à un expert du domaine en question 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 pris en compte 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?

Comme Tim le mentionne dans son article, les tentations sont nombreuses de démarrer sans signatures formelles. Nous les expérimentons é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:

1. délais imposés: toujours de mauvaises raisons ! “Toute proposition de solution qui ne peut être prête pour le 1^er janvier ne nous intéresse pas!”. J’ai été témoin, et même partie prenante je le reconnais, de nombreuses décisions de choix de projets ou de solutions techniques basées sur des critères de disponibilité prévisionnelle. Certains composants auraient mieux répondu aux besoins business mais semblaient prendre trop de temps. En informatique, un exemple typique est d’essayer à tout prix de réutiliser une application développée dans un service 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 paraît 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, de plus, l’adéquation de la solution aux besoins de ses futurs utilisateurs largement surestimée avec une prise en compte limitée des contextes, marchés, et cultures différentes. Il en résulte souvent une insatisfaction des nouveaux utilisateurs, ou des délais de mise en service proches au final des autres solutions qui auraient pu être choisies 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 “bonne solution”, elles sont souvent le résultat de vues partielles de la situation ou des objectifs complets 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 global du portefeuille de projets ou de l’entreprise. 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 votre 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 qui 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 est 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 réduites, 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 défaire puis refaire (tant est que l’on en ait encore les moyens) ce qui aurait été réalisé sans alignement total sur les objectifs.

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

Les dangers à agir sans signature formelle pour le projet

http://www.pmhut.com/the-perils-of-proceeding-without-project-sign-off

Par Tim Ingram-Smith

Un des pièges du management de projet dans lequel je suis tombé plusieurs fois est de procéder sans signature complète du client ou du sponsor du projet. Souvent la mission proposée a un tel sentiment d’urgence qu’en tant que chef de projet, cherchant toujours à répondre au besoin urgent du client, je me suis embarqué sur un projet ou un produit sans une approbation claire et définitive.

Peut-être il y avait un impératif de délai, ou un lancement de produit, ou un point de rencontre avec une autre partie de développement, ou autres “ne peuvent pas être décalés”, une raison pour laquelle on “doit commencer tout de suite”; peut-être était-ce simplement qu’après tant de discussions et revues et présentations comité exécutif et à retravailler le contenu et les coûts et tant de personnes impliquées et le client hurlant presque pour commencer, que j’étais certain que le projet devait être commencé, dans la seconde.

Voici ce que je fais maintenant – je me retiens!

Peu importe à quel point je pensais être utile, ni combien l’urgence à commencer était mentionnée, je me rends compte que je ne devrais pas entamer de travail facturable avant que le client ou le sponsor de projet n’ait littéralement signé.

Démarrer le projet sans signature formelle est comme se mettre en route pour rencontrer quelqu’un alors qu’il n’a pas encore confirmé son adresse exacte : il m’est arrivé de partir sur une mauvaise route et de dépenser beaucoup de temps en aller-retour pour essayer de trouver le bon endroit.

Quand je passe outre cette signature, il se produit toujours (après un travail substantiel) que le client ne m’a pas en fait donné le feu vert, pas approuvé la portée, pas approuvé le financement, n’acceptera pas le livrable et voudra tout refaire, à partir de zéro. J’ai brûlé de l’argent, consommé de l’énergie, embarrassé mon équipe, ennuyé mon client et mis un bâton pour me battre dans les mains de mon patron – et je peux me passer de toutes ces choses!

Je dis au client, nous aimerions commencer, nous sommes prêts à y aller, pourriez vous s’il vous plaît juste signer et retourner cette commande de travail qui nous autorise à progresser.

Bien sûr, il en ressort souvent, que le client n’est pas tout à fait prêt à y aller, il n’a pas sécurisé l’approbation en interne et n’est pas entièrement à l’aise avec le contenu, il ne peut pas signer le bon de commande. Et c’est exactement pourquoi je ne dois pas procéder sans signature.

Attendre le feu vert n’est pas toujours facile : le projet peut être vraiment urgent, mes experts techniques peuvent être disponibles seulement pendant une petite fenêtre de temps avant qu’ils ne soient utilisés ailleurs, ou peut-être mes ressources brûlent des dollars internes en attendant le client. Mais ce n’est pas une raison valable pour  dépenser effort, énergie et bonne volonté sur un chemin qui atteindrait une issue non satisfaisante. Donc j’essaye de garder mes ressources déployées sur d’autres activités productives aussi longtemps que possible, et de changer rapidement leur affectation quand l’accord est signé.

Un document signé a beaucoup plus de valeur pour toutes les parties que de “la bonne volonté”: il décrit la tâche, il montre le chemin, il détaille l’accord entre les parties, c’est exécutoire devant une cour et c’est le socle de mon autorité de chef de projet.

Avec la commande de travaux ou le bon de commande en place, sécurisé par une signature du contenu et du plan de travail, le projet en entier se portera beaucoup mieux.

Tags:la gouvernance