Business Case : Un projet dans le projet

Le Business Case (cas d’affaire en français) est une analyse démontrant la faisabilité financière d’un placement. Elle constitue un élément de preuve pour prendre la décision de lancer (ou non) un projet.

BUSINESS CASE : QUIZ INTRODUCTIF

Quiz : Un sponsor vous contacte pour signer la charte d’un projet d’infrastructure informatique à destination d’un organisme bancaire. Il s’agit de mettre au point un nouveau système d’information sur l’ensemble des filiales du groupe. Quelles sont les 3 choses à faire avant d’initialiser un projet prédictif d’après vous ? (Une seule réponse possible) : 

1. Évaluer les besoins, créer un business case, rédiger un plan de gestion des bénéfices
2. Évaluer les besoins, créer un business case, signer la charte du projet
3. Créer un business case, rédiger un plan de gestion des bénéfices, signer la charte du projet
4. Rien car les phases génériques d’un projet sont à adapter en fonction de chaque projet

—

Corrigé du quiz en bas de cet article [1].

Les projets échouent à un rythme frénétique, plus de la moitié du temps selon certaines estimations (cf. Le chaos report du Standish Group) Et pourtant le besoin de créer, d’innover et de lancer des projets est plus fort que toutes les statistiques de gestion de projet. Sortis des enjeux métaphysiques et économiques de la question : « pourquoi les humains se lancent-ils dans des projets ? », « Qu’est-ce qui motive les humains à construire des projets ? A quoi cela sert-il de créer des entreprises ? Etc., généralement on lance un projet pour 2 raisons. Soit pour résoudre une problématique, ex : les vaccins, les emballages intelligents, les fermes verticales, etc. Soit pour saisir une opportunité, ex : créer des taxi-robots autonomes, créer des vêtements connectés, des autoroutes automatiques, etc.

Première question à se poser : à quel moment doit-on rédiger un Business Case ? Réponse, à l’étape d’avant-projet. Sa présentation chronologique se retrouve notamment la figure 1-7 du guide pratique des groupes de processus (Process Groups : a practice guide, page n°30).    

NB : Sachez que cet article n’est pas spécifique aux grands projets liés au standard ou aux lignes directrices du PMBOK®, vous verrez qu’il s’agit là de règles de « bon sens » applicables à tout type de projet. Mais le « bon sens » n’est la chose la plus partagée ! 🙂

BUSINESS CASE – CONSEIL N°1 : PARTEZ DES COÛTS D’OPPORTUNITÉ !  

Quand on veut conjurer le sort des statistiques alarmistes de gestion de projet (notamment par rapport aux échecs), généralement on se questionne sur ses critères de réussite : à quoi verrais-je que mon projet est réussi ? Quels seront ses critères de réussite (à ne pas pas confondre avec les critères d’acceptation) ? Sa stratégie ? Etc. Ces questions interviennent pour « justifier » l’efficacité du projet futur.

Mais « avant » de questionner cette efficacité, il convient de s’interroger surtout sur sa « pertinence » : est-ce le bon projet ? Combien peut-il rapporter (R.O.I, N.P.V, Période de remboursement, etc.) ? Généralement le directeur de portefeuille pose ces questions, puis un Business Analyst les élabore pour présentation et validation en CODIR, COMEX (ou devant des actionnaires). Il faut donc « convaincre ».

Le meilleur moyen de convaincre de la pertinence d’un projet est donc de jouer sur des biais psychologiques bien connus. Mon favori étant « le biais d’aversion à la perte »  car il nous permet de parler des coûts d’opportunité d’un projet. C’est à dire des « coûts de ne pas faire le projet ». 

COÛTS D’OPPORTUNITÉ : EXEMPLE

Exemple de discours pour présenter des coûts d’opportunité pour un projet : « L’année dernière, notre concurrent principal a lancé une nouvelle application basée sur l’IA qui a capturé 30% de notre part de marché en seulement six mois. Si cette tendance se poursuit (présentez également des hypothèses), nous pourrions perdre encore plus de parts de marché, ce qui pourrait entraîner une diminution annuelle de nos revenus de 40% à 50% […] ».

Vous pouvez aussi présenter des chiffres concrets dans vos hypothèses : « […] notre chiffre d’affaires annuel est de 100 millions d’euros, une perte supplémentaire de 20% de parts de marché pourrait se traduire par une perte de 20 millions d’euros par an. Si nous ne réagissons pas rapidement en développant des solutions innovantes, nous risquons de perdre notre position de leader sur le marché.  Nous devons démarrer ce projet ! » 

Comme je l’indiquais précédemment, ce travail est à faire par un Business Analyst. Sachez que si vous préparez la certification PMP® du PMI®, vous devrez impérativement savoir ce qu’on doit faire « avant » de lancer un projet. Dans le PMBOK® vous entendrez beaucoup parler de valeur du projet : création de valeur, les composants de la création de valeur, se concentrer sur la valeur, etc. le Business Case est un des (nombreux) moyens qui existe pour prouver la valeur d’un projet. Dans un précédent article j’explique : comment se concentrer sur la valeur d’un projet ? 

BUSINESS CASE – CONSEIL N°2 : IDENTIFIER LES BESOINS IMPLICITES  

Plus on attend pour résoudre un problème, plus il coûte cher. Par exemple, une vis oubliée sur une ligne de production d’aspirateurs coûte quelques centimes. Mais si on attend pour la réparer, il faut stopper la ligne, faire venir un technicien, identifier le problème et reprendre la production, ce qui augmente encore ses coûts. Et si l’aspirateur atteint le point de vente, les coûts et les risques pour le client s’envolent encore plus. 

« Si j’avais demandé aux gens ce qu’ils voulaient, ils m’auraient répondu des chevaux plus rapides » Henry Ford.

Mais l’équation est difficile car les parties prenantes ne savent pas toujours exprimer clairement leur besoin. Souvenez-vous de cette phrase d’Henry Ford :  « Si j’avais demandé aux gens ce qu’ils voulaient, ils m’auraient répondu des chevaux plus rapides ». Il s’agit donc de trouver le bon équilibre entre la réponse aux besoins exprimés et la réponse à leurs besoins latents.

Vous l’aurez compris, dès l’étape d’avant-projet, le Business Analyst doit préparer le projet. Dans un projet prédictif, le chef de projet n’intervient normalement pas, sauf s’il assume aussi le rôle de Business Analyst. Il lui faudra identifier les parties prenantes impactées, comme les collaborateurs, les clients, les fournisseurs, etc.

Investiguer les besoins des parties prenantes est capital et souvent difficile, car il faut découvrir les besoins latents et non-dits. Souvent on croit répondre à un besoin et en fait « non ». Si ce sujet vous intéresse, je vous recommande ce livre : 100 grands flops de grandes marques – Histoires vraies et les leçons à en tirer).

BUSINESS CASE – CONSEIL N°3 : SÉPAREZ LE BESOIN DE LA SOLUTION 

Parfois, on connaît le besoin mais c’est dans la recherche de solution que les choses se corsent. Par exemple, l’aspirateur Dyson a été pensé à l’origine pour ceux qui avaient des problèmes d’asthmes. Le besoin était donc plutôt bien identifié : « trouver un objet éliminant les substances solides et liquides hors de l’organisme humain à destination de personnes asthmatiques pour leur permettre de nettoyer leur maison ». On est parti du besoin pour identifier le service à rendre aux parties prenantes.

Il fallait donc trouver une solution qui contourne le problème du moment. Les sacs des aspirateurs de l’époque remettaient la poussière dans la pièce lors de la mise en corbeille. Il fallait donc trouver une solution qui puisse éviter de rejeter des particules fines ; pollens de graminées et acariens principalement dans l’air ambiant. Il a fallu attendre la bagatelle de 5127 prototypes pour trouver une solution qui conviennent à toutes les parties prenantes. Admettez, qu’il eut été difficile de faire émerger cette solution par les parties prenantes.  La raison principale ? Un prototype est déjà une solution et non un besoin ! Il faut bien faire la différence entre un « besoin » et une « solution ».

• Le besoin : c’est l’usage souhaité par une personne. Ex : une personne Z souhaite trouver un objet permettant de se protéger de la pluie. Et c’est ce que doit rechercher le Business Analyst.

• La solution (appelée également exigence) : c’est le service à rendre aux parties prenantes par l’intermédiaire d’une fonction. Cette fonction est composée de caractéristiques destinées à répondre au(x) besoin(s) des parties prenantes. Ex : un morceau de toile en nylon, un manche et un rayon pour former un parapluie. Le parapluie rend service aux personnes qui souhaitent se protéger de la pluie. Et c’est ce que devra chercher à faire le chef de projet (ou Product Owner pour les projet agiles)) quand il y démarrera le projet.

Généralement lors d’un projet d’innovation, l’identification du besoin intervient dans la phase d’avant-projet et la recherche de solutions intervient pendant le projet. Mais parfois, par exemple lors de projet plus traditionnels la sélection de la solution à mettre en œuvre est très claire dès le départ, c’est-à-dire dès la phase d’avant-projet. Il suffira alors de réaliser une analyse des alternatives. C’est-à-dire réfléchir aux « raisons » qui vous ont poussées à sélectionner ou ne pas sélectionner ladite solution.

BUSINESS CASE – CONSEIL N°4 : PRÉCISEZ LES RISQUES DE HAUT NIVEAU  

Ensuite, il faudra aussi regarder du côté des risques de haut niveau [2] du projet. Haut niveau car il ne s’agit pas de rentrer dans le détail de tous les risques du projet. Il s’agit de regarder rapidement si les réponses aux risques identifiées seront contrôlables (en restant optimiste bien sûr 😊) en termes de délais et en termes de coûts. Dans le cas d’un aspirateur pour asthmatiques, il faudra penser par exemple à la réglementation, c’est-à-dire aux risques liés aux problèmes de voisinage causés par le bruit de l’aspirateur, aux problèmes de santé physique causés par la poussière, au respect de l’environnement, etc. Une fois analysés, ces risques de haut niveau seront ensuite consignés dans la charte de projet (si le projet voit le jour car souvenez-vous qu’on est encore au stade d’avant-projet). On veillera bien sûr à leur apporter des réponses globales en se faisant épauler éventuellement par quelques « expert-judgment [3] ». Et on veillera également à le mettre à jour régulièrement.

CONSEIL N°5 : NE CONFONDEZ PLUS BUSINESS CASE vs PLAN DE GESTION DES BÉNÉFICES vs CHARTE DU PROJET  

• • • Le business case du projet (ou cas d’affaires en français) :

      Le business case du projet (appelé également cas d’affaires) est un document de 2-3 pages (cf. template ci-dessous téléchargeable gratuitement) rédigé par un business analyst (ou équivalent) avant-même de démarrer le projet. Son objectif est de décrire synthétiquement le problème qu’on cherche à résoudre ou l’opportunité qu’on cherche à exploiter. .

      Exemple : 

      • • Il va y préciser le périmètre global du projet (ce qu’on cherche à faire concrètement) ;
        • Ses objectifs ;
        • Le nom de son commanditaire et message clé (utilisation de verbatims) ; 
        • « L’efficiency » (très important), c’est-à-dire expliquer la pertinence du projet par rapport au problème en cours. Ici on peut parler du ROI, de la NPV, de la période de remboursement (Payback Period) et des coûts d’opportunité ;  
        • L’analyse des alternatives du projet ;
        • Les résultats escomptés à 3 à 5 ans (le détail est précisé dans le plan de gestion des  bénéfices. voir paragraphe suivant) ; 
        • Le budget estimatif pour avoir une idée globale (mais attention, le budget définitif ne sera présenté qu’après démarrage du projet (à la fin de sa planification).    
      •  

• • • Le plan de gestion des bénéfices du projet :

      C’est grâce à ce document que le Business Case pourra être créé (et inversement car le business case sera régulièrement mis à jour). Il s’agit d’un document rédigé aussi dès la phase d’avant-projet par un business analyst (ou responsable financier) pour décrire quand et comment les bénéfices du projet seront obtenus. On y retrouvera une sorte de business plan décrivant les résultats escomptés à court, moyen et long terme, les bénéfices tangibles et/ou intangibles du projet (cf. article sur la valeur d’un projet), le nom de la personne en charge de signaler les bénéfices obtenus et les critères de mesure des bénéfices. Mais ce document est un annexe du Business Case. 

• • • La charte du projet :

      On la confond souvent avec le Business Case mais la charte du projet n’a pas le même objectif que le business case. Son intérêt principal est d’officialiser le démarrage du projet et de donner de l’autorité au chef de projet pour affecter des ressources aux différentes tâches du projet [5]. Si vous avez regardé des films policiers américains, on y retrouve souvent des phrases du genre : « vous reviendrez me voir quand vous aurez un mandat… ». C’est typiquement le même objectif pour une charte de projet (« project charter » en anglais). Elle est généralement rédigée par le sponsor du projet (ou préparée par le chef de projet) dans tous les cas de figure elle doit être signée par le sponsor et le chef de projet. Dans le cas contraire, un simple mail suffira (puisqu’un simple courriel peut être constitué comme preuve juridique, pour en savoir-plus cliquez-ici). On y retrouve des informations de haut niveau (c’est-à-dire des informations encore plus synthétiques que celles du business case) : comme l’objectif, les principaux livrables, les risques de haut niveau (c’est-à-dire les risques globaux), le budget global, les conditions à respecter pour clore ou annuler le projet (c’est-à-dire les critères de sortie) et bien sûr le nom du chef de projet et du sponsor.

CONCLUSION : UNE PRÉPARATION MINIMALE MAIS SANS DÉTAIL MAXIMALE 

Gardez en tête que contrairement à une idée reçue, un projet se prépare à minima avant d’être lancé. Sinon c’est prendre le risque de proposer un produit qui ne réponde pas aux besoins de vos futurs clients. Il s’agit simplement de s’assurer que votre projet puisse fournir un livrable d’une « valeur » commerciale minimale au travers d’un Business Case et d’un plan de gestion des bénéfices pour l’accompagner. Mais il ne s’agit pas non plus de créer une « usine à gaz » en le balisant d’une documentation que personne ne va consulter. Comme le dit Steve Jobs : « la qualité est le meilleure de vos business plan [5], point final. »