Warning: Undefined array key "HTTP_ACCEPT_LANGUAGE" in /home/vaesoli/snippet-center/trql.website.class.php on line 511

Warning: Undefined array key "HTTP_ACCEPT_LANGUAGE" in /home/vaesoli/snippet-center/trql.website.class.php on line 389

Budget

21-01-2024 16:09:43

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 devrait prendre en compte 3 coûts composites :

  • 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 fixés 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". 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é, une équipe expérimentée circonscrit mieux le périmètre et est plus à même de le découper en phases, voire d'eliminer du scope qui a 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.

Notes de bas de page

[1]Timeo Danaos et dona ferentes

Telegram icon