La profession de BA

Le dilemme des évolutions de poste quand on est Business Analyst

Le dilemme de l"évolution de carriere du business analyst

Vous êtes Business Analyst et votre hiérarchie vous propose d’évoluer vers un poste de Product Owner ou de Project Manager. Vous hésitez, car d’un côté, il vous semble que c’est une promotion professionnelle plutôt bénéfique à votre carrière, mais de l’autre, vous n’êtes pas sûr(e) que ce nouveau poste vous plaira.

Et vous n’êtes pas le ou la seul(e) à vous poser la question ! La réponse est bien entendu personnelle, mais je vous propose quand même ici de faire le tour de la question pour vous aider à prendre cette importante décision…

La confusion des genres

Franchement, même si on travaille depuis longtemps dans les projets de systèmes d’information, on en arrive parfois à s’y perdre sur le « qui fait quoi ». Avant, c’était simple, on avait une organisation pyramidale avec, en haut de l’organisation projet, le chef de projet, puis le développeur, le graphiste et l’administrateur (DBA).

Ensuite, on a eu l’architecte technique, le leader technique, l’intégrateur, et le consultant fonctionnel (AMOA).

Sont également apparus l’expert solution (ERP, BI, CRM, PLM…), le PMO (Project Management Officer), l’architecte fonctionnel, l’UX/UI(User eXpérience / User Interface), le Product Owner (PO), le Projet Manager (PM – ah, c’est sans doute pareil que le chef de projet ?),le business analyst technique, le Business Analyst processus, le Release Train Engineer (RTE), le Scrum Master, le Business Owner…

Aïe. Je vous ai perdu(e) ? Pas évident de préparer une évolution de carrière face ce brouillard d’acronymes et de nouveaux rôles !

>> Lire aussiLe cauchemar des acronymes (Le Petit Guide de survie pour une communication claire)

 

Le rôle dépend de l’organisation

Vous pouvez surfer sur internet à la recherche de la description précise du poste convoité (ou proposé par votre hiérarchie), vous trouverez beaucoup d’informations parfois contradictoires. Par exemple, le Projet Manager est parfois assimilé au Product Owner. Mais le Business Analyst l’est aussi. Mais attendez… le Business Owner ne serait-il pas un Product Owner ? Et le développeur agile un business analyst ? Et qu’en est-il de l’expert UX/UI ? Il élicite, propose la meilleure ergonomie et interface graphique possible, fait du mind mapping… donc ne serait-il pas un Business Analyst, lui aussi ?

>> Lire aussiPourquoi et comment concevoir les maquettes de vos applications

En réalité, même si les approches et méthodes de gestion de projet décrivent les rôles et responsabilités de manière plus ou moins précise, ces dernières varient énormément d’une organisation à une autre.

>> Lire aussiOù s’arrête le rôle du Business Analyst (et où commence celui de l’équipe technique)

 

Les méthodes agiles tendent à aplanir voire supprimer l’organisation pyramidale

Au temps du monopole de la gestion de projet en V ou en cascade, c’était simple de s’y retrouver. Le chef de projet était vraiment le chef de l’équipe. C’est lui qui donnait le tempo, allouait la charge de travail et définissait les deadlines (entre parenthèses, on dit « dead » lines pour le respect des jalons intermédiaires… alors qu’on parle Go « Live » pour la mise en production du logiciel cible. La carotte et le bâton de l’organisation traditionnelle ?). C’est le chef de projet qui acceptait ou non le périmètre fonctionnel, trouvait le budget, et faisait tampon entre l’équipe technique et les desideratas du client.

>> Lire aussiPourquoi le document de cadrage est-il si important ?

Mais avec l’avènement des méthodes agiles, le chef de projet n’a plus de rôle dédié, tout comme (entre autres) le Business Analyst. C’est à présent le Product Owner (PO) qui priorise, donne le rythme, définit le périmètre. Il est tout à la fois chef d’orchestre, expert métier, représentant de la maîtrise d’ouvrage et bienveillant superviseur de la maîtrise d’œuvre.

Bien entendu, comme la tâche du PO est titanesque, il délègue la plupart du temps une partie de ses activités. Et on retrouve, sous d’autres noms souvent, le Project Manager / chef de projet MOE, et le business analyst (qui peut être appelé « deputy Product Owner »)

De son côté, le Scrum Master n’a de « maître » que le nom. Etymologiquement, le maître est celui qui commande ou dirige (issue de l’ancien français « maistre »). Mais dans le framework Scrum, il n’a en réalité « que » les prérogatives d’un coach et d’un facilitateur.

La première valeur du manifeste Agile indique que l’agilité est un état d’esprit, privilégiant les individus et leurs interactions plus que les processus et les outils.

Normalement, donc, il n’y a plus de chef dans un projet organisé de manière agile. Mais il faut bien l’admettre, la société occidentale et française en particulier, même si elle décrit ses chefs, a du mal à se mettre d’accord et à avancer sans hiérarchie, sans roi pour trancher les divergences et faire appliquer une vision commune.

La position hiérarchique vs le rôle au sein du projet

Au sein d’une même organisation, certains projets sont gérés de manière agile, d’autres de manière traditionnelle.

Le choix de la méthode de gestion de projet dépend en effet de plusieurs facteurs, dont la complexité du projet, la disponibilité des contributeurs, la gestion du risque, la compétence de l’équipe projet, la flexibilité de l’enveloppe budgétaire et des délais, et la formation des parties prenantes.

C’est là qu’intervient un troisième facteur de confusion. En effet, un collaborateur peut avoir une position hiérarchique – et donc une fiche de poste – bien définie au sein de son entreprise, tout en ayant, au gré des projets de son organisation, un rôle de Product Owner, de Sponsor, ou encore de Project Manager.

Toutes ces raisons expliquent pourquoi il est si difficile d’identifier les avantages et inconvénients d’une évolution de poste.

En réalité, l’intitulé du poste seul n’apprend rien.

Pour accepter ou demander une « promotion », commencez par réclamer une fiche de poste ou de mission très détaillée.

Vérifiez également votre rattachement hiérarchique, qui peut être très différent du rattachement opérationnel. Cela vous permettra d’identifier si vous aurez une relative facilité à faire appliquer vos décisions ou recommandations, ou si vous aurez à vous battre bec et ongles pour faire avancer vos projets.

N’oubliez pas que l’une des causes majeure d’échec des projets informatiques est liée aux conflits « stratégiques » entre managers. Cela a donc son importance pour vous aider à choisir votre évolution de carrière…

>> Lire aussiPourquoi 83% des projets informatiques échouent-ils?

Quelques témoignages

Comme à mon habitude, je suis allée me balader sur les forums anglo-saxons. J’aime bien lire les problématiques rencontrées par nos confrères et consœurs Business Analysts, car elles reflètent, avec quelques années d’avance sur nous autres, francophones, ce que sera notre quotidien professionnel dans un proche futur.

Voici donc quelques témoignages significatifs (j’ai changé les noms pour garder l’anonymat) pour conclure cette réflexion…

La question de Charlie

« J’aime vraiment mon rôle de business analyst. C’est là que je peux utiliser au mieux mes points forts pour analyser les processus, amener les parties prenantes à réfléchir réellement à leurs besoins actuels et futurs et, d’une manière générale, guider les gens dans des transitions complexes et techniques. Ce que je préfère, c’est mener l’analyse métier de A à Z, depuis la compréhension des processus métier, en passant par la conception de la solution jusqu’aux tests et à la formation des utilisateurs. J’aime beaucoup voir une vision se concrétiser en logiciel.

Cela dit, mon job m’amène à jouer de plus en plus le rôle de Project Manager et je n’ai pas l’impression que cela me réussisse autant. Les chefs de projet doivent avoir beaucoup de sang-froid et d’autorité, et ils ont beaucoup de travail administratif. Il y a ces rapports financiers interminables, les burn down charts, le suivi des heures réalisées par l’équipe technique, mais aussi la partie la plus importante du travail du Project Manager, qui consiste à constamment veiller à ce que le projet ne déraille pas.

Je ne dis pas que c’est mal, mais j’ai juste l’impression que cela ne me correspond pas. C’est une vision binaire en tout noir ou tout blanc, alors que, d’après moi, un Business Analyst est beaucoup plus dans la nuance. Le Business Analyst challenge ses contributeurs, mais pas de la manière dont le fait le chef de projet. En réalité, il s’agit plutôt de les aider à remettre en question leurs processus de pensée et à toujours se demander pourquoi. Il s’agit de les amener à étayer leurs « besoins » grâce par exemple, à des analyses de rentabilité, sans pour autant systématiquement remettre en question leur budget ou leurs attentes.

Avez-vous déjà réussi dans ces deux rôles, de Business Analyst et de Project Manager ? Comment puis-je mieux m’adapter à cette perspective que doit avoir le chef de projet, moi qui suis plutôt une personne chaleureuse et nuancée ? »

Les réponses d’autres business analysts…

Je ressens exactement la même chose que toi. Je suis un excellent Business Analyst / Business System Analyst / Product Owner, mais je pense que je démissionnerais si on me demandait d’être Project Manager.

Bien sûr, c’est plus d’argent et un avancement de carrière, mais rien que de penser devoir rester assis toute la journée à faire des diagrammes de Gantt et à établir un budget…

Quoi qu’il en soit, cela ne veut pas dire que je ne peux plus évoluer professionnellement, je peux par exemple regarder du côté des postes de Product Management. En fait, je pense que le poste de Product Manager est un mélange entre Business Analyst et Product Owner, qui permet de faire tout ce que l’on aime accomplir en tant que Business Analyst, avec une plus grosse rémunération et une meilleure reconnaissance. C’est en tout cas cette position que je vise à présent.

Julian

Pareil. Je suis constamment contraint par ma hiérarchie d’assumer des responsabilités de chef de projet. Je leur répète simplement que je ne suis pas PM mais que je ferai de mon mieux…

Joshua

Si je suis passée d’un poste de Business Analyst (BA) à celui de Project Manager (PM)? Pas vraiment, mais je fais certainement des tâches de chef de projet dans le cadre de mes activités de BA. Mais ce n’est pas tout le périmètre du rôle de PM. 

Kelly

Je suis de tout cœur avec vous. J’ai dit à mon manager que je ne suis pas du tout intéressé par les rôles de type Project Manager. J’aime le travail de détective que l’on fait en analyse métier, cela me procure une vraie joie. Je suis tout à fait d’accord pour développer d’autres compétences de business analyse, mais la paperasserie, cocher des cases et faire des calculs dans tous les sens comme le fait le project manager ne m’attire pas du tout.

Heureusement, il y a d’autres voies de progression de carrière dans mon entreprise. 

Evan

J’ai été un certain temps chef de projet, et je me suis reconverti en tant que business analyst. Je ne suis tout simplement pas assez ferme ni autoritaire pour être un bon Project Manager et j’étais, franchement, très mauvais dans ce domaine…

Une chose à propos d’être à la fois Business Analyst et Project Manager : quand les choses vont bien, tout va bien mais… quand elles vont mal, on se sent très seul ! Je suis tout à fait favorable à ce que ces deux rôles soient séparés.

Dans beaucoup d’endroits où j’ai travaillé, il est commun de penser que le poste de chef de projet est l’étape suivante dans la carrière d’un business analyst. Je ne comprends pas du tout. Les compétences requises sont très distinctes et c’est presque offensant pour notre profession ! Personnellement, je pense que le rôle du Business Analyst est tout en nuance, alors que ce qui est attendu d’un chef de projet, c’est d’être au contraire tranchant comme un couteau. 

Kevin

Et vous, qu’en pensez-vous? Partagez votre opinion en commentaire 😉 

Cet article vous a plu? Partagez-le et suivez-moi sur les réseaux sociaux!

Share on facebook
Share on twitter
Share on linkedin
Alice Svadchii
Alice Svadchii
Auteure du blog et Business Analyst enthousiaste

7 réflexions au sujet de « Le dilemme des évolutions de poste quand on est Business Analyst »

  1. Je pense qu’un bon business analyst peut faire des choses bien plus importantes qu’un chef de projet. Le chef de projet est un rôle limité à certaines frontières. Mais un business analyst peut tout faire, tout proposer. J’aime plus le rôle de business analsyt que celui de chef de projet. Je veux être business consultant à un niveau supérieur.

    1. Même constat en ce qui me concerne… J’ai été chef de projet et directrice de projets, mais ce que j’aime, c’est mettre les mains dans le cambouis, c’est la communication, c’est améliorer le quotidien des utilisateurs…. Je préfère largement mon rôle de Business Analyst!

  2. Je me reconnais tellement dans les propos de Charlie … Ce que j’ai vu d’un CP ne me correspond pas, j’ai beaucoup de respect pour cette fonction de CP malmenée ces derniers temps ( pour la fonction nouvelle, pas pour ce que j’en ai vu en application réelle malheureusement ). J’ai essayé PM et j’ai très vite déchanté. Et pourtant en France , un AF qui n’a pas souhaité devenir CP ou autre, on ressent qu’il a loupé sa carrière, c’est stupide à mon sens. BA est plus à la mode …

    1. idem pour les développeurs qui veulent continuer à coder… Passé 30 ans, c’est des « losers sans ambition ». Aux US, ce sont des experts recherchés, payés plus cher que les CP. Question de culture…

  3. Hello Alice, ton article est très intéressant… encore une fois ! Les débats entre les rôles au sein d’une organisation sont éternels… et je pense qu’il faut envisager de voir les choses suivant le point de vue des compétences (cad. le métier, la profession) d’un côté et le point de vue du rôle d’un autre côté. Dans certaines entreprises, il y a une distinction entre le BA et le PO car le BA sera considéré comme un métier (on est avant tout un analyste), alors que le PO n’est qu’un rôle (celui par exemple qui est identifié dans Scrum). Le rôle n’a de sens que dans un contexte donné. Ainsi, j’aime bien prendre l’exemple du cinéma où l’acteur va jouer un rôle dans un film. Etre acteur c’est son métier, cela demande des compétences particulières, et le rôle, c’est le personnage qui est joué dans le film dans un environnement et un scénario particuliers. Voilà pour faire avancer le sujet…

    1. Merci beaucoup Stéphane, ton commentaire est très intéressant également. C’est amusant ce parallèle que tu fais avec le jeu d’acteur… Je l’emploie régulièrement pour expliquer pourquoi j’aime ce métier de BA. Quand on élicite, quand on essaie de cerner les besoins métier et la vision de l’entreprise, se mettre dans la peau de nos contributeurs permet de développer notre empathie, d’être le plus qualitatif possible. et de découvrir continuellement de nouvelles choses. Passionnant 🙂

    2. J’abonde vos propos , en Kick-off Agile, le Scrum Master s’est tourné vers le BA et lui a dit « Tu vas jouer le rôle de PO ?
      « , le BA a répondu « Oui cà me va bien ! « 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *