Vous êtes Business Analyst prestataire et vous avez l’impression que chacune de vos missions débute systématiquement par une interminable période de montée en compétence ? Vous allez prendre vos fonctions de Business Analyst comme collaborateur interne chez votre nouvel employeur, et vous souhaitez vous préparer au mieux face aux difficultés qui vous attendent ? Dans cet article, je vous décris les 17 défis du Business Analyst en début de mandat.
La Business Analyse: une discipline en soi
Plus qu’un métier, la Business Analyse est une discipline, que de nombreux professionnels peuvent être amenés à pratiquer en partie et ponctuellement tout au long de leur carrière, parmi leurs autres activités.
En revanche, quand on parle du métier de Business Analyst, on évoque un(e) professionnel(le) qui intervient lorsqu’une Organisation doit implémenter une solution en réponse à un problème ou à un désir de changement.
C’est en effet à lui ou elle que revient la responsabilité de recommander, décrire et mettre en œuvre la meilleure solution possible en fonction de la vision stratégique, des besoins métiers et des nombreuses contraintes internes ou externes.
Business Analyst IT et non-IT
Cette « meilleure solution possible » peut tout aussi bien être liée au système d’information de l’organisation, que non-IT – par exemple, lors de la mise en œuvre d’une conduite du changement, de l’amélioration de la chaîne de processus ou de la gouvernance d’entreprise.
Il arrive fréquemment que ce soit une combinaison de tout cela, conduisant à l’intervention de plusieurs professionnels de la business analyse, chacun spécialisé dans un domaine spécifique.
Par exemple : le « consultant en réorganisation » côtoiera l’AMOA (assistant à la maîtrise d’ouvrage) intégré au pôle métier, et côté maîtrise d’œuvre, réalisatrice de la solution informatique, on trouvera le Business Analyst en SI en support du Product Owner au sein d’une équipe agile, voire d’un expert en Business Intelligence, en ERP ou autres CRM.
Un métier qui demande une grande adaptabilité
Un Business Analyst n’a donc pas forcément ce « titre » sur sa fiche de poste ou sur son bulletin de salaire, mais dans cet article, je vais me focaliser sur celles et ceux qui sont clairement identifiés comme BA par leur employeur ou leur client final.
Pouvant intervenir comme prestataire externe porté par une ESN ou un cabinet de conseil, ou comme collaborateur interne de l’Organisation cliente, salarié ou freelance, le Business Analyst doit faire preuve d’une très grande adaptabilité et ouverture d’esprit, et ce, tout au long de sa carrière.
Surfant sans arrêt de changement en changement, pour lesquels on lui demande de trouver des solutions, il doit avoir le goût de la nouveauté, être curieux, et ne pas craindre de sortir fréquemment de sa zone de confort.
Des défis à relever à chaque stade d’une mission
Malgré toutes ces appétences pour une vie professionnelle rythmée et pleine de surprises, les Business Analysts peuvent se sentir submergés par le volume d’informations hétérogènes à recueillir et à analyser, alors qu’ils ne possèdent initialement pas ou peu d’expertise métier sur le domaine économique de l’Organisation demandeuse.
Comprendre les défis des débuts de missions ou de prise de poste est indispensable pour optimiser une montée en compétence rapide du Business Analyst.
A mon sens, celle-ci peut se découper en plusieurs phases : les premiers jours, les premières semaines, une période allant environ du deuxième au sixième mois, et au-delà de 6 mois.
Les défis des tous premiers jours
Un Business Analyst qui débute dans un secteur et une entreprise qu’il ne connaissait pas auparavant fait face à de nombreux défis lors des tous premiers jours de sa prise de fonction.
Les principaux sont les suivants :
- [1] Comprendre le « métier » de l’organisation: affrêtement maritime, aéronautique, exploitation autoroutière, bateaux de croisières de luxe, ou encore banques, télécoms, nucléaire, publicité, … Recommander et concevoir une solution qui tient compte des spécificités sectorielles nécessite de les appréhender finement. Au tout début, évidemment, on ne se focalise que sur les grandes lignes. Tels des acteurs qui apprennent leurs nouveaux rôles, il est indispensable de comprendre le contexte sectoriel dans lequel nous allons travailler. Et ça n’est pas facile !
- [2] Savoir qui fait quoi dans l’équipe / chez le client : recueillir les besoins de manière exhaustive, puis les vérifier, les valider (ce qu’on appelle l’élicitation) avant de pouvoir effectuer nos analyses, recommander et concevoir la solution nécessite de très nombreuses interactions avec les parties prenantes et les contributeurs. Comment identifier auprès de qui nous adresser tout en nous assurant que c’est réellement la BONNE personne .
- [3] Savoir par où commencer
Contrairement à certains rôles (comme celui de développeur informatique), un Business Analyst ne sait pas forcément quelles sont les activités, tâches, et livrables qui lui incombent, ni à quelle échéance ceux-ci sont attendus par les autres membres de l’équipe ou par le client final.
Etablir sa feuille de route personnelle est donc l’un des défis majeurs à surmonter lorsqu’on débute. Dans le meilleur des cas, un chef de projet donne les grandes lignes. Mais beaucoup de tâches de Business Analyse sont invisibles à ses yeux, alors qu’elles sont chronophages et indispensables à la réalisation des livrables projet. Et dans de nombreuses situations, notamment sur les petits projets où le BA est polyvalent et a la charge de sa propre gouvernance, c’est à lui d’établir sa road map.
Quand on est débutant, on ne sait en général pas du tout par quoi commencer, et je peux vous assurer que c’est un réel challenge dans les tous premiers jours (et au-delà).
- [4] Obtenir de l’information utile et compréhensible pour notre niveau de connaissance actuel (donc, de débutant…).
En effet, aller interroger des experts qui éprouveront de la difficulté à se mettre à notre humble niveau, et à prendre du recul avec le jargon et les acronymes qu’ils manipulent sans même s’en rendre compte, n’est pas pertinent dans les premiers jours de prise de poste.
Notre contributeur idéal ? Celui ou celle qui vulgarise et synthétise son métier, et qui visualise ce qui peut nous être utile (à notre place, parce qu’à ce stade, toutes les informations se ressemblent !) sans se perdre dans les détails.
- [5] Aller vers les autres qu’on ne connaît pas encore
Pour un Business Analyst, il est fondamental d’être connu et reconnu pour recueillir de l’information pertinente. Si personne ne sait ce que vous faites, ni à quoi vous pouvez (leur) servir, vous risquez de passer à côté d’informations et de réunions importantes.
Prenez donc garde à ne pas rester dans votre coin à lire de la documentation 8 heures d’affilée pendant ces premiers jours, en attendant d’être sollicité(e). Il est normal de se sentir intimidé(e) en début de mission, mais un bon BA doit savoir passer outre pour se présenter aux autres collaborateurs (et peut-être futurs utilisateurs de la solution cible).
Les 5 enjeux principaux des 2 premiers mois
Passés les premiers jours de brouillard londonien, le ou la Business Analyt en sait un petit peu plus, et il ou elle commence à être invité(e) à diverses réunions. S’il /elle est rattaché(e) à une équipe projet (en mode « build » ou « run »), il est probable que le chef de projet ou un manager hiérarchique lui ait transmis des éléments de planification. Il ou elle a également en ligne de mire ses premiers livrables ou tâches à réaliser.
A ce stade où le brouillard laisse peu à peu la place à de la brume, voici les défis que rencontrent la majorité des business analysts :
- [6] Réussir à s’organiser
Un écueil fréquent est de naviguer à vue, d’être réactif et non proactif, de percevoir une vue d’ensemble partielle et non complète, et de-ci de-là, quelques détails saillants (pas forcément les plus importants). Attention également à la réunionite aigue qui commence à s’installer. Je veux dire par là que dans les premières semaines, si votre rôle de BA est bien compris, vous pouvez être invité(e) à pleiiiin de réunions, sans savoir en quoi celles-ci peuvent vous être utiles.
- [7] Réussir à trouver sa place dans l’équipe projet.
Cette difficulté est particulièrement vraie pour les BA qui travaillent dans un contexte agile, et cela a un impact considérable sur le point précédent. Pour ne pas avoir la sensation d’être le bouche-trou de l’équipe ou du Product Owner (PO), commencez par bien identifier les rôles et responsabilités de chacun, ainsi que la plus-value que vous pouvez apporter au produit, au projet, et à vos collègues.
Si vous pensez que ce n’est pas à vous, Business Analyst, de mener cette réflexion, vous n’avez pas tort… Mais si personne ne le fait (manager, CP, PO…), mieux vaut prendre les devants le plus tôt possible.
- [8] Obtenir les noms des « bons » contributeurs, c’est-à-dire ne pas se satisfaire des noms que votre chef de projet ou manager vous aura donnés.
A ce stade, vous avez impérativement besoin d’identifier les contributeurs qui apportent une information pertinente à la granularité voulue, c’est-à-dire :- Soit suffisamment synthétique qui met en lumière la photo globale,
- Soit très détaillée, par exemple pour la phase de conception fonctionnelle,
- Soit permettant de comprendre la vision stratégique,
- Soit permettant de comprendre les interactions avec d’autres systèmes (projets ou thématiques connectées, contraintes à prendre en compte etc).
Obtenir les noms des « bons » contributeurs est un travail d’élicitation à part entière, c’est ce qui sécurisera le recueil exhaustif, fiable, vérifié et consensuel de la matière première dont sera issue la solution cible : l’information.
- [9] Mettre en œuvre la stratégie d’engagement des contributeurs.
En tant que Business Analyst, le prérequis est d’avoir réussi la première phase d’appropriation du projet, de comprendre les objectifs, le périmètre, et la feuille de route. C’est ce qui nous permet d’identifier par la suite les profils de « bons » contributeurs, et de préparer la stratégie d’engagement de ces derniers.
En effet, même si un contributeur est sur le papier « l’expert qu’il vous faut », il ou elle n’est pas forcément aussi mobilisé(e) que vous l’êtes sur la réussite du projet. Sans doute a-t-il déjà un poste très accaparant, des managers opérationnels auxquels rendre des comptes en priorité, et parfois peu de motivation personnelle pour vous livrer son expertise métier.
Quelques semaines après votre arrivée, il s’agit donc d’un défi important, souvent négligé et quasi-invisible alors que c’est un point fondamental pour réussir la suite de votre mission de Business Analyst.
- [10] Commencer à produire de la valeur
Passés les premiers jours où on vous laisse en général prendre vos marques, il est important de commencer à apporter une plus-value assez rapidement. J’ai pu constater que cette attente, pas forcément exprimée par vos managers ou par l’équipe projet, a comme un plafond de verre aux alentours de la fin du deuxième mois anniversaire de votre arrivée.
Selon le contexte projet, et la nature de votre intégration (collaborateur interne ou prestataire externe), sachez qu’à cette échéance, vous devrez avoir démontré votre valeur ajoutée d’une manière ou d’une autre. Il ne s’agit pas forcément de livrables projets officiels (analyses, spécifications etc), mais au moins de rapport d’étonnement, d’une feuille de route interne, de recommandations méthodologiques, d’ateliers de travail, de comptes-rendus de réunions ou autres analyses et conseils.
En effet, c’est à peu près à cette échéance (entre 1 et 2 mois) que le client ou le manager estime que le BA doit vraiment être capable de produire quelque chose de concret.
Une période critique : entre 2 et 6 mois
Ça y est, vous avez enfin commencé à prendre vos marques, et votre agenda s’est rempli d’activités productives. Pour autant, bien des Business Analysts débutants et même expérimentés font face aux défis suivants :
- [11] Le syndrome de l’imposteur
Vous êtes entouré(e) d’experts. Experts métiers, experts IT, chefs de projets etc. Avoir l’impression que tout le monde a une expertise, sauf vous, conduit beaucoup de BA à se sentir illégitimes pour produire recommandations et autres descriptions d’une solution qui devra apporter de la satisfaction aux utilisateurs finaux. Au début de votre projet / mission, ne pas vous sentir expert était acceptable, mais cela ne doit plus être le cas par la suite, pensez-vous (à tort, voir le point suivant).
- [12] Se faire prendre pour un expert métier par l’équipe technique et devoir leur faire comprendre qu’on ne peut pas répondre tout de suite à toutes leurs questions.
Même après être monté(e) en compétence sur les thématiques métiers, un BA doit a minima vérifier sa bonne compréhension, la pertinence de sa réponse, ou encore qu’il / elle n’a pas oublié des cas aux limites ou des exceptions. Cela passe donc souvent par de l’élicitation (lecture de documentation, analyse d’interfaces, ateliers collaboratifs etc).
- [13] Eviter de se faire déposséder de ses responsabilités fonctionnelles par l’équipe technique ou le chef de projet.
Certains CP ou développeurs préfèrent faire vite, quitte à (faire) refaire derrière, pour des raisons de planning, de contrat ou autres. Si un BA ne rend pas assez rapidement ses analyses ou éléments de conception fonctionnelle – quand bien même on lui aurait fixé des objectifs inatteignables car mal évalués – il ou elle peut se faire « by-passer ».
Il arrive que dans une équipe où le rôle et les responsabilités du Business Analyst ne sont pas assez identifiés et reconnus, ou en raison du manque d’expérience du chef de projet, que celui-ci ou l’équipe de développement, trop pressés de finaliser un développement prévu ou de ne pas mettre en retard un planning mal ficelé, prennent des décisions sans les valider fonctionnellement avec le BA.
Si vous vous reconnaissez dans ce cas de figure, vous savez comme cela peut être impactant pour la qualité de la solution cible, et donc pour la satisfaction utilisateur. Et en général, le BA se retrouve dans une situation délicate où il/elle est pris dans un conflit de loyauté entre son employeur (s’il s’agit d’une ESN en charge de la maîtrise d’œuvre, par exemple), et le client envers lequel il s’est engagé à concevoir une solution fonctionnelle de qualité.
Cette difficulté est majoritairement ressentie par des Business Analysts déjà bien « installés » dans le projet, soit au-delà de 4 à 6 mois en moyenne.
Les enjeux principaux au-delà des 6 mois
Si vous croyez que votre vie de Business Analyst va enfin être un long fleuve tranquille une fois que vous vous sentirez à l’aise avec votre projet et vos collègues, j’ai le regret de vous dire que d’autres défis vous attendent.
Ne vous méprenez pas : j’adore mon métier, et si vous lisez mes publications, vous savez que je suis plutôt du type « bisounours », à présenter des facettes passionnantes de notre belle discipline! Mais il est vrai que parfois, on peut se décourager, ou être fatigué(e) de devoir sans cesse nous adapter.
Voici les difficultés que beaucoup de BA m’ont rapporté vivre après environ 6 mois de projet / mission :
- [14] La gestion du temps
En tant que chaînon reliant les pôles métiers, les équipes de dév et la gestion de projet, un BA est sollicité de toutes parts, tout le temps et par tout le monde, dès lors qu’il y a un questionnement métier. Vous devrez apprendre à gérer votre temps, pour faire face aux nombreuses réunions, urgences et demandes de dernière minute, tout en gardant votre capacité à livrer vos analyses, spécifications fonctionnelles, user stories, documents de formation utilisateurs et autres plans de tests dans les temps impartis.
- [15] Etre proactif(ve) et pas seulement réactif face aux urgences
Découlant directement du point précédent, la proactivité est en effet une attitude importante quand on est Business Analyst, pour garder de la hauteur sur la vision d’ensemble et conserver l’alignement de la solution cible sur les objectifs stratégiques et métiers initiaux.
- [16] Réussir à se positionner comme un conseiller et non comme un simple exécutant.
Les schémas de certification internationaux à la Business Analyse ne sont pas tous d’accord sur la place du BA.
Pour IIBA, schéma historique de la Business Analyse fondée à Toronto en 2004, le BA est le conseillé avisé du chef de projet, du client et de l’équipe technique.En revanche, le PMI, influencé par sa culture « chef de projet », voit davantage le Business Analyst avec un lien de subordination entre lui et le chef de projet.Personnellement, j’adopte la vision IIBA, qui me permet de travailler en accord avec la philosophie de l’analyse métier et de viser la satisfaction utilisateur et client avant toutes choses.
- [17] Le syndrome de l’imposteur peut s’intensifier à ce stade.
Car même après 6 mois sur un même projet, sachez-le, un BA n’est toujours pas expert métier parlant à la place des utilisateurs finaux. Et il ne devrait pas l’être – quand bien même sa connaissance métier serait conséquente -, sous peine de passer à côté de nombreux besoins non exprimés.
En Business Analyse, la technique de l’egoless programming est en effet une posture très utile pour recueillir les besoins latents, cachés, et inconscients. Or beaucoup de chefs de projets, managers ou développeurs travaillant avec des BA pensent à tort qu’au-delà d’un certain temps de “séniorité”, ceux-ci sont censés en savoir autant que les utilisateurs finaux. Les BA se sentent donc en décalage entre la manière dont ils sont perçus, et le fait qu’ils ne possèdent évidemment pas la science infuse.
Enfin, il faut savoir que l’immense majorité des Business Analysts s’est formée sur le tas à son métier, et ne dispose donc pas des bonnes pratiques, techniques et méthodes de la profession.
Beaucoup d’employeurs de BA pensent qu’être Business Analyst revient à avoir des connaissances ou un diplôme en économie de gestion et en management, ainsi que des bonnes capacités de communication, d’analyse et de synthèse. Les Business Analysts se sentent donc parfois (souvent) durant de longues années perçus à tort comme plus compétents qu’ils ne pensent eux-mêmes l’être.
Et pourtant, je vous l’assure, vous qui m’avez lu(e) jusqu’au bout: si vous êtes Business Analyst, soyez fier/fière de vous et de votre parcours!
Fier/ère de votre capacité à comprendre et à résoudre des problèmes, à faire le lien entre un nombre infini d’informations hétérogènes, à vous adapter au changement, à apprendre constamment de nouvelles choses et à concevoir dans le détail des solutions dont la plus-value n’existe encore que sur le papier.
Soyez fier/ère d’être si autonome et créatif/ve, résilient(e) et à l’écoute constante des besoins tant des utilisateurs et que des managers, soucieux(se) de fournir la meilleure solution possible en dépit des nombreux défis et contraintes qui jalonnent votre chemin.
Alors soyez-en sûr(e): relever ces 17 défis, inhérents aux débuts de missions ou de prise de fonction comme Business Analyst, est à votre portée!
