Dans les projets de grande envergure avec une grande maturité, il est intéressant d’avoir des Business Analysts travaillant de pair avec les chefs de projets.
Il est souvent récurrent de confondre chef de projet et Business Analyst. Les descriptions des postes ne sont d’ailleurs pas claires dans les projets et beaucoup de chefs de projet répondent aux deux types d’annonces.
Pourtant les deux n’ont pas les mêmes responsabilités ou objectifs, il est nécessaire pour les entreprises ainsi que pour les professionnels de bien connaître les périmètres et différences de chacun.
Lorsqu’ils se côtoient, des conflits dus aux missions de chacun peuvent naître.
Le Chef de projet a du mal à suivre les évolutions des besoins en permanence de la part du Business Analyst tandis que le Business Analyst reproche au chef de projet de privilégier le planning au détriment de la valeur.
Nous verrons dans cet article, les rôles de chaque poste pour ensuite bien mettre en avant la collaboration efficace et optimisée clé du succès des projets.
Le Chef de Projet garant du comment
Le chef de projet est le chef d’orchestre du projet, son rôle est de coordonner toutes les activités du projet pour mener les projets au succès.
Le succès sera déterminé par ses objectifs ainsi que la valeur apportée à l’entreprise/l’organisation. Il devra respecter et suivre le budget, les délais et la qualité prédéfinis.
Pour cela, il planifie, organise et communique en continu tout au long du projet.
Voici quelques-unes de ses responsabilités :
- La planification et le suivi des tâches
- La gestion des risques et des dérives
- La gestion des parties prenantes
- Le reporting
Son but est de livrer mais livrer ne suffit pas si ce qui est livré n’est pas ce qu’il faut.
En effet, en continuant de livrer le projet en suivant le planning et sans comprendre les enjeux du projet actualisés, le chef de projet risque de réussir le projet avec tous les KPI au vert mais qui n’apportent aucune valeur.
Exemple :
Dans un projet de développement d’application, le chef de projet et ses développeurs développent et livrent toute l’application suivant le cahier des charges par rapport uniquement à leur compréhension.
Pourtant lorsqu’ils ont livré l'application, ils se sont retrouvés face à une insatisfaction forte des utilisateurs, qui leur ont clairement signifié qu’ils ne pouvaient pas l’utiliser.
Ils ont donc rejeté l’application avec les arguments suivants :
- « On va devoir continuer à utiliser Excel à côté »
- « On prend plus de temps qu’avant. »
- « Notre travail s’en trouve complexifié »
Le projet n’était pourtant pas en retard, le budget tenu mais la valeur est faible !
L’équipe est obligée de lancer des demandes de changement tardives et coûteuses.
Au-delà de cela, la crédibilité du chef de projet en pâtit et l’équipe perd sa motivation.
Faire intervenir un Business Analyst aurait changé la donne.
Le Business Analyst : gardien du pourquoi et du quoi
En effet, le Business Analyst (ou BA) est l’interprète entre le métier et la technique. Sa mission est de comprendre, formaliser et valider les besoins réels.
Ce qui revient à garantir que les exigences soient correctement listées, comprises et interprétées.
Voici quelques-unes de ses responsabilités :
- Recueillir les besoins auprès des parties prenantes
- Les traduire en exigences fonctionnelles et non fonctionnelles
- Identifier les incohérences et vérifier la conformité des livrables.
Il donne le sens du projet, dans un environnement agile, il collabore avec le Product Owner pour prioriser les besoins selon leur impact.
Tableau comparatif – Chef de Projet vs Business Analyst
Pour récapituler, voici un tableau comparatif des deux rôles du chef de projet et du Business Analyst :
Axe | Chef de Projet | Business Analyst |
|---|---|---|
Finalité principale | Garantir la pertinence du besoin | |
Objectif clé | Respecter les délais, le budget et la qualité | Maximiser la valeur métier |
Rôle central | Coordonner l’ensemble des activités du projet | Comprendre, formaliser et valider les besoins |
Focalisation | Avancement, jalons, charges, risques | Usage, valeur, cohérence fonctionnelle |
Relation métier | Organise et pilote les échanges | Recueille et clarifie les besoins |
Arbitrage | Peut arbitrer sur le périmètre sous contrainte | Priorise les besoins selon leur impact |
Risque principal | Livrer dans les temps mais sans valeur suffisante | Définir des besoins difficiles à livrer |
Source de tension fréquente | Pression planning et budget | Évolutions tardives des besoins |
Indicateur de réussite | Projet livré dans le respect des contraintes | Solution conforme aux besoins réels |
Complémentarité | Cadre, pilotage, sécurisation | Sens, valeur, cohérence |
Les zones de tension fréquentes
Comme souvent, les sources de tensions proviennent tout d’abord d’un manque de compréhension, surtout que la frontière peut être floue.
Quelques questions que les deux se posent :
- Qui est responsable de la relation métier ?
- Qui arbitre ou valide un livrable ?
Par exemple, dans une entreprise, sur un projet, où le Business Analyst identifie et priorise les besoins.
Le chef de projet peut, sous pression, décider de retirer certaines fonctionnalités pour respecter le budget et les délais.
Pour le Business Analyst, il peut y avoir une perte de confiance.
D’autres sources de tension, comme le langage, la temporalité ou des objectifs différents sont sources de conflits.
Le Business Analyst se concentre sur la valeur ou l’usage tandis que le chef de projet doit tenir compte des jalons, charges et risques.
Cela peut bloquer si des besoins critiques arrivent tardivement et que le chef de projet voit cela comme une menace.
La discussion peut devenir émotionnelle sans cadre clair.
Un cas extrême peut émerger dans un projet de migration vers le cloud de tous les serveurs de l’entreprise.
Le chef de projet consacre beaucoup d’heures à remplir les outils de suivi, à adapter les contenus aux métiers et à répondre aux demandes “urgentes” du management.
Il n’a alors pas le temps d’échanger avec le Business Analyst et ils ne travaillent pas sur l’évolution des besoins.
Le pilotage réel se dégrade, la valeur n’est pas mise en avant.
Les leviers pour instaurer la collaboration
Pour éviter tous ces conflits et ces incompréhensions, il faut mettre en place des mécanismes clairs et engagés.
1) Définition d’un RACI
Dès le cadrage du projet, définir un RACI clair pour bien délimiter les rôles du Chef de Projet, Business Analyst, PMO et métier.
En effet, il est important de déterminer qui est responsable de la définition du besoin, de la priorisation ou encore de la validation finale.
Ces catégories peuvent bien évidemment être déclinées et avoir différents responsables.
Pour être utile, le RACI ne peut pas être générique. Il gagne à être décliné selon la situation.
Il pourrait, entre autres, être décliné en livrable, composante ou segmenté suivant le budget.
Prenons les deux cas suivants :
Cas 1 : Sur un projet de déploiement de CRM si l’on effectue un RACI par livrable
Livrable | Chef de Projet | Business Analyst | Équipe IT | Métiers | RH |
|---|---|---|---|---|---|
Spécifications fonctionnelles | C | R | C | A | I |
Paramétrage CRM | A | C | R | C | I |
Plan de formation | A | C | I | C | R |
Recettes | C | I | R | A | I |
Cas 2 : Sur un projet agile
Étape | Product Owner / Business Analyst | Chef de Projet | Métier | Sponsor | Équipe |
|---|---|---|---|---|---|
Priorisation du backlog | R | C | C | A | C |
Respect des délais | C | R | I | A | I |
Évolution du périmètre | C | R | C | A | I |
Valeur livrée | R | I | A | C | I |
Ici, le Chef de Projet est responsable du respect des jalons.
Le Business Analyst ou Product Owner est responsable de la cohérence des besoins.
Le métier, quant à lui, est responsable de la validation finale.
Il ne faut bien évidemment pas oublier le rôle du sponsor.
Et dans le dernier RACI, il est approbateur de plusieurs actions clés. Il est primordial de l’inclure car il est le garant politique stratégique et décisionnel du projet.
Il est souvent issu du top management et ne peut pas être qu’un simple validateur ou qu’une figure symbolique. Il porte le projet.
Même le duo Chef de Projet/Business Analyst le plus performant peut faillir si le sponsor est absent.
2) Mise en place des rituels
Un second levier est de mettre en place des rituels fréquents pour maintenir la communication, la transparence et la cohérence.
Des points hebdomadaires Chef de Projet/Business Analyst peuvent être mis en place.
Il y sera fait une revue conjointe des besoins ou encore des synchronisations régulières avant et après chaque livraison.
3) Choix d’outils communs
Finalement, il est indispensable d’avoir des outils communs tels que le backlog, la documentation à jour ou encore le suivi des indicateurs.
Cela permet de partager la même vision et d’avancer ensemble vers le même objectif.
En mettant en place toutes ces recommandations, l’optimisation peut mener à un projet réussi orienté valeur.
Dans un projet de refonte d’outils, les rituels mis en place sont :
- Des ateliers de cadrage co-animés
- Synchronisation régulière et préparer ensemble les comités de pilotage pour les arbitrages
- Bien analyser les impacts métiers et planning des décisions
Ce système mène à des décisions rapides, une meilleure compréhension par tous des enjeux et une équipe alignée et plus engagée.
Les ingrédients essentiels à la réussite des projets.
Conclusion
On peut conclure que ce duo a la responsabilité de créer de la valeur en maîtrisant les contraintes de projet.
La fusion et la confusion de ces deux rôles génèrent des tensions, il est nécessaire de clarifier les missions de chacun et de se synchroniser en continu.
Le projet peut être en péril juste par le manque d’alignement dans l’équipe, et cela peut être dû à ce manque de clarté entre le Business Analyst et le Chef de Projet.
La pluralité des rôles est présente en projet, si cela n’est pas bien cadré, il peut y avoir confusion et manque de transparence menant à des ralentissements de projet.
Bien faire cohabiter les rôles de Chef de Projet, Business Analyst, PMO, Métier apportera succès aux projets de l’organisation et sera signe de maturité en gestion de projet.
La réussite d’un projet ne dépend pas uniquement de ce qui est livré, mais de l’alignement entre ceux qui pilotent la livraison et ceux qui en portent le sens.
25 Conseils pour
Chefs de Projet
(Guide PDF)
- Gagnez en efficacité en suivant les bonnes pratiques en gestion de projet
- Utilisez les bons livrables au bon moment tout au long du projet
- Démarrez votre projet du bon pied en prenant des décisions éclairées
Vous recevrez régulièrement des contenus intéressants. Vos données seront en lieu sûr, nous détestons le spam sans doute autant que vous, et vous pouvez vous désinscrire à tout moment. Voir notre politique de confidentialité.
