Qu’il soit agile ou non, un projet a toujours un budget prévisionnel établit, car l’objectif de toute entreprise est de générer le meilleur retour sur investissement possible. Le contrôle du budget, et donc le contrôle des coûts font partie des incontournables de tout projet. Nous allons voir ici sur quels critères se baser pour effectuer un contrôle efficace de son budget, et comment utiliser le « cost burn-up chart » pour estimer le coût prévisionnel du projet jusqu’à sa fin.
Le calcul du budget prévisionnel
Le contrôle du budget agile est une contrainte très importante pour n’importe quel projet. Il est particulièrement rare de rencontrer un projet disposant d’un budget illimité, à moins qu’il ne soit financé par un mécène très généreux. Dans l’immense majorité des cas, l’objectif d’un projet est de dégager une plus-value et de générer un retour sur investissement le plus important possible.
Pour cela, il faut d’une part déterminer le budget prévisionnel du projet, et d’autre part, limiter les coûts engendrés lors de son déroulement.
La construction du budget prévisionnel s’appuie sur l’estimation des coûts directs et des coûts indirects. La première catégorie regroupe les coûts salariaux des différents profils amenés à intervenir sur le projet, les éventuels frais de déplacements, le matériel utilisé… La seconde catégorie regroupe les frais de location des locaux et de mobilier, l’amortissement des serveurs, les frais de gestion (services juridiques et comptables)…
A partir de cette estimation, de la liste des fonctionnalités demandées et chiffrées, et de la vélocité de l’équipe, il va être possible de déterminer un budget prévisionnel.
Le contrôle des coûts
Déterminer un budget prévisionnel pour un projet agile, c’est bien. Le respecter, c’est encore mieux. Le contrôle des coûts doit donc être réalisé durant tout le déroulement du projet. Il sera nécessairement plus complexe à réaliser au début du projet, car un certain nombre de critères sont encore flous à cette période, comme par exemple la vélocité de l’équipe de développement. Mais il pourra s’affiner au fur et à mesure de l’avancement du projet.
Le contrôle des coûts va être basé sur les quatre principaux indicateurs que sont le budget prévisionnel, le rendement, les demandes de modifications et le plan de gestion des coûts.
Le rendement est mesuré à partir de ce qui a été réalisé lors des itérations précédentes. On compare ce qui a été réalisé avec le planning prévu et les fonctionnalités embarquées normalement. Si moins de fonctionnalités que prévu ont été développées, le rendement est mauvais. Si au contraire, l’itération a pu embarquer plus de choses que prévu à l’origine, le rendement est plutôt bon. Quand ce qui était prévu a été réalisé, le rendement est normal. On observe généralement des variations de rendement en début de projet, sur les premières itérations, lorsque l’équipe projet ne fonctionne pas encore à plein régime et que sa vélocité fluctue (normalement, elle doit augmenter durant les premières itérations puis se stabiliser).
Les demandes de modifications de la part du client peuvent changer les coûts par rapport à ce qui était budgété. L’évolution du product backlog peut avoir une influence significative sur le coût du projet scrum. Un product owner qui ajoute des demandes non planifiées à l’origine dans le backlog ou qui effectue des modifications conséquente peut modifier le cours du projet. Ces demandes doivent être discutées et arbitrées. Si elles doivent être prises en compte, elles doivent être estimées, et ajoutées au coût initial provisionné. Au contraire, un product backlog insuffisamment renseigné peut amener à une équipe en sureffectif par rapport à la charge de travail. Il est important d’anticiper ces variations, car elles peuvent amener au départ d’un certain nombre de personnes de l’équipe, qui seront ensuite difficilement remplaçables si la charge de travail augmente de nouveau. Cela peut être alors une source de coûts supplémentaires.
Le plan de gestion des coûts, même s’il n’est pas préconisé en mode agile, est assez courant dans tous les projets. Il permet de définir notamment les outils de suivi qui seront utilisés, la façon dont les rapports seront effectués, et la façon dont les variations des coûts seront gérées dans le cadre du projet.
Des moyens de contrôle
Les outils de contrôle des coûts sont nombreux et basés sur l’expérience acquise et le déroulement du projet.
Les estimations des coûts doivent être revues régulièrement en fonction des besoins et les courbes de tendances surveillées. Toute tendance à la hausse des coûts qui n’était pas prévue et qui peut représenter un danger pour le projet pourra ainsi être repérée plus facilement. De la même façon, le budget doit être mis à jour régulièrement de façon à mettre en avant les tendances à la hausse ou plus rarement à la baisse.
L’efficacité des actions correctives mises en œuvre durant les précédentes itérations doit également être estimée. Les contraintes ont ainsi pu évoluer depuis la mise en place des différentes mesures, et le périmètre du projet a pu être modifié. Les différentes actions entreprises peuvent avoir un effet positif comme négatif sur l’évolution des coûts. Il convient alors d’en estimer l’impact afin de prévoir au mieux la suite des événements.
Enfin, il faut savoir tirer des leçons du passé et s’en servir pour estimer et contrôler plus finement les coûts. En fonction des travaux déjà effectués et de leurs coûts désormais connus, il est possible d’optimiser l’utilisation les ressources de l’équipe projet afin d’augmenter la plus-value des opérations en cours et à venir.
Le coût du projet est dans la plupart des cas une contrainte forte. Si vous n’avez pas la possibilité d’obtenir un supplément pour le budget de votre projet, une surveillance rapprochée des coûts est primordiale. Le cost burn-up chart est l’outil idéal pour cela.
Le cost burn-up chart
Ce graphique « cost burn-up » a pour objectif d’une part la surveillance des coûts du projet, et d’autre part la prévision des dépenses des futures itérations. Il permet donc non seulement de suivre précisément les frais déjà engagés lors des itérations précédentes, mais également d’anticiper les besoins futurs.
Les investissements déjà réalisés peuvent être calculés puisque le coût de chaque membre de l’équipe est parfaitement connu. Il suffit de les transposer d’une échelle de temps mensuelle à une échelle basée sur les itérations.
Les prévisions de dépenses quant à elles sont basées sur deux informations principales. La première concerne directement les travaux de développements avec le nombre d’itérations nécessaires pour terminer le projet. Le nombre d’itérations restantes peut être calculé à partir de la vélocité mesurée de l’équipe et du contenu mis à jour du product backlog. La seconde information est basée sur la gestion des ressources humaines, avec le nombre de jours que chaque membre de l’équipe va passer à travailler sur les itérations restantes.
A la fin de chaque itération, le graphique cost burn-up est mis à jour avec les nouvelles données, le montant des dépenses étant connu. Grâce à cet outil, il est possible de surveiller de près les coûts et leur évolution de façon tout à fait régulière.
Le but de ce graphique n’est pas de fournir des valeurs précises. En revanche, il permet de déterminer trois scénarios qui sont le cas de figure le plus favorable, le cas de figure le moins favorable et le cas intermédiaire, moyen. Ces scénarios vont permettre de mettre en place une surveillance agile des coûts du projet. Naturellement, il y aura toujours une part d’incertitude puisque ce ne sont que des prévisions. Le plus important est d’instaurer une surveillance continue et d’agir en conséquence en fonction des besoins.
Le graphique « cost burn-up » est un outil particulièrement performant pour communiquer les résultats et les prévisions du projet à l’équipe de gestion, lors d’un comité de pilotage par exemple. La hiérarchie peut ainsi être tenue au courant du déroulement du projet, qui est rendu lisible grâce au cost burn-up chart. Même si dans une équipe agile c’est le product owner qui porte la responsabilité des dépenses et du budget de façon plus générale, les décisions finales reviennent au comité de pilotage en cas de dépassement flagrant. Dans la mesure où le respect du budget représente une contrainte particulièrement importante pour un projet, il est impératif d’avoir un outil efficace qui permettre d’en effectuer une surveillance continue.
Le product owner grâce aux prévisions de coûts peut anticiper un dépassement de budget, et engager de façon préventive des actions correctives. Il peut s’agir d’abandonner certaines fonctionnalités, d’en diminuer la complexité, de faire l’inventaire des user stories du product backlog afin de déterminer lesquelles pourraient finalement ne pas être nécessaires ou encore d’optimiser les performances de l’équipe en la réorganisant. L’efficacité de ces actions sera ensuite évaluée et prise en compte lors des mises à jour suivantes du cost burn-up chart.
Beaucoup pensent qu’il n’est pas possible de surveiller efficacement le budget d’un projet agile. En réalité, c’est plutôt simple puisque tout ce dont vous avez besoin, ce sont les dépenses liées à l’équipe lors des itérations précédentes, un product backlog à jour, la durée d’une itération et la vélocité de l’équipe. Le graphique « cost burn-up » construit à partir de ces informations deviendra rapidement l’outil indispensable de contrôle du budget de votre projet.
Nutcache est l’outil idéal pour gérer le budget de votre projet agile. Testez-le gratuitement pendant 14 jours!
