Budget

19-07-2024 15:41:39

Le coût réel d'un projet est chose éminemment complexe à établir. C'est plus une affaire d'art que de science, quel que soit le soin et le sérieux qu'on y consacre. Cela ne signifie pas non plus qu'il s'agit d'un exercice qui n'a pas d'approche méthodique.

Le coût réel est composite : il prend en compte 3 coûts distincts :

• le coût de construction
• le coût operationnel
• le coût de "ne pas faire"

Cr = Cc + Co - Cn

Pour être complet, il faudrait que j'aborde la question du CoD (Cost of Delay), mais je néglige cette donnée car je la considère plus comme une question de manque à gagner (ce qui n'est pas complétement exact non plus, car le délai peut engendrer des coûts de pénalité d'une façon ou d'une autre). Quoi qu'il en soit, je fais cette simplification et j'accepte d'emblée qu'on l'a qualifier d'abusive (lecture recommandée : Weighted Shortest Job First — © Scaled Agile, Inc.)

Revenons à nos 3 composantes, coût de construction, coût opérationnel et coût de "ne pas faire".

Dès le moment où on introduit le coût opérationnel on fait face à des problèmes de posture. Si on définit un projet comme étant "ce qu'on a l'intention de faire et estimation des moyens nécessaires à la réalisation" (https://www.cnrtl.fr/definition/projet) on bute sur la définition même de ce qu'est un projet : s'arrête-t-il à la seule réalisation / construction ? est-il limité dans le temps (date de début et de fin) ? Dispose-t-on d'équipes long-terme ou pas ? etc.

On en revient alors à la question du funding et à l'orientation de l'entreprise : projet ou produit. Je n'y reviens donc pas ici.

Adoptant la posture de l'entreprise qui assemble des équipes long- terme de type "You build It, You Run It", j'embarque d'emblée le coût opérationnel, ce qui ne simplifie pas l'équation, j'en ai peur. Dans une organisation traditionnelle, on demandera souvent au Chef de Projet de lister les coûts récurrents que la construction va engendrer : location, licences, frais d'infrastructure, etc. Prenez l'exemple d'un projet CRM, vous vous exposez à des coûts récurrents de licence, parfois malaisés à estimer, surtout lorsque ces coûts sont eux-mêmes soumis à des parties fixes et d'autres variables. Le tout, ici, est de préparer le terrain correctement en essayant de tenir compte le mieux possible de l'ensemble des coûts récurrents afin d'aider le Management à garder les coûts de RUN sous contrôle. Ceci me rappelle de nombreuses situations où le CIO faisait état de son désespoir car il voyait filer 80% de son budget en coûts opérationnels divers. Au final, seuls 20% lui restaient pour articuler sa capacité de CHANGE.

Le coût de "ne pas faire" est cynique, peu souvent invoqué. Son principe est simple : que vous coûterait ce projet si vous ne le faisiez pas ? L'exemple le plus simple auquel je puisse penser est celui d'un projet légal. Le faire vous coûterait 1.000.000 €; ne pas le faire vous expose à une amende de 600.000 €. Le coût réel de ce projet est donc de 400.000 €. Voilà un premier exemple de coût de "ne pas faire" (600.000€ ). En voici un autre. Toujours un projet de 1.000.000 €, cette fois sans amende, mais avec des incidences multiples : si vous ne le faites pas, alors conséquences A, B et C. A vous coûterait 100k€, B aussi et C ne vous coûterait rien MAIS aurait pour conséquences X (100k€), Y (200k€) et Z (300k€). A ce stade, cela paraît simple mais il n'en est rien car des conséquences en chaîne peuvent survenir et l'analyse du problème gagne rapidement en complexité. Quelle que soit votre option, il est important de tenir compte du coût de "ne pas faire" pour établir le budget le plus réaliste possible. Mon garde-fou est celui du bon sens qui craint la complexité comme les Troyens craignaient les Danaens^[1]

Coût de construction (Cc)

Le coût de construction, lui, est ce que les chefs de projet mettent habituellement dans leur budget. Dans certains secteurs, le budget tient compte de la TVA, pas dans d'autres. Il convient d'y être attentif. On distinguera les coûts suivants :

• collaborateurs internes
• collaborateurs externes
• outillage non amortissable
• investissements (et durée d'amortissement)
• satellites (hôtels, voyages, …)
• contingence (le coût de l'incertitude)

Ayez une grille de coût moyen journalier d'un collaborateur et veillez à bien estimer la disparité potentielle entre les collaborateurs internes et les externes afin d'éviter de mauvaises surprises (j'ai connu plusieurs situations où la disparité des coûts était importante — du simple au double — où cela a conduit un projet à devoir se séparer des externes car le budget avait été consommé en la moitié du temps prévu initialement). L'utilisation d'un budget burndown vous aide à garder le budget sous contrôle notamment par la vertu d'une courbe d'extrapolation (moment auquel j'aurai consommé la totalité de mon budget si je le dépense au burn rate actuel).

J'aime fonctionner sans ramp-up et sans ramp-down soudain pour les membres de l'équipe. C'est une question de projection : à fonctionner avec un effectif fixe, disposant de coûts moyens, le budget se gère plus aisément.

Les financiers qui examineront votre budget seront particulièrement attentifs au moment où ils peuvent activer les amortissements. Pour eux, le plus vite, le mieux. Quand peuvent-ils procéder aux amortissements ? Dès que le produit / service est livré. Être capable de découper votre projet en livraisons rapides partielles épouse leurs vues. Favorisez cette approche, même si vous ne travaillez pas selon les canons de l'Agilité.

La contingence est, elle, également affaire délicate. Vous n'aurez aucun mal à la positionner à 10% du coût de construction (hors contingence, cela va de soi). Entre 11% et 20%, il vous faudra faire montre de capacités de négociation. Au-delà de 20%, appelez Tom Cruise.

La contingence ne doit jamais se concevoir comme une réserve destinée à équilibrer un budget mal ficelé. La contingence doit toujours être proportionnelle à la part d'incertitude (ce que vous aurez mentionné sous forme de risque). Lorsque l'incertitude se matérialise, il faut avoir le courage d'amputer la contingence du coût engendré. Au cours de ma carrière, j'ai remarqué qu'une contingence entre 15 et 17% était raisonnable et négociable.

L'incertitude existe par nature en ce que le futur est toujours incertain. Elle dépend d'un cône d'incertitude que vous seriez bien inspiré d'établir pour VOTRE projet car il est lié au degré de nouveauté de ce que vous voulez entreprendre et à l'expérience des membres de votre equipe. Vous servir du cône d'incertitude du collègue ne vous aidera pas. Personnellement, j'essaye de garder une vue détaillée des activités (qui, quand, comment) sur un horizon de 3 mois, avec la mise au point d'une ligne de temps précise sur un horizon de 1 mois. Je relâche la contingence budgétaire au fur et à mesure du projet, à raison de 50%. J'explique : si j'ai un projet de 1.000.000 € (870k€ hors contingence) pour 1 projet d'1 année, et si j'ai négocié une contingence à 15 %. (130k€), alors si rien de fâcheux ne s'est manifesté après 6 mois, je relâche 50% de la contingence sur les 6 premiers mois, soit 65k€ / 2, c'est-à-dire 32,5k€. Je me livre à cette discipline tous les 3 mois et au lieu de fonctionner avec une charge linéaire (le coût projet mensuel serait fixe), je fonctionne avec une courbe de Gauss plus ou moins aplatie selon le projet. Ce qui est relâché alors correspond au montant de la contingence au croisement de la courbe et de la ligne de temps. C'est plus compliqué, mais c'est plus précis. Cet exercice est, pour moi, fondamental dans la mesure où il me permet de rendre des moyens budgétaires à l'organisation dont les ressources, nous le savons, ne sont pas illimitées. Étant donné les habitudes développées dans les exercices budgétaires (allocation annuelle), plus vite on relâche de la contingence, mieux c'est.

Le coût de construction est une fonction dont les paramètres sont "Maturity", "Who", "What", "hoW", "When" et "Where".

Rationalité :

Who

construire une maison avec un architecte chevronné et une équipe expérimentée impacte le coût (positivement ET négativement). L'expertise coûte plus cher que l'inexpérience. En revanche, elle permet de réduire l'incertitude sur le "When" (respect des délais), elle permet de mieux circonscrire le "What" (les bonnes personnes, à la bonne place voilà qui permet de mieux cerner / limiter le périmètre) et permet également de se tourner plus facilement vers les meilleures solutions : on impacte donc le hoW. La taille de l'équipe est un facteur important : plus la taille de l'équipe est imposante, plus l'effort de coordination et synchronisation sera important.

What

un architecte chevronné permet de mieux cerner correctement le périmètre et est plus à même de le découper en phases, voire d'eliminer le scope, ou d'en postposer des parties) qui ont moins de valeur à un instant t.

Where

il s'agit ici de tenir compte de circonstances de lieu au sens large. Réaliser un projet en Argentine n'est pas la même chose que le réaliser en Suisse ou en Roumanie. Déployer le projet dans le Cloud n'est pas la même chose que de le déployer sur votre infrastructure propre. Par analogie, construire la maison sur des sables mouvants ou en montagne coûte plus cher que de la construire en plaine, proche des matériaux de construction. Il est utile de considérer les circonstances de lieu dans l'établissement du budget.

When

Les circonstances de temps sont aussi importantes que les circonstances de lieu. Plus vite le projet doit être livré, plus la pression sur l'équipe est grande. Frederick Brooks nous a mis en garde contre cet aspect avec son livre "The Mythical Man-Month". Il démontre que le nb de personnes qui travaillent au projet devrait être proche du nb de mois pendant lesquels elles vont travailler, par exemple, 8 personnes pendant 8 mois. L(i)VID utilise cette notion dans sa formule de priorisation.

Maturity

enfin, vient cette question délicate de "Maturity". Je prendrai un raccourci en vous disant que cette maturité est elle-même un valeur composite : la maturité de l'organisation, la maturité de l'équipe projet et la maturité des équipes à interagir les unes avec les autres. C'est tout le sens de CMM et CMMi qui conclut en disant que plus la maturité de l'organisation croît, plus les chances de réussir les projets sont élevées et plus l'organisation est capable de prendre rapidement toutes mesures correctives nécessaires.

Les Avantages de Gérer un Budget avec un Burndown Chart

Gérer un budget peut parfois sembler une tâche ardue, mais l'utilisation d'un burndown chart offre une approche visuelle et dynamique qui facilite cette gestion. Un burndown chart est un graphique qui montre la quantité de travail restant à accomplir dans un projet par rapport au temps. Dans le contexte budgétaire, il peut illustrer les dépenses prévues par rapport aux dépenses réelles, permettant ainsi une meilleure compréhension de l'état financier d'un projet.

Visualisation Claire des Dépenses

L'un des principaux avantages d'un burndown chart est sa capacité à fournir une visualisation claire et intuitive des dépenses. En représentant graphiquement les coûts, les gestionnaires peuvent rapidement identifier les tendances et les écarts entre le budget prévu et les dépenses réelles. Cela permet une prise de décision rapide et éclairée, car les équipes peuvent ajuster leurs stratégies financières en temps réel pour éviter des dépassements budgétaires.

Suivi de la Progression Budgétaire

Un burndown chart permet également de suivre la progression budgétaire au fil du temps. En affichant les dépenses cumulées par rapport à une ligne de tendance idéale, il devient facile de voir si le projet est sur la bonne voie. Cette approche proactive aide à anticiper les problèmes financiers avant qu'ils ne deviennent critiques, offrant ainsi la possibilité de réagir et de réajuster le budget si nécessaire.

Voilà ce que je vous propose : un budget en burndow !

Engagement et Responsabilité

En intégrant un burndown chart dans la gestion budgétaire, on favorise également un sentiment d'engagement et de responsabilité au sein de l'équipe. Chaque membre peut visualiser l'impact de ses décisions financières sur l'ensemble du projet. Cela encourage une culture de transparence et de collaboration, où chacun est conscient de l'importance de respecter le budget et de contribuer à son bon suivi.

Adaptabilité et Flexibilité

Enfin, l'utilisation d'un burndown chart permet une plus grande adaptabilité et flexibilité dans la gestion budgétaire. Les équipes peuvent facilement ajuster leurs prévisions et stratégies en fonction des données en temps réel fournies par le graphique. Cela est particulièrement utile dans des environnements dynamiques où les conditions peuvent changer rapidement, permettant ainsi aux gestionnaires de naviguer efficacement à travers les imprévus tout en maintenant le contrôle des finances.

Un budget par projet; un budget pour le tout

Lorsque votre Transformation Digitale englobe de multiples projets comme celui qui est donné en exemple ci-dessous, la question de savoir si vous devez gérer un budget par projet ou un budget global se pose bien vite.

Cela ne vous encouragera pas mais il est indispensable d'avoir un budget par projet ET un budget global.

En somme, gérer un budget à l'aide d'un burndown chart est une méthode efficace qui combine visualisation, suivi, engagement et flexibilité. Cette approche moderne et dynamique transforme la gestion budgétaire en un processus plus accessible et collaboratif, propice à la réussite des projets.

Notes de bas de page

^[1] … Timeo Danaos et dona ferentes