Un chef de projet a des compétences en organisation et en pilotage de projet. De son côté, un Business Analyst possède une expertise en matière de résolution des problématiques métiers existantes ou anticipées. A priori, ces deux experts n’empiètent donc pas sur leurs platebandes respectives. Pourtant, le poste de chef de projet MOA (Maîtrise d’OuvrAge), combinant ces deux rôles, fleurit allègrement dans bon nombre d’offres d’embauche.
Petit disclaimer avant de vous exposer mon point de vue : je n’ai pas voulu me farcir le PMBOK®, qui est le corpus de connaissances du PMI® pour se certifier en tant que chef de projet. Je ne suis donc pas certifiée PMP® (ni un quelconque autre schéma de certification à la gestion de projet), et je tire mon chapeau à celles et ceux qui ont eu l’énergie et la motivation de le faire.
Quoique non certifiée, j’ai pratiqué la chefferie de projet sous diverses casquettes : en tant que Business Analyst, chef de projet MOA, experte fonctionnelle, ou encore directrice de projets, dans des moyennes entreprises comme dans de grands groupes internationaux. Mes excuses donc par avance aux puristes : je réponds dans cet article de manière essentiellement empirique, enrichie de beaucoup d’apprentissage et lectures autodidactes.
Précisons également que je parle essentiellement de chef de projet informatique, mais vous pouvez élargir mon propos à tous domaines, hors des systèmes d’information – ce que j’ai également pratiqué, en tant que Business Analyst métier et gouvernance, avec la casquette de chef de projet en sus.
Les missions d’un chef de Projet informatique
Il y a énormément d’information en libre accès sur la Toile, permettant de se faire une idée précise des responsabilités du chef de projet des systèmes d’information.
Voici la fiche de poste « type » que vous pourrez retrouver dans la plupart des Organisations.
Le rôle du chef de projet informatique (CPI)
- Expert en informatique
- Il a sous son égide plusieurs techniciens
- Garant de l’état d’avancement d’un projet informatique, le CPI doit ajuster les évolutions et les besoins y afférents si cela s’avère nécessaire. Il doit également tenir compte des contraintes en termes de financement et de délais.
Il se doit donc de posséder des compétences techniques et managériales à la fois.
Nature des activités du CPI
Avant-projet : l’élaboration du cahier des charges
Le CPI fait office d’interface entre les différents acteurs, à savoir les fournisseurs, les clients, les ingénieurs, les techniciens, etc.
Il va à la rencontre des clients et définit leurs besoins par le biais d’une série d’études.
Il élabore, par la suite, le cahier des charges. Il doit estimer le temps imparti à la réalisation du projet, le budget à allouer ainsi que les ressources humaines internes ou externes utilisées.
Lire aussi : Pourquoi le document de cadrage est-il si important ?
Pendant le projet : l’activité de suivi de l’avancement du projet
En tant que coordinateur, sa mission est de mener à bien la conception et le développement du projet informatique qu’il a la charge de piloter. En terme plus simple, il est présent sur toutes les étapes du projet. Dans cette optique, il en assume la réalisation de A à Z et est responsable de sa réussite ou de son échec.
En tant que manager, le chef de projet informatique doit encadrer une équipe de développeurs et travaille en collaboration avec des ingénieurs système, des consultants techniques ou fonctionnels, un administrateur de base de données et un architecte technique. C’est lui qui met en place un calendrier de travail avec la répartition des tâches. Et ce, en veillant à ce que le suivi et la coordination du déroulement des réalisations soient respectés. Le CPI communique un compte-rendu régulier à son client comme à son supérieur. Son objectif : finir le projet dans les délais impartis en répondant au mieux au budget et aux attentes exprimées.
Lire aussi : Tutoriel: Conception Fonctionnelle vs. Spécifications Fonctionnelles Détaillées
En règle générale, le CPI intervient dans la phase d’étude jusqu’à la conception et la mise en place du projet avec une équipe de techniciens qui l’aide.
Après le projet : intégration chez le client et maintenance du système
Il organise et assure :
- La mise en place et l’intégration des installations ou du logiciel au sein de l’entreprise cliente.
- Le contrôle qualité afin de mesurer si le produit final répond aux exigences techniques du cahier des charges.
- Les actions correctrices au cas où des dysfonctionnements sont notés.
- L’évolution et la maintenance des applications
Les compétences du Chef de Projet informatique
- Il doit connaître « la technique » : en d’autres termes, le CPI doit être familier avec la technologie informatique.
- Le CPI doit également connaître le métier du client
Cette compétence, souvent citée dans les compétences requises par les organismes de formation et les employeurs, explique en soi pourquoi le rôle de chef de projet et de business analyst fait souvent l’objet d’un amalgame.
En effet, comme le Chef de Projet Informatique entretient un lien direct avec le client, il doit être à son écoute et il doit être capable de traduire plus aisément et rapidement ses besoins métiers et sa vision stratégique. Il doit donc connaître ses domaines d’intervention, ses contraintes internes et externes, et être totalement à l’aise avec l’organisation fonctionnelle de l’entreprise cliente (que ce soit sa propre organisation, ou un client final externe, dans le cas de prestations de services).
Le périmètre et les missions du Business Analyst
La Business Analyse – analyse d’affaires au Québec, ou littéralement en français, analyse métier – est la discipline qui consiste à recommander, définir, et mettre en œuvre la meilleure solution possible, afin de résoudre un problème ou de faire face à un besoin d’évolution exprimé par une organisation.
Lire aussi: Se certifier à la business analyse
Le rôle de Business Analyst
Les réponses que peut apporter la Business Analyse à ce besoin d’évolution sont principalement de 3 sortes :
- Amélioration ou mise en place de la gouvernance,
- Evolutions opérationnelles « métier »,
- Mise en place ou amélioration du système d’information.
Les deux premières catégories ont pour finalité la recommandation, la conception et la mise en œuvre d’une solution non informatique, contrairement au rôle de Business Analyst en systèmes d’information (S.I.) » qui travaille dans le cadre d’un changement matérialisé par une solution de systèmes d’information.
Dans les pays francophones, on le retrouve sous d’autres libellés plus anciens, comme ceux de consultant fonctionnel et d’Assistant à la Maîtrise d’Ouvrage (AMOA), de responsable de qualification fonctionnelle, ou encore de Product Owner, quand il est business analyste décisionnaire sur un projet informatique agile.
Et on le retrouve également sous le libellé « chef de projet MOA », lorsqu’il cumule les rôles de business analyst et de chef de projet pour la maîtrise d’ouvrage.
Un Business Analyst se positionne en chaînon manquant entre de nombreuses disciplines pour garantir qu’on ne perd pas de vue la vision d’ensemble et la valeur apportée par la solution. Il est au carrefour du métier, de la technique et de la gestion de projet.
Activités et livrables de la Business Analyse
La conduite d’un projet débouche sur un produit, un service, une nouvelle organisation, etc. Cette finalité, appelée “livrable”, est le résultat tangible d’une production réelle, appréhendable, mesurable attendue par le client final. Un projet peut, bien sûr, avoir plusieurs livrables. Les livrables attendus par le client sont définis dans le cahier des charges.
Les réalisations intermédiaires d’un projet sont aussi des livrables.
Le livrable produit au moment d’un jalon matérialise concrètement l’achèvement de cette étape.
Voici donc les principaux livrables qu’un Business Analyst rédige. Pour savoir à quoi ils correspondent, et surtout, comment les compléter avec les bonnes pratiques de l’analyse métier, je vous invite à consulter mes formations en ligne 😊.
[Master Class] Devenir Business Analyst en S.I.
Les Fondamentaux de A à Z
50 heures de formation qualifiante complète en e-learning pour se professionnaliser au métier de Business Analyst en systèmes d'information.
Livrables principaux d’avant-projet :
- Étude d’opportunité
- Analyse de faisabilité
- Etude de rentabilité (business case)
Livrables principaux durant le projet (build ou run):
- Cadrage du besoin / du périmètre fonctionnel (gestion de projet traditionnelle) / de la valeur utilisateur à atteindre (approches agiles)
- Gouvernance & pilotage de la BA : indicateurs, feuille de route de la Business Analyse
- Mise en place de l’Ingénierie des exigences (essentiellement dans la gestion de projets traditionnels)
- Analyses de l’existant, des besoins, des exigences, analyse comparative, analyse des écarts, analyse des risques
- Conception fonctionnelle – gestion de projet traditionnelle
- SFG
- SFD
- Glossaire, règles métier (RM), modélisation, maquettes / prototypage / UX – UI
- Conception fonctionnelle – gestion de projet agile
- Product Goal, Product Backlog
- Sprint Goal
- User Story, critères d’acceptance
- Glossaire, règles métier (RM), modélisation, maquettes / prototypage / UX – UI
- Test – Recette :
- Stratégie de test
- Conception des tests fonctionnels
- Implémentation dans les outils de test
- Exécution et reporting des tests
- Documents de formation utilisateurs
Les compétences relationnelles et comportementales du Business Analyst en SI
En dehors des « hard skills » qui consistent à savoir réaliser les activités et livrables précédemment cités, un Business Analyst est également un expert en relations humaines. J’estime que 50% de la compétence globale est liée à ses « soft skills ».
Jusqu’à présent d’ailleurs, un Business Analyst était essentiellement recruté en fonction de son potentiel pour devenir un bon BA, ce dernier étant évalué sur la base d’un ensemble de compétences relationnelles et comportementales, notamment :
- La communication
- La résolution de problèmes
- L’intelligence émotionnelle, l’empathie, la présence à l’autre
- La gestion du temps
- La créativité
- La vision et la visualisation
- Le sens du collectif
- La curiosité
Chef de Projet MOA : info ou intox ?
Maintenant que la distinction entre chef de projet et business analyst est faite (avec un focus sur les projets de systèmes d’information, qui sont de loin majoritaires), peut-on affirmer que la double casquette chef de projet ET business analyst fait sens ?
Pour résumer :
- Le chef de projet informatique est responsable de la définition du cahier des charges, puis du suivi de l’avancement et de la bonne exécution d’un projet informatique en termes de délais, de budget et de qualité de la solution technique livrée. La bonne exécution du projet passe par un rôle de coordinateur des différents intervenants (client, fournisseurs, équipe de développement) et de manager de l’équipe de développement.
- Le Business Analyst en SI est responsable de la valeur apportée par la solution logicielle à la chaîne de valeur de l’organisation cliente. Cela signifie identifier, définir, concevoir et s’assurer de l’adéquation entre la vision stratégique de l’Organisation, ses besoins métier et la satisfaction des utilisateurs et du client final. Pour y parvenir, un Business Analyst met également en place la gouvernance de ses activités, et coordonne les différentes parties prenantes (MOA et MOE) dans l’objectif d’optimiser la satisfaction métier – et non pas, comme le fait le CP, dans une perspective de pilotage du projet.
Théoriquement, on ne peut donc pas être à la fois chef de projet ET business analyst.
Ma réponse empirique : le chef de projet MOA
Nous l’avons vu, il existe de nombreuses offres d’emploi intitulées « chef de projet MOA ».
C’est donc que le besoin existe, le rôle faisant sens dans de nombreuses organisations.
On rencontre ce type de poste assez fréquemment dans les cas suivants :
- Les petits projets, sur lesquels il y a assez peu de moyens / de ressources. Il est donc courant qu’un professionnel cumule toutes sortes de casquettes. Ainsi, un Business Analyst va agir pour le compte de la maîtrise d’ouvrage tout en pilotant l’avancement de la réalisation mise en œuvre par des sous-traitants.
- On ne demande en revanche pas à un CP MOA d’avoir des compétences techniques fines. Son rôle est focalisé sur l’animation des parties prenantes, le suivi de la feuille de route, et la vérification de la qualité de l’ouvrage livré.
- L’existence / le besoin d’un CP MOA dépend aussi de l’organisation interne de l’entreprise. Une PME a rarement une équipe métier ou informatique dédiée « projet ». En règle générale, elle assure le bon fonctionnement opérationnel de son système d’information, et n’a pas les ressources pour gérer exclusivement les projets de création ou d’évolution majeure.
Enfin, notez que parmi les activités du Business Analyst, ainsi que ses contraintes opérationnelles, il y a la planification, le suivi de l’avancement, et la coordination entre le « client » (MOA) et le « réalisateur » (MOE).
Ainsi, pour répondre à la question de cet article : « Peut-on être à la fois chef de projet et Business Analyst ? » : oui, on le peut. Personnellement, j’apprécie particulièrement cette double-fonction qui rend notre métier encore plus épanouissant. En revanche, cela peut également constituer un risque de cumuler autant d’activités seul(e), sur une période et avec des ressources restreintes. Je recommande donc de remonter avec transparence à sa hiérarchie tout goulet d’étranglement ou compétences manquantes, afin de sécuriser la qualité de la solution cible et celle du projet.
Cet article vous a plu? Partagez-le et suivez-moi sur les réseaux sociaux!
