A l'affiche

Projet & communication

Dernièrement, j'ai eu l'occasion de répondre à quelques questions posées par une SSII dans le cadre d'une enquête. Le thème : les projets et la communication. J'ai répondu aux questions posées, de manière détaillée, et je me propose aujourd'hui de partager mes réponses avec vous.

Quelles sont les 3 conseils de communication que vous donneriez à un Chef de projet ?

Premier conseil : sur un projet informatique, il y a une multitude d'acteurs, aux responsabilités diverses, aux métiers différents et à des niveaux hiérarchiques différents. Le premier conseil, c'est qu'il ne faut pas avoir "une communication", mais "des communications".

Par exemple, les informations qui seront utiles aux décideurs sont très différents des informations qu'attendent les développeurs. Inversement, les informations techniques utiles aux développeurs n'intéressent pas du tout les décideurs, dont le niveau d'attente en termes d'informations est plus macro.

Se cantonner à ne faire "qu'une communication", c'est noyer tous les intervenants dans un flot commun d'information, et c'est à coup sûr tuer l'information : les décideurs ne prêteront plus d'attention au flot d'information à la granularité trop fine, tandis que les équipes de développement seront potentiellement stressés par des remontées macro (trop macro selon eux) sur une situation du projet, faite à l'attention de décideurs. Au final, personne ne se sentira concerné par l'information, et aucun ne sera atteint efficacement par l'information importante qui le concerne en premier lieu.

Second conseil : partager les décisions!! Un projet c'est avant tout des décisions qui sont prises par les décideurs : ce sont des jalons cibles, ce sont des actions à réaliser, des stratégies, des orientations fonctionnelles et techniques. Ces décisions engagent le projet sur des choix fonctionnels, des choix techniques, des choix organisationnels.

Ces décisions doivent impérativement être tracées (écrites, compte rendu), et partagées (affichées) avec ceux qui ont pris ces décisions, et ceux qui vont appliquer les actions qui découlent de ces décisions. Chaque nouvelle décision doit faire l'objet d'une communication envers tous les acteurs, quitte à différentier la forme et le contenu selon les acteurs.

L'affichage clair des décisions prises est primordiale pour responsabiliser tous les acteurs : il est fréquent qu'à l'issue d'un projet, une mauvaise décision initiale prise par des décideurs MOA aboutisse à des impasses fonctionnelles dont la MOE portera au final la responsabilité, car telle est la tradition dans les projets informatiques. Afficher clairement les décisions permet de rendre le partage des responsabilités de manière plus saine.

Ce partage comprend également le partage des documents (spécifications, storyboards, ...), dont chaque mise à jour majeur doit faire l'objet d'une communication, en plus d'un partage correct des supports. Cette communication permet à la MOA de valider de fait les nouvelles orientations fonctionnelles décidées, et à la MOE de prendre connaissance des fonctionnalités à intégrer dans l'application. L'absence de communication sur la mise à jour d'un document fonctionnel (spécifications , ...) peut avoir des conséquences financières directes très rapides, du fait des modifications et corrections à faire sur des développements réalisés sur la base de spécifications obsolètes.

Troisième conseil : plus que de communiquer, le chef de projet doit animer son projet, via sa communication. L'animation va au delà de la communication : c'est faire tout ce qui est nécessaire pour garantir les bonnes interactions entre les acteurs en s'assurant que tout le monde est en phase sur son propre domaine de responsabilité. C'est s'assurer que tout le monde se comprend, et s'estime, car aucun projet impliquant des acteurs qui se méprisent ne peut réussir pleinement. Animer un projet, c'est aussi s'assurer que tout le monde est motivé, et que tous partagent le même objectif et ont conscience des enjeux. Voir le dossier sur mon site Projets Informatiques: http://bit.ly/1fSoZzu

D’après vous, quels sont les 3 pièges usuels en terme communication dans lesquels tout le monde tombe ?

Premier piège : ne faire aucune action de communication. Tout simplement parce qu'on n'a pas le temps, ou parce que le chef de projet (MOA ou MOE) n'a aucune fibre pour communiquer. Les conséquences sont assez rapides avec une désorganisation de tous les acteurs projets, et des conflits larvés qui ne manqueront pas de se déclarer : chacun rejetant sur l'autre la responsabilité d'une mauvaise orientation ou décision (car non tracée).

Second piège : parler d'une seule voix pour tous les acteurs projets, et pour tout type d'information. L'exemple type : le chef de projet a un mail type avec plusieurs dizaines de destinataires, MOA MOE confondus, managers & développeurs mélangés et "arrose" tout le monde à chaque évènement, décision ou avancement. Dans ce cadre, techniquement, le chef de projet fait la communication sur son projet, on ne peut rien lui reprocher, à part le fait qu'il le fait mal.

Troisième piège : utiliser le mail uniquement pour communiquer, échanger, partager. Dans bon nombre d'équipes, le mail reste l'outil de partage (des documents, ..) et de communication pour toutes les étapes du projet. Pour utiliser exclusivement le RSE pour animer mes projets depuis maintenant 3 ans, l'usage exclusive du mail est à mon sens un non sens complet dans le cadre de l'animation d'un projet. Encore faut il que l'entreprise soit équipée d'un RSE.

Quel est le plus importante difficulté que vous ayez rencontré (ou juste observé) due à un dysfonctionnement dans la communication ?

Une communication défaillante impacte souvent les aspects suivants d'un projet.

Conflits MOA / MOE: si la MOA prend une décision, qui ne s'avère pas pertinente, ou qu'une solution technique controversée est proposée à la MOA pour palier à une difficulté rencontrée dans le projet, plusieurs mois plus tard, la raison de ces décisions peut être oubliée, si aucune communication n'a été faite ou tracée. C'est alors la parole de l'un contre celle de l'autre, avec à la clé des conflits de personnes qui n'apportent rien de bon au projet.

Surcoûts de développement: l'absence de communication sur des évolutions fonctionnelles d'un projet peuvent avoir des impacts directs sur le coût d'un projet. Mal informés, les développeurs peuvent développer une solution qui ne correspond pas à la cible, avec à la clé des modifications à apporter quand le problème de documentation de référence est identifié.

Animation : l'absence de communication sur les enjeux et les raisons des décisions peut avoir un impact sur la mobilisation des acteurs. Cas réel : un projet dont le délai de réalisation a été divisé par deux, sans expliquer les raisons liées à un enjeu métier fort. Les raisons des décisions doivent être partagées si elles ont pour origine des enjeux stratégiques important, pour mobiliser les équipes

Racontez une situation difficile dont vous (ou quelqu’un) êtes sortis grâce à une bonne communication.

A l'issue d'un projet, une MOA nous a reproché des délais de mise en oeuvre trop importants. Argument évoqué : la mise en service de l'application attendue initialement en janvier, ne s'était faite qu'en juin. Le projet étant d'importance, le reproche a été escaladée aux différentes hiérarchies côté métier et DSI.

De notre côté, l'inscription dans un "blog" partagé avec la MOA, de toutes les décisions, avec les dates précises, ont permis en 20 minutes de retracer quasiment jour par jour, toute les décisions prises sur le projet, et tous les évènements. Cet historique a alors mis en lumière plusieurs périodes de "mise en attente" du projet, entre le lancement des études, et la finalisation des spécifications, pour faute de temps disponible de la maitrise d'ouvrage. L'addition de ces "mises en veille" volontaires du projet par le demandeur lui même, correspondait exactement au décalage reproché (de plusieurs mois), avec au passage des conséquences de charge des équipes MOE mises en attente pour lesquelles nous n'avions pas voulu polémiquer à l'époque.

Le traçage systématique de ces décisions, même anodines (retards de part et d'autres) a permis d'éviter un conflit entre les deux partis, et a surtout évité une sanction de la MOE.

Votre/vos outils de communication préférés (déclinable par interlocuteur, situation, etc.)

Depuis 3 ans, notre équipe utilise exclusivement le RSE pour animer les projets dont nous avons la charge. Il n'y a plus d'échange de mails (ou très peu) : les échanges entre les acteurs se font au travers d'un "mur d'échange" au sein de la communauté. Dans cette même communauté sont stockés les documents projets et toutes les informations utiles (planning, etc).

Tous les comptes rendus et évènements importants du projet sont tracés dans un blog projet, permettant de retracer tout l'historique du projet.

Cette manière de faire, permet de créer un endroit unique qui concentre toute la connaissance sur un projet : échanges entre les acteurs, communication, documents, comptes rendus, etc. Sans un tel outil, ces informations sont dispersées dans les BAL des acteurs projets, et des serveurs de fichiers (dans le meilleur des cas).

Mieux, les communautés d'un RSE permettent de créer des "groupes" d'acteurs projets de même niveau en termes de besoin d'informations. Généralement, nous créons par exemple, pour un même projet, deux communautés : une communauté pour l'équipe technique en charge du développement, et une communauté pour la MOA. Les infos échangées dans les deux cas sont différents même si certains informations sont communes (comme par exemple les spécifications).


Billets récents

Billets par tags