Table des matières CARTE HEURISTIQUE... 2...2 LES PROJETS INFORMATIQUES ONT BIEN MAUVAISE RÉPUTATION...3 LE BUDGET D'UN PROJET... 3 Le principe de détermination du budget d'un projet...3 Les méthodes d'estimation des coûts d'un projet...4 Les méthodes d'estimation de la charge...4 LA RENTABILITÉ D'UN PROJET... 4 Le Retour sur Investissement...5 Le Délai de recouvrement...5 La valeur actuelle nette...5 Le Taux de rendement interne...5 VAL IT : la gouvernance des investissements informatiques...6 LE SUIVI DES COÛTS D'UN PROJET... 8 Interprétation des écarts...10 Les indices de performance...11 Exemple...11 Carte Heuristique 1/11
Les projets informatiques ont bien mauvaise réputation... «On constate que rares sont les projets d'envergure en matière d'utilisation des technologies informatiques qui rendent les services attendus. Et les observateurs (Gartner Group, Standish Group, Forrester Research et autres analystes ) le mettent en évidence : 50 à 60% des projets qui introduisent des technologies nouvelles, et sans doute "déstabilisatrices", comme le CRM (partager l'information client), les ERP (intégrer les fonctions de l'entreprise), la GED ou le KM (partager l'information), échouent, ou au mieux ne répondent pas aux objectis initiaux; ces "échecs" se mesurent par 20% de dépassement des coûts et au moins 40% des délais, alors même que le produit mis à disposition ne répond pas aux ambitions initiales, etc. Bref, autant de chiffres aussi alarmants que désarmants. Pourtant, les projets purement informatiques ne sont qu'une très faible part des projets de SI... Les projets dits "informatiques" sont dans bien des cas une composante, informatique certes, d'un projet global de transformation de l'entreprise, qui va aller bien au delà de la mise en service d'une application, et jouer surtout sur les processus de l'entreprise, son organisation, et ses compétences. De fait, les causes avancées par les observateurs sur les motifs des échecs des "projets informatiques" sont toujours les mêmes : a) défaut d'alignement stratégique : quand un projet informatique sert une cause qui n'est pas celle de l'entreprise, mais celle d'un quelconque dirigeant, d'une mode ou d'un oukaze sans relation avec l'avenir de l'entreprise, cela finit bien par se voir. Et le couperet tombe... b) insuffisance des maîtrises d'ouvrage en matière d'accompagnement des évolutions des métiers. C'est un symptôme. Le mal est dans la sous-estimation des évolutions des processus de l'entreprise et dans ce qui doit les accompagner : évolution des compétences, de l'organisation, des métiers. c) sous-estimation des moyens à mettre en oeuvre, notamment de l'évolution des processus, et ce qui va avec, absence d'allocations de ressources. Un processus, c'est un savant cocktail de méthodes, de compétences, d'outils et de... motivation. Changer l'outil ne suffit pas à ce que le reste du cocktail fonctionne. Au contraire, le principe de l'entropie veut que le désordre règne. Mais, et c'est aussi l'arbre qui cache la forêt, la confusion des rôles entre sponsor du projet (celui qui s'engage et se fait fort d'obtenir les résultats attendus et donc obtient les ressources nécessaires) et le maître d'ouvrage opérationnel (qui gère le projet au quotidien) y est sans doute pour quelque chose. d) absence d'indicateurs fiables de performance. On bâtit des projets sur des "mieux", "plus vite", "plus efficace", mais comme les indicateurs avant projet ne sont pas définis, ceux qu'on mesure après projet n'ont pas de sens. Et, malheureusement, les bénéfices d'un projet ne se mesurent pas en réalité en termes informatiques, puisque par construction l'informatique coûte et que c'est l'optimisation des processus métiers qui rapporte. Autrement dit, les gains potentiels ne se réalisent pas au sein de la DSI. Tout cela ne fait que révéler un mal-être profond de la notion de projets informatiques. Globalement, en dehors de ceux qui sont purement "technologiques" (mais qui quelque part vont servir les processus informatiques) ou "obligatoires" (an 2000, euro), tous les autres projets informatiques ne sont que des composantes de projets d'entreprise qui vont servir des processus métiers. Encore fautil que tout le monde dans l'entreprise comprenne bien quel service va rendre la composante informatique du projet global, c'est-à-dire que l'entreprise ait bien assimilé que l'informatique est un "facilitateur" de transformation et d'optimisation de processus métiers.» (AFAI) Le budget d'un projet La MOA est en charge de la gestion budgétaire du projet. Elle doit mettre en place des outils de suivi et de prévision, qui seront utilisés pendant toute la durée du projet, afin de limiter le risque de dérapage financier. Le principe de détermination du budget d'un projet Lors de l'étude préalable, la MOA définit le budget à allouer au projet. L'estimation doit tenir compte des dérives possibles et déterminer le plafond budgétaire à ne pas dépasser. 2/11
Le risque est de sous-estimer le budget par optimisme ou par sous-évaluation des tâches nécessaires au bon déroulement du projet (documentation, recette, formation... ). Une mauvaise estimation du budget peut avoir des conséquences directes sur le respect des objectifs assignés au projet ou sur la qualité du système d'information. La fiabilité des prévisions est importante dans le succès du projet et elle est un préalable à la gestion des priorités. Les méthodes d'estimation des coûts d'un projet Parmi les nombreuses méthodes d'estimation des coûts d'un projet, on peut utiliser : le modèle analytique : le coût est calculé à partir de l'estimation individuelle des composants et des tâches ; la synthèse d'estimations réalisées par différents experts ; l'estimation par comparaison : le coût est calculé par rapprochement avec un projet présentant des similarités. Les différences sont mises en évidence et les écarts sont pris en compte ; la meilleure offre du marché : l'estimation du coût est basée sur les réponses faites par des fournisseurs à un appel d'offres. L'estimation des coûts permettra à la MOE et à la MOA de suivre le budget du projet. Toutefois, elle nécessite très souvent de calculer la charge, qui représente la quantité de travail nécessaire, indépendamment du nombre de personnes. La charge s'exprime en jours-homme (j-h). Il existe plusieurs méthodes d'estimation, présentées dans le tableau suivant : Les méthodes d'estimation de la charge Méthodes Descriptions Décomposition Cette méthode se fonde sur une estimation descendante. Dans un premier temps, le projet est décomposé en phases. Dans un deuxième temps, les phases sont décomposées à leur tour en activités significatives et évaluables en termes de charge. Ensuite, la charge totale du projet est déterminée avec une majoration de 10 à 20 % pour couvrir la gestion de projet à proprement parler. Multiplication Cette méthode est utilisée pour les tâches répétitives (par exemple, le déploiement sur des postes). Analogie Cette méthode est basée sur l'expérience en gestion de projet. Délimitation Cette méthode utilise des minimas et des maximas pour extraire une valeur réaliste. Pourcentages Cette méthode utilise les pourcentages généralement admis par les méthodes structurées (par exemple, s'agissant du développement interne, selon la méthode HERMES : 5 % pour l'étude préalable, 35 % pour la conception, 55 % pour la réalisation et 5 % pour l'introduction). COCOMO (COnstructive Cost MOdel) Cette méthode se fonde sur la taille du projet exprimée en lignes de code. Ces différentes méthodes sont utilisées par les entreprises selon leur expérience des projets à conduire et la nature de ces derniers. La rentabilité d'un projet Avant de réaliser l étude de rentabilité il faut avoir défini, au moins à grande maille, le fonctionnement du système. C est le rôle de l étude préalable qui détermine les enjeux, les risques, les points forts et faibles du projet. C est à ce moment-là qu il faut étudier la rentabilité du projet. Les principes de l étude de rentabilité sont les suivants : définir les alternatives possibles, calculer les coûts complets, définir et argumenter les hypothèses de gains, 3/11
estimer les gains, utiliser des méthodes éprouvées de calcul de rentabilité, évaluer la sensibilité de la rentabilité aux hypothèses de gains, évaluer les risques, optimiser la rentabilité, mesurer la rentabilité effective. Tous les calculs de rentabilité sont fondés sur l évolution du compte d exploitation de l entreprise et donc sur les flux nets de trésorerie, c est-à-dire, la différence entre les gains et les coûts, majorés des investissements, le tout étant minoré des impôts et taxes. De multiples indicateurs existent, qui résultent d approches différentes. Le Retour sur Investissement Le retour sur investissement (ROI en anglais) est défini pour une période donnée comme la somme des profits actualisés du projet, c est-à-dire les revenus moins les coûts, divisée par les fonds investis dans le projet. La méthode de calcul est la suivante : RSI = Bénéfices annuels actualisés - coûts annuels actualisés Coût du projet 100 Le taux utilisé pour l actualisation correspond souvent au taux d intérêt ou au loyer de l argent. Le résultat est un pourcentage qui indiquera la rentabilité du projet. Au RSI est souvent associée la notion de «délai de remboursement» ou «Payback period» Le Délai de recouvrement Le «payback period» est le délai au-delà duquel les gains (Recettes cumulées) dépassent les coûts (Dépenses cumulées), c est-à-dire que le flux net de trésorerie est nul ou que le Cash Flow cumulé devient positif. On peut visualiser ce délai par la courbe des cash-flows cumulés. Cette courbe décroît sous l axe des abscisses puis se redresse et recoupe l axe. Le moment de cette intersection est le délai de recouvrement. C est une notion simple, qui exprimée autrement indique le temps nécessaire pour rembourser l investissement réalisé. C est le meilleur indicateur pour les projets informatiques, qui trop souvent dérapent en délais et coûts. La valeur actuelle nette La valeur nette actualisée (VAN) est sur une période donnée, le cumul des flux nets actualisé en tenant compte d un taux de l argent. Ce chiffre indique la valeur du système mis en place à l horizon donné. Une VAN négative est la démonstration d un projet non rentable. La valeur actuelle nette (VAN) mesure par définition la création de valeur d un projet en actualisant les flux de trésorerie générés par ce projet. Simplement, le taux d actualisation ne représente pas le loyer de l argent mais le risque du projet. Il aboutit à un chiffre positif qui mesure la valeur créée ou à un chiffre négatif qui mesure la valeur détruite. Dans ce dernier cas, les analyses ne sont pas approfondies et le projet ne sera jamais lancé, sauf circonstances particulières. La VAN est la somme des cash-flows (rentrées et sorties nettes de trésorerie) actualisés, sur toute la durée de vie de l investissement. VAN = Rt / (1+a) t - Dt / (1+a) t = (Rt Dt) / (1+a) a : taux d'actualisation R : rentrées nettes D : sorties nettes t : nombre d'années t Le Taux de rendement interne Le taux interne de rentabilité (TRI) est le taux qui rend nul la VAN, soit le taux maximum auquel il est possible d emprunter pour que le projet soit rentable. Ce taux est très souvent très élevé dans les projets informatiques, mais pas très significatif, les investissements s effectuant massivement au démarrage du projet. Le calcul du TRI a les mêmes fondements que celui de la VAN. Il consiste à rechercher pour quel taux d actualisation on obtient l égalité entre l investissement initial (Io) et la valeur actuelle des cash- 4/11
flows nets attendus. En effet, l examen de la courbe donnant la VAN en fonction du taux d actualisation montre qu il existe une valeur de ce taux pour laquelle la VAN est égale à 0. Ce taux est appelé «taux de rendement interne», et peut aussi être vu comme le taux d actualisation maximal pour lequel le projet est créateur de valeur. TRI = Rt - Dt (1 + i)t =0 R : rentrées nettes D : sorties nettes t : nombre d'années i = taux d'actualisation inconnu VAL IT : la gouvernance des investissements informatiques Val IT (Enterprise Value : Governance of IT investments) est un cadre de référence pour la gouvernance des investissements informatiques. En effet, les projets de transformation de l'entreprise et de ses processus comportent de plus en plus souvent une composante informatique significative. A l'échelle d'une entreprise ou d'une organisation, il n'est pas rare qu'une centaine de projets soient menés en parallèle, à des stades de développement divers. Les directions générales exigent de plus en plus de transparence sur les apports des projets et souhaitent pouvoir étayer leurs décisions et arbitrer ou réviser les choix effectués. Dès lors que les demandes existent, en matière de projets, il convient alors de se poser quelques bonnes questions : Les investissements informatiques consentis sont-ils réellement générateurs de valeur, pour l entreprise, Et ce, à un coût acceptable, Et à un niveau de risque maîtrisé? Ce qui est schématisé par VAL IT sous la forme des quatres questions clés : Les 3 domaines de Val IT Val IT décompose sa méthodologie en 3 domaines : La gouvernance de la valeur (GV) : a pour objectif de s'assurer que le concept de valeur est présent dans les pratiques de management La gestion de portefeuille (GP) : vise à optimiser la création de valeur à travers la construction du portefeuille d'investissement La gestion des investissement (GI) : vise à assurer la rentabilité de chaque investissement ou "programme" pris isolément. 5/11
Val IT se place du point du vue de la gouvernance d'entreprise Fait on les bonnes choses (question stratégique)? En retire t-on des bénéfices (question sur la valeur)? CoBIT se place du point de vue de l'it Fait on les choses de la bonne façon (question sur l'architecture)? Est-ce qu'on les réalise correctement (question de la réalisation)? 6/11
Le suivi des coûts d'un projet Le pilotage des coûts doit permettre de respecter le budget pendant toute la durée du projet. Il est possible de réviser les conditions initiales, selon les modalités suivantes : un avenant budgétaire est accordé par la MOA, augmentant les ressources existantes ; une redistribution interne entre lignes budgétaires (à budget global constant) est acceptée par la MOA ; une modification nécessaire du cahier des charges est décelée par la MOE et acceptée par la MOA. L'objectif du pilotage des coûts est de détecter rapidement les écarts entre les prévisions et le réalisé, et d'en analyser les raisons. Le budget doit pour cela être décomposé en lignes budgétaires correspondant aux différentes tâches identifiées dans le calendrier détaillé (lotissement des actions à mener). Pour un pilotage efficace des coûts et une détection précoce des éventuels dérapages, le budget ne doit pas être défini à un niveau trop général ou trop détaillé. L'utilisation d'outils de gestion de projet est souvent nécessaire pour faciliter la remontée et la consolidation des informations. La courbe en S est un bon outil pour déterminer retards et écarts à un instant t et pour mesurer leur impact sur les engagements de fin de projet. Dans la courbe en S, il s'agit de comparer respectivement : ce qui est prévu au budget (coût budgété du travail prévu : CBTP) ; et ce qui est réalisé (coût réel du travail effectué : CRTE) ; au coût budgété du travail effectué (CBTE : Valeur budgétaire du travail réalisé ou Valeur acquise = Valorisation des tâches effectuées par leurs coûts prévisionnels définis dans le budget à date). Toutefois, la rentabilité ne s exprime pas uniquement par un chiffre. Elle traduit aussi les conditions de réalisation effective des gains, surtout lorsqu il s agit de gains de personnel qui comptent souvent pour près de 50 % des gains apportés par les technologies, conditions qui relèvent du management de l entreprise et pas des technologies en tant que telles. Légende J0 et Jc dates de début et de fin du projet. Jp date prévisionnelle d achèvement, estimée au jour j. B budget encouru au jour j. BD budget à date. D coût encouru. C valeur budgétaire du réalisé dans les conditions conduisant au budget à date (BD). CP coût prévisionnel de l affaire complète, réestimé au jour J. 7/11
Le diagramme met en évidence les retards (écarts de planning) et les dépassements (écarts de coût). Les méthodes de calcul de ces indicateurs et les écarts qui en résultent sont conformes aux prescriptions du Project Management Institute (PMI) dans le contenu de son référentiel Project Management Body of Knowledge (PMBOK). Le pilotage économique d'un projet se fait à travers des indicateurs dits normalisés qui constituent un tableau de bord dont l'objectif est de faciliter le suivi du projet. À une date donnée, qualifiée par ailleurs de «date d'état», ces indicateurs fournissent des informations sur l'utilisation des ressources affectées au projet. Les dates d'état peuvent être (pré)définies au début du projet ou tout simplement fixées selon les besoins de contrôle et de gestion des ressources. Dans le premier cas, ces dates découlent du «plan projet" et donc des livrables (intermédiaires) qui lui sont associés. Dans le second cas, le choix des dates d'état peut résulter d'une nécessité d'évaluation (de régulation) pour soutenir, le cas échéant, des décisions de gestion parmi lesquelles : la révision des coûts liés aux ressources utilisées pour le projet ; l'estimation du budget global au terme du projet ; le choix d'actions correctrices ; Le tableau de bord d'un projet repose essentiellement sur le «Budget du projet», entendu ici comme l'ensemble des coûts planifiés pour l'exécution complète des activités du projet. Il est désigné par l'acronyme BAC (Budget At Completion). Ainsi, à la date d'état (T), trois indicateurs peuvent être mis en évidence et faire l'objet d'analyse : Début (D) Date d'état (T) Fin (F) CBTP, CBTE, CRTE BAC = Budget du projet CBTP : Coût Budgété du Travail Prévu (Valeur Planifiée) : La courbe 1 représente le budget prévisionnel du projet c'est à dire la portion du budget global prévue pour être engagée à la date d'état T. Il contient le cumul des coûts prévisionnels jusqu'à la date d'état : CBTP = (coûts budgétés du travail prévu) Lorsque la planification est régulièrement distribuée dans le temps (du début à la fin du projet), le CBTP se calcule en déterminant le pourcentage (de budget) correspondant à la date d'état. CoefCBTP = (T - D) + 1 (F - D) + 1 Où : T = date d'état ; D = date de début du projet ; F = date de fin du projet. Le CBTP se calcule alors CBTP = CoefCBTP x BAC CBTE : Coût Budgété du Travail Effectué : La courbe 2 représente le coût prévu au budget des activités réalisées à la date d'état T. Il représente, en d'autres termes, le pourcentage du budget qui aurait dû être engagé à la date d'état pour le travail effectué. La valeur fictive obtenue par le calcul (travail éffectué x coût unitaire budgété) est souvent désigné par Earn Value (Valeur Acquise). CBTE = (coûts planifiés du travail prévu) Lorsque la planification est régulièrement distribuée dans le temps (du début à la fin du projet), le CBTE se calcule en déterminant le coefficient dû réalisé par rapport à la durée globale du projet. Ce coefficient s'obtient comme suit : CoefCBTE = TE (F - D) + 1 8/11
Où : TE = temps de travail effectué ; D = date de début du projet ; F = date de fin du projet. Le CBTE se calcule alors CBTE = CoefCBTE x BAC CRTE : Coût Réel du Travail Effectué : La courbe 3 représente les dépenses réelles engagées à la date d'état T pour le travail effectué (TE). CBTP : coût budgété du travail prévu. BCWS : Budgeted Cost of Work Scheduled CBTE : coût budgété du travail effectué BCWP : Budgeted Cost of Work Performed CRTE : coût réel du travail effectué. ACWP : Actual Cost of Work Performed Interprétation des écarts L écart entre les courbes CBTE et CBTP représente l écart entre le Travail Effectué et le Travail Prévu (axe des absices, le retard d avancement) : cet écart exprimé en coût (lecture sur l axe des ordonnées) s appelle la Variance délai (Schedule Variance). L écart entre les courbes CBTE et CRTE représente la différence en coûts entre le Coût Budgété et le Coût Réel : cet écart est nommé Variance coût (Cost Variance). Les écarts entre les trois catégories d'indicateurs décrits permettent d'apprécier l'avancement et/ou la bonne utilisation des ressources du projet. Écart de performance VC = Variance Cost : écart entre CBTE et CRTE VC = CBTE-CRTE Si VC < 0, (le coût réel > au coût budgété) : on dépense plus que prévu. Si VC > 0 ( le coût réel < au coût budgété) : on dépense moins que prévu. Écart de planning VS = Variance Schedule : écart entre CBTE et CBTP VS = CBTE - CBTP Si VS < 0, ( le travail effectif < au travail prévu) : on avance moins vite que ce qui était prévu. Si VS > 0 ( le travail effectif> au travail prévu) : on avance plus vite que ce qui était prévu. L'Estimation à l'achèvement (EAA) ou Forecast At Completion (FAC) désigne, par rapport au budget, la somme des dépenses engagées pour le travail effectué à la date d'état T et ce qui reste à réaliser pour l'exécution complète du projet. Il contient : FAC = CRTE + reste à réaliser Plus précisément, le calcul du «reste à réaliser» du budget implique le BAC, le CBTE et un indice dit de performance de coûts (lpc). La valeur maximale de cet indicateur est l'estimation des coûts jusqu'à l'achèvement, qui représente la meilleure estimation actuelle du coût total du projet. A remarquer que la valeur de l'eaa peut être différente de celle du BAC car on peut effectuer de meilleures estimations totales du coût au fur et à mesure que le projet progresse. Par conséquent, l'eaa peut changer selon les périodes de rapport. Écart sur budget (VAC = Variance At Completion) : l'écart entre le Budget (coût planifié) et l'estimation à l'achèvement (établie à la date d'état) : VAC = BAC - FAC Si VAC < 0 ( BAC < FAC) : le projet court un risque de dépassement du budget. 9/11
Si VAC > 0 (BAC> FAC) : les dépenses engagées à la date d'état sont dans les limites des prévisions. Il est encore possible de respecter les prévisions budgétaires. Les indices de performance L'Indice de Performance de Coût L'IPC ou en anglais Cost Performance Index (CPI) se calcule à la date d'état : IPC = CBTE / CRTE Le CRTE et le CBTE sont calculés à la date d'état T. L'IPC représente la quantité de travail accomplie pour chaque franc dépensé. Lorsque l'ipc a une valeur de 100%, l'équipe du projet livre 100 euros de travail planifié pour 100 euros dépensés. Un IPC de 80% signifie que l'on reçoit une valeur de 80 euros de travail planifié pour 100 euros de coût. Un IPC de moins de 100% peut indiquer que le rendement de l'équipe du projet n'est pas aussi bon que prévu, ou que le budget initial était trop serré pour la quantité de travaux à accomplir. Remarque : IPC doit être calculé avec les données cumulées. L'indice de performance Activité IPA = CBTE / CBTP L'IPA donne la mesure de la valeur gagnée cumulative sur la somme des valeurs planifiées des tâches prévues à date. Si l'indicateur est de 100%, cela signifie que l'équipe a respecté pleinement le budget. Si l'indicateur est inférieur à 100%, l'équipe a accompli moins de tâches que prévu. Le contraire si l'indicateur est supérieur à 100%. L'indice de performance globale IPG= IPA * IPC L'IPG exprime la performance globale de l'équipe de projet. Si le résultat est égal à 100%, l'équipe tient bien le projet en main. Si le résultat est inférieur ou supérieur à 100%, cela peut être le fait d'une sur ou sous-activité ou/et d'une sous ou sur-consommation de budget. L'indice de performance achèvement IPR = (BAC-CBTE) / (EAA-CRTE) L'IPR donne la projection future de la productivité moyenne nécessaire pour terminer le projet dans le cadre du budget estimé. Est calculé en divisant le travail qu'il reste à faire par l'estimation actuelle des coûts restants ou, autrement dit, le budget restant par le coût restant. L'indicateur IPR doit être utilisé conjointement à l'indicateur IPC. L'IPR doit être comparé à l'ipc afin de déterminer la mesure dans laquelle le coût total estimatif (EAA) le plus récent est réaliste pour le projet. Il faut remarquer que l'ipc mesure la productivité chronologique moyenne jusqu'à ce jour. Si l'ipr est supérieur à l'ipc, c'est que l'équipe du projet prévoit une amélioration de l'efficacité. On peut donc calibrer le coût total estimatif (EAA) du projet en comparant l'ipr à l'ipc. Exemple Les estimations faites pour un projet prévoient d'utiliser 4 ingénieurs et 3 programmeurs. Le salaire journalier prévu pour un Ingénieur est estimé à 900 et celui d'un Programmeur à 400. Le projet est planifié du 01/01/20xx au 31/07/20xx (on admet que tous les jours sont ouvrés) et que le projet a effectivement démarré à la date prévue. Le salaire journalier négocié en début de projet pour les ingénieurs est de 700 alors que celui des programmeurs est de 450. Au 15/01/20xx, on a enregistré 8 jours de travail effectif. 10/11
durée Début projet : Fin projet : Date état : Nb jours travail effectif : BAC = CBTP = CBTE = CRTE = VC = VS = IPC = IPA = IPG = IPR = FAC = VAC = 01/01/2013 31/07/2013 15/01/2013 8 1 017 600,00 72 000,00 38 400,00 33 200,00 5 200,00-33 600,00 115,66% 53,33% 61,69% 115,66% 879 800,00 137 800,00 Salaire journalier ingénieur programmeur 212 15 CoefCBTP = CoefCBTE = 7,08% 3,77% estimé 900 400 négocié 700 450 Effectif 4 3 72 000,00 38 400,00 On dépense moins que prévu On avance moins vite que ce qui était prévu On reçoit 116 euros de travail planifié pour 100 euros de cout l'équipe a accompli moins de tâches que prévu Attention, sur ou sous-activité ou bien sur ou sous consommation de budget Productivité moyenne à terme Les dépenses engagées à la date d'état sont dans les limites des prévisions 11/11