Editions ENI Livres | Vidéos | e-Formations
Parties prenantes
Introduction
Les parties prenantes du projet ? Facile ! Celui qui paie, celui qui fait fabriquer, les autres à côté et ceux qui râlent fort… oui, mais pas que ! Cette partie sera succincte, car elle relève plus de la gestion de projets que du recueil des besoins en tant que tel.
Répondre aux besoins des parties prenantes du projet : le scope
Il y a plusieurs rôles généralement bien définis, et même si une personne peut avoir plusieurs casquettes, il s’agit de comprendre les rôles et responsabilités de chacune. Nous donnerons ici de grandes généralités, mais les scopes peuvent varier énormément d’une structure à l’autre. Comprendre les grandes lignes permettra néanmoins de savoir qui prend les décisions sur quel domaine.
Les noms peuvent varier suivant les méthodologies et les scopes peuvent changer en fonction des structures et tailles des projets et des entreprises.
1. Le chef de produit
Ce rôle a été créé pour la première fois par Procter and Gamble. L’entreprise a placé une personne en charge de sauver les mauvaises ventes d’un produit : le chef de produit.
En anglais, on parle de product manager. Il a une vision macroscopique du projet et va coordonner les étapes allant de la conception à la livraison, établir une roadmap et définir les principales fonctionnalités attendues. Il sera aussi responsable de l’alignement de la solution sur les objectifs de l’organisation, mais aussi sur la vision du produit. Il est orienté vers le business car il est là pour définir le problème...
Répondre aux parties prenantes hors projet : le besoin de l’entreprise et la stratégie
On parle maintenant des personnes qui ne seront pas autour de la table, mais qui ont un intérêt positif ou pas dans la réussite de celui-ci. Il peut s’agir d’équipes qui sont impactées par le processus métier, des équipes qui sont en amont ou en aval des parties prenantes du projet, des personnes qui seront impactées, car, lors des arbitrages, vous avez remporté les ressources ou les budgets, voire les deux.
1. Le processus métier
On touche là au nerf de la guerre ! Votre solution répond maintenant aux besoins des parties prenantes du projet, mais pour en faire une solution pérenne, stratégique, utilisée par tout le monde… Bref la seule et unique "source de vérité", il va falloir qu’elle réponde aux besoins de personnes non impliquées dans le projet et dont, par définition, vous ne connaissez pas le besoin. Dans ce chapitre je les appellerai les parties "non" prenantes.
Il y a tout de même une solution. Si l’on reprend l’analogie du restaurant (cf. Quelles informations recueillir et quand ? - Analogie du restaurant : le processus et le timing), le plus important est de faire pousser vos légumes et de les cuisiner sans vous préoccuper trop de "Paul qui viendra manger à midi".
Construisez les historiques pour tracer le plus fidèlement possible les informations des bases sources sans vous préoccuper du ou des modèles qui les utiliseront.
Le modèle de données sera construit pour supporter un process métier avec ses faits et ses dimensions. Il ne sera pas construit en fonction d’un rapport que vous devrez fournir. Garder en tête que la durée de vie d’un rapport peut être de seulement quelques minutes permettra sûrement de vous tenir loin de ce genre de solution. Quel effort pour si peu de bénéfice !
Maintenant, on peut voir le bénéfice, votre historique...
Exemple
Voici un exemple d’une différence entre le besoin de l’organisation et des parties prenantes.
En 2020, le monde a connu une pandémie : "COVID-19". Pendant la période de confinement, en France, chaque personne devait sortir avec une attestation de déplacement dérogatoire. Elle avait pour but de dissuader les gens de sortir et de les faire réfléchir au caractère indispensable de chaque sortie.
Une entreprise a proposé une version électronique de la déclaration dans le but de simplifier la démarche.
Dans cet exemple, l’entreprise a pris en compte le besoin du citoyen (l’utilisateur de la solution) et non de l’organisation (la société) ; la dématérialisation de l’attestation allant en effet à l’encontre de son caractère dissuasif.
Il est donc essentiel de lier les besoins des utilisateurs avec les objectifs de l’organisation pour pouvoir répondre aux deux.