Spécialisation des communications

La nouvelle relation MOE / MOA implique une action conjointe durant l’ensemble des phases du projet. C’est le principe de la réactivité préconisée par les approches Agiles. Pour coordonner cette action il est conseillé de faire appel à un animateur-facilitateur neutre spécialisé dans la gestion des relations interpersonnelles qui organisera avec l'ensemble des acteurs un groupe d'animation et de rapport (le GAR) chargé réaliser la validation permanente.

Dans les projets de systèmes d’information, les rapports entre les partenaires du développement, ou de la réorganisation, se complexifient et se contractualisent. La fonction de direction de projet unique fait alors place à l’action d’un binôme composé d’un coordonnateur fonctionnel et d’un coordonnateur technique. Le premier est généralement issu de la direction " métier " concernée, et sa mission consiste à imposer la dynamique applicative. Le second représente la maîtrise d’œuvre pour intégrer la dimension technologique à l’expression des exigences. Ainsi se définit l’approche, maintenant classique, de la dichotomie des relations entre maîtrise d’œuvre et maîtrise d’ouvrage.

Presque simultanément à l’acceptation de ce principe, il devient évident qu’il doit faire place à un triptyque intégrant l’intervention d'un groupe neutre d'animation-facilitation et de rapport. Ce groupe se spécialise dans la gestion des relations interpersonnelles et a pour champ d’intervention l’ensemble large des acteurs concernés de près ou de loin par le projet. Les approches méthodologiques performantes comme le RAD ou les méthodes Agiles préconisent depuis longtemps cette structure de travail. Le RAD nomme cette ressource le groupe d’animation et de rapport.

Le GAR est organisé autour d’un animateur-facilitateur dont la mission est d’obtenir une expression formelle et consensuelle des exigences par la maîtrise des techniques d’entretien, de prévision et de gestion des conflits. Lors de l’expression des besoins, l’animateur va utiliser la double compétence de son expérience des projets informatiques et de ses talents de médiateur pour transformer ce qui était un affrontement entre 2 cultures différentes en une collaboration enrichissante pour les acteurs et efficace pour le projet et l'entreprise.

Certains imaginent la distinction entre maîtrise d’ouvrage et maîtrise d’œuvre comme une spécificité " franco-française ". Faux : elle existe aussi dans les pays anglo-saxons, même si le vocabulaire y est différent. Aux Etats-Unis, le maître d’ouvrage délégué nommé " business technologists " répond d’une spécialisation à laquelle forment les universités. Si le partage des rôles que nous venons de décrire se retrouve dans à peu près toutes les entreprises, la terminologie est loin d'être fixée. Les mêmes mots reçoivent des acceptions diverses selon l'entreprise considérée : ainsi, certaines entreprises appellent " maître d'ouvrage stratégique " ce que nous appelons " coordination des maîtrises d'ouvrage " et " assistance à maîtrise d'ouvrage " ce que appelons " maîtrise d'ouvrage déléguée ". Chercher à comprendre une organisation nécessite souvent une translation de son vocabulaire vers la terminologie à laquelle on est accoutumé (source : Michel Volle, Le Club des maîtres d'ouvrage des systèmes d'information).

D’autres encore s’imaginent que cette relation est caduque. Encore faux : elle n’a jamais été aussi nécessaire. Par contre, ce qui n’est plus sensé, c’est la rupture entre une spécification d’exigence effectuée par la MOA, suivie d’une réalisation sur cahier des charges par la MOE. Cette forme d’engagement est la cause de la plupart des échecs de projets.

Dans la réalité de l’organisation, les responsabilités sont d’ailleurs encore plus complexe comme l’expose la " Vision orientée : structuration chronologie / responsabilités des actions " affichable à parie du bouton central de la page d'accueil. Car, en matière de communication et de délégation d’autorité, dans le cas d’un projet transverse, qu’il soit transdomaines ou transorganisation, il est indispensable de fonctionner selon des principes sensiblement identiques à ceux qui prévalent dans les Cercles de qualité.

Dans le cas où l’environnement organisationnel n’est pas coutumier de ce principe, il faut, dès l’étape d’initialisation, former les participants et informer les hiérarchies. Le point le plus important à considérer par l’animateur-facilitateur ou le directeur du projet est le niveau réel de délégation dont disposent les participants (empowerment). Les limites de cette autonomie de décision doivent être formalisées dans un document de type contrat-projet. Il est généralement signé entre la MOA et la MOE dans un entretien préalable à la réunion de lancement du projet.

1.1. Séance de spécification et séance de validation

En termes de communication, un protocole formel de validation des travaux doit être établi. Un circuit informel devra néanmoins se mettre en place entre les participants au projet et leur hiérarchie d’origine. Afin d’éviter tout malentendu, il faut enseigner à la hiérarchie les différences entre les principes d’actions propres aux projets transverses et leurs pratiques habituelles de commandement.

La distinction devant être faite entre séance de spécification et séance de validation est de la plus grande importance.

Les exigences du projet sont spécifiées durant des séances où œuvre un cercle composé essentiellement d’utilisateurs de base et de cadres opérationnels. La production de ce cercle doit ensuite être validée par un niveau supérieur d’encadrement lors d’une séance de validation.

Lors d’une validation, il n’est pas question de refaire le travail de spécification mais simplement d’en confirmer la pertinence, ou, dans le cadre d’une divergence, de demander un approfondissement du sujet.

Le cas où la séance de validation se transforme en séance de spécification et met en évidence des différences de vision entre les utilisateurs de base et la hiérarchie est un signe évident de dysfonctionnement de l’organisation. L’animateur-facilitateur doit alors réagir en modifiant la composition des groupes de travail pour y intégrer un niveau supérieur d’encadrement, ou à défaut, le projet s’enlise. Parfois, le cas implique de modifier très concrètement les pratiques d’un encadrement s’auto-estimant compétent et n’acceptant pas les remises en question. Ce cas n’est pas aisé à traiter. Lorsqu’il est possible d’obtenir l’attention des cadres concernés, il faut leur proposer une courte information sur la distinction entre spécification détaillée et validation générale, sur la notion de granularité de préoccupation et sur les indispensables niveaux d’abstraction en tant que garde-fous d’un improductif et dangereux mélange :

 de besoins fonctionnels,

 de solutions techniques,

 d’impact organisationnel,

 et de contraintes de réalisation.

Cette nécessité d’un minimum de rigueur est vitale dans les projets ou la complexité réelle est cachée sous une apparence de simplicité fonctionnelle. Ce cas s’est encore vérifié lors d’un projet récent où aucun animateur n’avait été engagé et où ces aspects de formes de communication n’avaient pas été considérés comme importants. Le déficit de communication auquel cette situation a abouti s’est avéré la base de fâcheux quiproquos, où toute l’incompréhension de la hiérarchie pour ces notions et le refus de les intégrer s’est révélée dans la dimension de sa véritable nature : plus autoritaire que compétente. Deux états qui naturellement et généralement vont de pair.

Dans une organisation conséquente, créer une cellule méthode pour encadrer le travail des MOA peut être une solution intéressante à considérer dans la limite d’une action qui ne saurait se substituer à celle de l’animateur-facilitateur (neutre et répondant à une instance supérieure). Par contre, créer une maîtrise d’ouvrage permanente par l’embauche de nouvelles ressources n’est pas une solution viable, mais plutôt une monumentale source de problèmes. Pourtant, cette solution de facilité semble se répandre dans les organisations incapables de se doter d’une vraie maîtrise d’ouvrage.

La MOA doit être " du " métier, pas " de " métier ! Une MOA efficace est une force de proposition fonctionnelle au fait du détail et de la réalité du processus métier.

Aussi, les membres de la MOA d’un projet spécifique sont pressentis sur la base de :

 leur maîtrise du métier dans sa réalité opérationnelle quotidienne,

 leur vision projective de l’évolution prévisible du contexte,

 leur représentativité en regard des autres utilisateurs,

 leur intérêt affirmé pour l’amélioration de l’outil de travail.

Il faut garantir à ces professionnels de terrain des conditions organisationnelles permettant un engagement à plein temps si nécessaire. La qualité et la rentabilité des projets sont à ce prix. Lorsque, pour des raisons diverses, il est dérogé à cette règle, il faut s’attendre à des problèmes plus ou moins affirmés mais toujours onéreux, quand ce n’est pas à un réel échec.

1.2. Groupe d’animation et de rapport

Par rapport aux deux maîtrises qui viennent d’être définies, l’animateur-facilitateur est neutre. Il " facilite " des entretiens de groupe auxquels participent des utilisateurs d'origines diverses. Les participants développement alors une formalisation précise de leurs tâches respectives dont l’aboutissement est la modélisation du " métier ". Apparaît ensuite la justification des objectifs et de la raison d’être (ou de ne pas être) des travaux et circuits d'information qu'ils utilisent. Cette réflexion conduit généralement à une responsabilisation de l'ensemble des participants et peut déclencher une dynamique de recherche de qualité dépassant les limites du projet informatique pour aboutir à une réingénierie des procédés.

La composition habituelle d’un GAR inclut des rapporteurs. La mission de ces auxiliaires spécialisés est de réaliser en direct la formalisation des exigences et la modélisation de l’application. Les sessions de travail et de validation permanente se réalisent lors de travaux de groupe organisés dans un espace de communication dédié, équipé de logiciels et de matériels adéquats (atelier de génie logiciel sur micros, moyens électroniques de vidéo-projection, etc.).

Dans un petit projet, il est fréquent que le rapporteur chargé de la modélisation soit délégué par la MOE, et que celui chargé de la formalisation textuelle relève de la MOA.



Suite et compléments publiés dans l'ouvrage

Systèmes d'information et processus Agiles
Hermès Science Publication, 3 juillet 2003

Systèmes d’information et processus Agiles a pour objectif de former les ressources (maîtrise d'ouvrage comme maîtrise d'œuvre), engagées dans un projet d’organisation et/ou de système d’information.
Systèmes d’information et processus Agiles décrit d'abord les aspects stratégiques de l'Agilité puis en détaille les concepts opérationnels. Il s'adresse aux dirigeants et à tous les cadres de l'organisation, dont évidemment, les DSI et chefs de projets "informatiques" ou "utilisateurs".

Outil de compréhension de l'agilité organisationnelle et support de sa mise en œuvre technique, l'ouvrage afin d'offrir une réponse appropriée aux intérêts de chaque acteur du projet, est organisé en 3 sections :

  • Organisation et Urbanisation
  • Communications et ressources humaines
  • Agilité en conduite de projet



  • www.RAD.fr ® © Jean-Pierre Vickoff