MOA PARTNER
Consulting Banque Finance
maîtrise d’Ouvrage
MOA – MODE D’EMPLOI
Comment la MOA peut-elle obtenir l'adhésion des utilisateurs ?
Accompagnement du changement
L'accompagnement du changement n'est pas l'épilogue d'un projet. C'est une démarche qui s'exécute sur toute la durée d'un projet. Comment la MOA peut-elle obtenir l'adhésion des utilisateurs ?
Définir sa stratégie, ses objectifs
En fonction de la dimension du changement (à l'échelle d'une application, d'un process, d'une organisation, de l'entreprise) et en fonction de la criticité de l'adhésion des utilisateurs finaux pour la réussite du projet, les exigences de l'accompagnement du changement ne seront pas les mêmes. Il est donc important de bien identifier la nature du changement pour identifier la bonne stratégie à adopter. Le déploiement worldwide d'une nouvelle application métier dans le but d'améliorer la qualité d'un processus ou la modification d'un processus métier pour optimiser les coûts avec des réductions d'effectifs ne seront pas gérés de la même manière.
Impliquer les utilisateurs en amont
L'accompagnement du changement ne se fait pas à la fin du projet, comme une cerise sur le gâteau. C'est un facteur clé de la réussite qui se négocie dès le début du projet. Plus les utilisateurs sont inclus tôt dans le projet, moins vous risquez d'avoir à gérer un rejet. Pour cela, certains utilisateurs clés, appelés parfois les "champions", doivent être embarqués afin de convaincre les autres utilisateurs de l'intérêt du changement. Ces "champions" aiment le risque et prendre des responsabilités supplémentaires ou ont un intérêt personnel à ce que le projet réussisse. Il ne faut pas passer à côté de cette opportunité, un "champion" charismatique permettra de convaincre bien plus de monde que la meilleure des présentations par une équipe projet.
Enfin, conservez une fois de plus votre bon sens et vos qualités humaines. Je citerai cet utilisateur qui m'a dit : "Vous facilitez la communication entre les systèmes, c'est très bien, mais n'oubliez pas de faciliter la vie des humains !".
La MOA doit-elle être un expert fonctionnel ?
Oui, la MOA peut être un expert fonctionnel...
Les MOA peuvent être au départ un expert fonctionnel qui est monté en compétences sur les aspects projet et les techniques de la maîtrise d'ouvrage. Par exemple, en finance de marché, un ancien opérateur Front ou Middle Office peut devenir maîtrise d'ouvrage sur un projet SI. Dans ce cas c'est un expert fonctionnel et métier qui est monté en compétences pour apprendre ce qu'était un projet SI et quelles étaient les activités d'une MOA et les livrables à fournir dans le cadre d'un projet SI. Plus souvent les MOA acquièrent l'expertise fonctionnelle avec le temps, en restant plusieurs années dans le même domaine fonctionnel. Elle devient alors un expert fonctionnel.
... mais être un expert fonctionnel ne signifie pas qu'on est une bonne MOA...
Être un expert fonctionnel ne signifie pas que l'on est une bonne MOA. La maîtrise d'ouvrage est un domaine fonctionnel à part entière. Il y a énormément de compétences à acquérir propres à ce domaine, les process de développement informatiques sont spécifiques à cette industrie. De plus quand on est MOA sur des projets SI, il faut avoir une culture informatique importante pour pouvoir comprendre les enjeux IT.
... alors finalement faut-il changer de domaine fonctionnel ?
Il est vrai qu'un regard neuf amène toujours des solutions qu'on n'arrive pas à faire émerger quand on est depuis trop longtemps sur le même sujet. Mais si vous choisissez de recruter une MOA qui n'est pas un expert du domaine, il vous faudra quelqu'un d'autre pour remplir ce rôle ! Donc cela ne fonctionnera que si vous avez des utilisateurs expérimentés et disponibles avec qui travailler ou alors si votre organisation a la maturité nécessaire pour formaliser ce type de rôle.
Finalement, en tant que MOA, je pense qu'il vaut mieux être généraliste dans un domaine plutôt que d'être complétement spécialisé. Il est important d'être passionné par le domaine dans lequel on travaille et d'essayer d'en apprendre un maximum afin d'être critique vis à vis des demandes des sponsors et des utilisateurs. Mais pourquoi ne pas construire sa carrière sur deux ou trois domaines de prédilection ? Cela permet de garder de la fraicheur et de rester innovant. L'inconvénient c'est que cela demande de se remettre en cause et de prendre des risques...
Management transverse, comment vaincre les clivages ?
Management MOA
En tant que MOA, on est souvent amené à travailler en réseau, à utiliser le management transverse. Et quand l'organisation de notre entreprise est très hiérarchisée, ce travail en réseau n'est pas facilité. Autre contrainte au niveau SI, l'architecture orientée service a souvent été mise en place sans refonte de l'organisation. Voilà les pire cas que l'on peut rencontrer et quelques idées pour les gérer au mieux.
Gérer le clivage MOA/MOE
• La caricature :
Il vaut mieux être au courant : La MOA pense que les MOE sont des "pisseurs de code", la MOE pense que la MOA sont des "pisseurs de slides".
• Les solutions du point de vue de la MOA pour éviter d'en arriver là :
Utilisez le plus souvent possible un style de management participatif. Demandez "quel est le plan d'action à mettre en œuvre pour tenir la date de livraison ?" plutôt que d'imposer une échéance.
Utilisez également un style autocratique lorsqu'il le faut. La MOA a son expertise, les décisions en relevant doivent être clairement prises et actées de tous. Ceci n'empêche pas d'expliciter les tenants et les aboutissants bien sûr.
De la même manière, ne remettez jamais en cause les décisions prises par la MOE qui relèvent de leur expertise. Par exemple, une MOA ne doit pas remettre en cause le chiffrage fourni par la MOE, même si elle est en droit de demander des détails ou des explications.
Gérer le clivage MOA/Sponsor
• La caricature :
Le Sponsor n'a pas de temps à accorder à la MOA. Pour lui, la MOA est un "informaticien" comme un autre. La MOA pense que son sponsor ne s'implique pas assez dans le projet.
•Les solutions du point de vue de la MOA pour éviter d'en arriver là :
Usez de vos qualités relationnelles. Sachez apporter légèreté et humour quand les conditions sont réunies, soyez toujours d'humeur égale, traitez parfois de hors sujets...
Adaptez votre style à votre interlocuteur. Certains interlocuteurs peuvent faire attention aux détails : ponctualité, look, sachez -vous adapter.
Optimisez votre temps. Organisez des réunions courtes (30 minutes sont souvent suffisantes) mais régulières. Préparez les en utilisant un support optimal (type "Flash report"), conduisez les réunions en évitant les écarts, rédigez et diffusez toujours le compte-rendu dans la foulée pour mettre noir sur blanc les résultats de ces réunions.
Gérer le clivage intergénérationnel
• La caricature :
La différence essentielle entre un jeune con et un vieux con réside dans le temps qu'il leur reste à être cons. - Jean Dion.
En tant que MOA vous serez amené à travailler avec des gens qui ont des rôles bien différents, vous amenant à réaliser un grand écart générationnel.
• Les solutions du point de vue de la MOA pour éviter d'en arriver là :
Soyez ouvert. Vous allez être tantôt le jeune, tantôt le vieux. Sachez rester ouvert aux points de vue de tous les intervenants. Un utilisateur qui a 30 ans d'expérience sur son poste ne vous fera pas les mêmes retours qu'un utilisateur qui sort de l'école. Mais tous sont bon à prendre.
Acceptez la critique. On vous prendra un jour pour un jeune prétentieux aux dents longues parce que vous souhaitez bouleverser un processus métier qui fonctionne très bien depuis 15 ans, et le lendemain pour un vieux de la génération X parce que vous ne pratiquez pas le twittering et que vous avez aimé connu le doux chant du modem 56K. Acceptez de recevoir toutes les critiques, vous n'avez rien à prouver.
Comment découvrir les besoins ?
Recueillir les exigences des différentes parties prenantes d'un projet, c'est comme construire les fondations de votre projet. C'est sur ces exigences que l'ensemble du projet va reposer. Mais avant de les formaliser un minimum, il faut déjà les découvrir.
Organisez des entretiens Top-Down
Je conseillerai plutôt de commencer par rencontrer les personnes ayant une vision plus globale du processus concerné pour finir par les utilisateurs clés des systèmes supportant le processus (par exemple dans une salle des marchés commencer par s'entretenir avec un directeur de l'exploitation ou un directeur d'une ligne métier, ensuite voir un responsable de table pour finir par un opérateur de marché et enfin un assistant). Cela permet de commencer par découvrir les exigences stratégiques pour finir par les exigences fonctionnelles et non fonctionnelles. Je pense également que le temps à passer doit être moins important avec le top management qu'avec les opérateurs au cœur du processus.
Préparez vos entretiens
Une réunion demande toujours d'être préparée, d'être conduite, puis il faut en rédiger un compte-rendu. Le compte-rendu d'un entretien de recueil de besoins est la matière première qui va permettre de construire le référentiel des exigences. Le point clé de la préparation de la réunion, afin d'avoir un compte-rendu copieux, c'est de prévoir les questions qui vont cadencer l'entretien. Ces questions doivent être adaptées à votre interlocuteur et suivre une évolution du plus global au plus précis.
Pensez processus métier et architecture orientée service (et non pas système)
On ne cherche pas encore à spécifier un système ou une solution même si les utilisateurs auront tendance à se rattacher à du concret. Posez vos questions afin qu'elles soient le plus possible absolue vis à vis des solutions (pour caricaturer, demandez quelles sont les informations nécessaires pour remplir un dossier plutôt que de demander quel écran de saisie est nécessaire). Gardez également toujours en tête comment cette partie s'inclut dans un processus métier complet.
Une exigence n'est donc pas simplement une information qui est venue à nous sans aucun travail. Le recueil des besoins est une phase clé du projet. Se contenter d'un mail succinct (le fameux Post-it) envoyé par le sponsor pour se lancer dans une phase de spécification fonctionnelle n'est pas suffisant. Il est vrai que cette phase de projet n'est pas "technique" mais exploite plutôt les compétences d'analyse et le relationnel de la MOA, et on peut donc parfois la sous-estimer sur un planning. Mais attention alors au risque de retard, car entre la préparation, la planification des entretiens, et l'analyse des résultats, cette phase peut être très consommatrice de temps.
Quels sont les cinq points clés pour réussir une recette ?
1) Définissez la stratégie de la recette.
En plus de la description de l'organisation et des moyens mis en œuvre pour la recette, n'oubliez pas de décrire l'objectif de cette recette. Faire la recette d’une application, ce n'est pas vérifier que l'application n'a pas de bug. Faire la recette, c'est vérifier que le système répond aux exigences fonctionnelles et non fonctionnelles par rapport aux coûts et à la qualité attendue. Définissez donc en amont quelle est la criticité des fonctionnalités du système et le niveau d'acceptabilité pour chaque criticité. Par exemple, on acceptera peut-être un bug bloquant sur une fonctionnalité "cosmétique" alors que pour une fonctionnalité très critique, aucun bug bloquant ou majeur ne sera toléré.
2) Pensez aux tests avant tout.
Test Driven Development, Behavior Driven Development, Acceptance Test Driven Development... Beaucoup de méthodes prônent la conception par les tests. Sans forcément passer par des concepts complexes, penser "tests" dès la conception fonctionnelle permet souvent d'expliciter sa pensée et de se concentrer sur les objectifs du système.
3) Coordonnez et planifiez la recette.
Même si tous les tests ne sont pas exécutés par la MOA, coordonnez. De la mise à disposition des environnements de test, à l'exécution de tests de performance, en passant par les tests utilisateurs, vous devrez coordonner des équipes aux contraintes très différentes. La recette est souvent un projet en elle-même.
4) Outillez-vous.
Que ce soit pour la description des plans de test et le suivi de l'exécution des campagnes, utilisez des outils pour industrialiser vos tests. Au minimum, utilisez un fichier Excel pour décrire vos scénarios et cas de test ainsi que pour en suivre l'exécution.
5) Soyez pugnace.
La recette n'est pas une activité simple. Bien que souvent pénible et répétitive dans son exécution, c'est un moment clé du projet. On est souvent tenté de rogner sur la charge prévue pour cette activité car à la fin d'un projet, il ne reste plus grand chose à arbitrer ! Et pourtant, c'est le dernier rempart avant la mise en production. La négliger pourrait être une erreur fatale.
Comment diminuer la charge des activités de test ?
Que ce soit la préparation (définition de la stratégie de recette et des plans de test) ou son exécution, une recette consomme beaucoup de ressources. J'ai souvent vu des projets sur des systèmes critiques pour l'entreprise avec des tests de validation qui représentaient 20% de la charge globale du projet. Ainsi il est important d'optimiser les activités de test.
Demandez à votre MOE un rapport d'exécution des tests unitaires et tests d'intégration
En plus de l'application à tester, votre MOE doit vous livrer un rapport d'exécution des tests unitaires et tests d'intégration. De nombreux outils existent pour faciliter le développement et le reporting de tests unitaires. Il peut être très coûteux de mettre en place des tests unitaires pour une application existante, il faut donc y penser dès le commencement du projet et que les charges de développement prennent en compte le temps nécessaire à la réalisation des tests unitaires. Pour cela, la MOA doit être prête à sponsoriser cette surcharge de travail.
Plan de test
Il faut utiliser un outil ou a minima un fichier Excel pour consigner les plans de test et les réutiliser. Cela doit permettre de spécifier le plan de test, planifier les campagnes de test, suivre l'exécution des tests et effectuer un reporting sur l'avancement des tests. Les tests des nouvelles fonctionnalités deviennent ensuite des tests de non régression, et on peut les réutiliser.
Tests fonctionnels automatisés
Et pourquoi ne pas aller plus loin et essayer d'automatiser les tests fonctionnels ?
Testeur - Un vrai expert
Finalement, on se rend compte que les techniques de test sont aujourd'hui nombreuses et parfois complexes. Le métier de Testeur est donc devenu un métier en lui-même où l'expertise est dure à obtenir. Si votre structure est trop petite pour avoir une équipe dédiée aux tests, alors il ne faut pas hésiter à faire appel à un expert externe pour aider à la mise en place de bonnes pratiques pour une démarche de test qui doit être intégrée à tout le cycle de vie d'un système.
Comment améliorer l'alignement IT/métier en utilisant un outil de gestion des exigences ?
L'informatique ne doit plus simplement suivre le métier. On attend aujourd'hui d'un SI qu'il soit capable de s'adapter à toutes les évolutions du business même ceux qui n'ont pas été anticipés par les opérationnels. Dans une étude concernant l'état de l'art de l'aligement IT / Métier en France publiée en 2008 par le cabinet PAC - Pierre Audoin Consultants, on apprend que « La collaboration entre maîtrises [maîtrises d'ouvrage et maîtrises d'œuvres] est un point crucial, qui pourrait être le fil rouge de cette étude. Elle est jugée critique à 94%. » On note également dans cette étude que l'intégration MOA/MOE est le deuxième levier juste derrière le projet stratégique au niveau de l'entreprise pour améliorer l'alignement IT / Métier.
Il existe des outils qui peuvent aider à plusieurs niveaux sur ce sujet. Ce sont les outils de gestion des exigences (requirements management). Une exigence fait référence à un besoin d'une des parties prenantes du projet. Une exigence peut être fonctionnelle ou non fonctionnelle.
IBM nous explique ce qu'une exigence doit être :
• Correcte (techniquement et juridiquement possible) ;
• Complète (exprime une idée ou un fait dans sa totalité) ;
• Claire (sans ambiguïté) ;
• Non contradictoire (pas en conflit avec une autre exigence ) ;
• Vérifiable (il est possible de définir si le système répond à cette exigence) ;
• Traçable (identifié de manière unique et tracé) ;
• Faisable (peut être accompli dans les coûts et délais prévus) ;
• Modulaire (peut être changé sans impact excessif) ;
• Indépendant de la conception (ne parle pas de solution concernant la conception).
Une fois que les exigences sont exprimées, tout l'intérêt d'un outil de gestion des exigences est de permettre la traçabilité afin de pouvoir répondre aux questions suivantes :
•Est-ce que tous mes besoins ont été couverts par le système ?
•Quels besoins étaient mal exprimés et donc volatiles ?
•Quel est l'impact si je modifie une exigence ?
C'est en étant capable d'analyser ces points qu'on pourra ensuite améliorer l'alignement IT / Métier.
La MOA est-elle une hôtesse de l'air ?
Le support applicatif métier est difficilement externalisable, contrairement au support sur les applications dites "bureautiques" (gestion des courriers électroniques, traitement de texte...). Plus les applications métiers sont critiques pour l'entreprise, plus l'équipe support applicative doit avoir des profils de haut niveau et des compétences pointues. Ce sont parfois directement les maîtrises d'ouvrage qui exercent le rôle de support applicatif ou support fonctionnel, alors que d'autres organisations mettent en place des équipes dédiées à ce support très proche du métier (équipes que l'on peut considérer alors comme assistance à MOA).
La MOA doit donc avoir le sens du service ?
Dans l'article Le « sens du service », une question d'organisation sur scienceshumaines.com l'auteur évoque les travaux d'Arlie Russel Hochschild qui dès 1983, dans The Managed Heart, définit le concept de « travail émotionnel » pour les hôtesse de l'air « consistant à réélaborer leur ressenti et à influer sur celui des passagers, notamment en diffusant un sentiment de sécurité ». La maîtrise d'ouvrage serait en fait un steward ou une hôtesse de l'air ? Il est vrai que face à un problème de production important ou face à une forte réticence au changement, la MOA peut avoir ce rôle de « travail émotionnel » : calmer l'utilisateur si ses craintes ne sont pas fondées, communiquer les informations nécessaires sans créer de panique, et éventuellement expliquer comme accéder aux toboggans de secours si le crash est inévitable !
Ensuite l'auteur de cet article parle des travaux du sociologue américain Ervin Goffman (Asile, 1968) pour définir la « compétence de service » : « la capacité de prendre une décision non prévue par une procédure impérative et de la présenter comme professionnellement justifiée ». Une telle décision n'est jamais facile à prendre car elle se prend toujours dans un contexte délicat. Donc plus qu'un sens du service commun une MOA doit avoir cette "compétence de service" afin d'être capable de réagir à des problèmes variés qui attendent des solutions spécifiques.
La notion de support informatique est souvent mal perçue pourtant faire du support applicatif ou fonctionnel sur des applications très critiques demande des compétences pointues sur le domaine géré et également une grande compétence de service. Il me semble également qu'il est toujours bon pour une MOA même si elle est orientée projet d'être au contact de la production et de ses réalités de terrain, cela permettant de concevoir des solutions fonctionnellement adaptées à la réalité.
Comment acquérir la confiance et le respect des parties prenantes de vos projets ?
Acquérir la confiance et le respect des différentes parties prenantes de vos projets est primordial pour pouvoir jouer pleinement votre rôle de facilitateur et d'influenceur. Si les gens vous respectent, vous pourrez plus facilement désamorcer les conflits. Si les gens vous font confiance, vous obtiendrez plus facilement l'adhésion aux décisions prises. Mais comment en arriver là ? Comme aujourd'hui je suis d'humeur optimiste, commençons par la méthode Coué :
Si vous avez confiance en vous-mêmes, vous inspirerez confiance aux autres. Johann Wolfgang von Goethe.
On respecte un homme qui se respecte lui-même.Honoré de Balzac.
Communiquez, faites circuler l'information
Si vous faites circuler l'information, à bon escient évidemment, on vous reconnaitra comme quelqu'un de confiance. Celui qui fait de la rétention d'information n'est pas vu comme quelqu'un de confiance, mais plutôt comme un incompétent. En effet, si il était compétent, il n'aurait pas besoin de faire de la rétention d'information pour se valoriser.
Ne réagissez pas aux objections infondées
Si on sur-réagit à des objections infondées (qu'elles soient émises par mail, en réunion ou par tout autre média), c'est qu'on est sur la défensive et donc que l'on a des choses à se reprocher. Dans ce cas-là, mieux vaut ne pas réagir du tout. Laisser un blanc dans une réunion suite à une objection infondée fera clairement comprendre à son interlocuteur qu'il s'est lourdement trompé. Et cela vous assurera le respect.
Prenez vos responsabilités, assumez les erreurs
Nous commettons tous des erreurs. En tant que MOA, vous devez accepter vos propres erreurs (par exemple un oubli dans une spécification ou une erreur de conception fonctionnelle), mais vous devez également assumer les erreurs de toute l'équipe projet face à vos sponsors. Inutile de rechercher et identifier le coupable idéal, cela ne vous apportera rien. Face au sponsor, soyez efficace : quelle erreur a été commise, quels sont les impacts, quel plan d'action pour y remédier. Savoir gérer et assumer les problèmes vous aidera à gagner la confiance des parties prenantes de vos projets.
Finalement, acquérir confiance et respect dans le milieu professionnel est un travail sur le long terme. Éthique, déontologie, développement durable sont des concepts à la mode que l'on peut appliquer pour soi au quotidien. Pour une fois c'est mon côté Candide, ou l'optimisme qui parle.
Le travail éloigne de nous trois grands maux : l'ennui, le vice et le besoin.Voltaire.
Comment la MOA peut dépasser la dépression post projet ?
Le baby blues survient entre le deuxième et le quatrième jour après l'accouchement, dure en moyenne deux jours. Une fois l'euphorie de l'aboutissement passée, et les premières mises en pratiques approximatives, on y est. Le projet est terminé. Alors que le stress redescend, comment dépasser la dépression post projet ?
Identifiez les réussites et les échecs de ce projet
Indépendamment de l'aspect affectif, cherchez à identifier les réussites et les échecs de ce projet. Pour la MOA, en premier lieu il faut identifier si les exigences ont été remplies. Si vous avez les outils adéquats, vous pouvez analyser les caractéristiques des exigences : ont-elles été volatiles ? combien ont été créées en cours de projet ? est-ce que les priorités ont beaucoup changé ? Et comme les parents trouvent toujours leur progéniture merveilleuse, vous pouvez essayer d'obtenir la perception des utilisateurs sur la réussite du projet. C'est moins quantitatif, mais finalement beaucoup plus objectif ! Attention, si vous recherchez le retour des utilisateurs, attendez que s'écoule quelques jours ou semaines. Les projets débutant en production avec quelques couacs (problèmes lors du déploiement, forte résistance au changement...) peuvent se transformer en réussite totale une fois les tensions des premiers jours passées.
Obtenez des retours sur votre travail
Profitez-en également pour identifier comment vous avez participé à ces réussites et ces échecs. N'hésitez pas à solliciter vos sponsors ou vos responsables pour avoir un retour sur votre travail. Quand le projet a atterri, il est plus facile d'obtenir un retour objectif car les différentes parties prenantes ont tous les éléments pour juger votre travail, et ils auront la distance nécessaire. Pensez également à faire un point sur vos méthodes de travail et les techniques de la MOA. Avez vous trop voulu formaliser ? Ou au contraire avez-vous manqué de formalisme ? Étiez-vous à l'aise avec la méthode employée sur le projet ?
Capitalisez sur votre travail
Vous avez réalisé un manuel utilisateur de qualité ? Vous avez amélioré la description de vos use case ? N'hésitez pas à reprendre vos documents afin d'en faire des templates ou des exemples en corrigeant leurs défauts. Cela vous permettra d'une part d'améliorer la qualité de vos livrables au fil du temps et d'autre part de gagner du temps sur votre prochain projet. Vous pouvez ensuite partager vos templates avec les autres MOA de votre société.
Cherchez les projets suivants
Faites un point avec vos sponsors habituels pour voir quels sont les besoins stratégiques qui ne sont pas encore couverts. Faites le tour des utilisateurs également, afin d'identifier des problèmes opérationnels qui ne seraient pas encore remontés. Le meilleur moyen de travailler sur un projet intéressant, c'est encore d'aller le chercher.
La fin d'un projet n'est jamais simple. C'est souvent une phase fortement chargée pour la MOA qui doit gérer la conduite du changement. Il faut être très présent. Et assez rapidement, tout s'arrête. Il faut alors savoir gérer la transition avant le ou les projets suivants. Soyez fort, on passe tous par là, surtout lorsque le projet est une réussite. Bizarrement, plus le projet est un échec, moins on a de mal à s'en défaire...
