5 techniques d'analyse pour tout chef de projet

En bref. Un chef de projet n'a pas besoin de tout le catalogue de la Business Analyse : cinq techniques suffisent à sécuriser l'amont — cartographier les parties prenantes, cadrer le périmètre, organiser l'arbitrage des priorités, analyser un processus et tenir les risques portés par le besoin. Ensemble, elles répondent aux questions qui font dérailler un projet : qui pèse, qu'est-ce qui est dedans, qui arbitre quoi, où ça coince, et sur quelle hypothèse on parie.

Si tu pilotes des projets, tu réponds d'une chose : livrer dans les délais et le budget. Or on ne livre bien que ce qu'on a bien cadré, et c'est exactement là que la Business Analyse — la discipline qui clarifie un besoin avant qu'on ne construise une solution — vient te renforcer. Pas besoin d'en faire ton métier : cinq techniques suffisent. Chez Edelw'ice, le glacier artisanal lausannois fondé par Heidi en 1983, c'est Abby — la méthodique du duo d'analystes — qui les souffle à Nora, la cheffe de projet interne, à chaque nouveau chantier : cinq questions posées avant le premier jalon du planning.

Pourquoi un bon planning ne suffit-il pas ?

Parce qu'un projet ne déraille presque jamais sur le planning : il déraille sur le flou. Un besoin mal compris, un périmètre qui gonfle, une décision que personne n'avait le mandat de trancher. Le meilleur diagramme de Gantt ne rattrape pas une question de départ mal posée. Ces cinq techniques traitent le flou avant qu'il ne coûte cher.

Cinq techniques pour cadrer avant de planifier

1. Cartographier les parties prenantes. Une partie prenante, c'est toute personne que le projet touche ou qui peut l'influencer. Les situer selon leur influence et leur intérêt, c'est fabriquer sa gouvernance : qui valide, qui peut bloquer une étape, qui doit seulement être informé. Un chef de projet en tire deux livrables très concrets — la composition de son comité et son plan de communication. → la fiche dédiée.

2. Cadrer le périmètre. Le périmètre, c'est la frontière de ce que le projet livre. L'écrire en deux colonnes — ce qui est dedans, ce qui est dehors — et le faire valider est le meilleur rempart contre le « tant qu'on y est… » qui fait exploser les délais. La colonne « dehors » est celle qui protège : elle ne dit pas non pour toujours, elle dit « pas dans cet engagement-là ».

3. Organiser l'arbitrage des priorités. Un chef de projet ne priorise pas à la place des autres : il fait en sorte que chaque arbitrage ait un arbitre et un axe. Le métier arbitre des fonctionnalités, et il les compare en impact × urgence — ce que ça rapporte, et ce que coûte l'attente. L'équipe IT arbitre des tâches, et elle les compare en impact × effort — la charge appartient à ceux qui la portent. Mélanger les deux tables produit la réunion sans fin où l'on compare des choses qui ne se comparent pas. → prioriser quand tout est urgent.

4. Analyser un processus. Cartographier le déroulé réel d'une façon de travailler — qui fait quoi, dans quel ordre, avec quelle attente entre deux étapes — pour voir où le temps se perd au lieu de le deviner. Indispensable dès qu'un projet change une habitude de travail : c'est là que se logent les résistances qu'aucun planning n'anticipe.

5. Tenir les risques portés par le besoin. Un chef de projet tient déjà un registre des risques de délai, de coût et de ressource. La Business Analyse y ajoute une ligne souvent absente : les hypothèses non vérifiées sur le besoin. « Les clients veulent commander en ligne » est une hypothèse tant que personne ne l'a mesurée — et c'est celle qui, si elle tombe, coûte le plus cher. On l'écrit, on lui donne un propriétaire, et on décide comment la vérifier avant le point de non-retour.

Le réflexe de Nora. « Avant le planning, je réponds à cinq questions : qui pèse, quel périmètre, qui arbitre quoi, où ça coince, et sur quoi je parie. » Le calendrier vient après.

La même logique, hors des projets IT

Organiser un déménagement d'entreprise, un événement, une migration d'outil : les mêmes cinq questions valent. On ne pilote pas des tâches, on pilote des décisions — et ces techniques rendent chaque décision plus sûre.

Un Product Owner se sert de plusieurs de ces techniques, mais pour d'autres décisions : le projet a une fin, le produit continue. Le comparatif est dans 5 techniques pour un Product Owner.

Par où commencer

1. Cartographie tes parties prenantes sur ton projet en cours : qui pèse, qui s'intéresse, qui valide.
2. Écris le périmètre en deux colonnes : dedans / dehors. Fais-le valider par écrit.
3. Nomme l'arbitre de chacune de tes trois prochaines décisions ouvertes, et l'axe sur lequel il tranche.

Ces trois gestes suffisent à voir la différence dès le prochain comité de projet.

Ces cinq techniques, et les 45 autres du guide central du BABOK, sont sur les cartes du deck BADASS : la vue d'ensemble, et le moyen de se rappeler laquelle sortir le jour venu. Le déroulé complet d'une technique sur un cas réel — pas à pas, arbitrages, chiffres — c'est l'eBook qui lui est consacré.

Articles liés : Savoir qui pèse sur le projet · Quelle technique de BA pour quel problème · 5 techniques pour un Product Owner qui priorise mieux