S3. Management de l’informatique
1-2. Le pilotage d’un projet informatique / Synthèse et compléments
1. Synthèse :
Le pilotage d’un projet consiste à :
- planifier
- évaluer régulièrement les écarts entre le planifié et le réalisé
- analyser les raisons des dérives significatives
- estimer le « reste à faire » et re-planifier si besoin
La planification consiste en un découpage
structurel et temporel permettant de réduire la durée globale du projet dès lors qu’il est possible de mettre en parallèle la réalisation de lots de travaux et d’utiliser de manière optimale les ressources (humaines, matérielles et financières) allouées au projet. Par contre, les contraintes en terme de coordination des lots deviennent plus importantes (le lot le plus long constituant un goulet d’étranglement pour l’intégration de l’ensemble). La coordination prend du temps !
1 La première finalité d’un planning est
d’identifier des dates-clés pour la finalisations d’étapes intermédiaires (voir schéma ci-contre). Il est contractuel et rend crédible la réalisation du projet aux yeux du client, en prévoyant des rendez-vous réguliers avec celui-ci afin qu’il valide une étape avant de passer à la suivante, comme aux yeux de l’équipe-projet.
Le planning est en effet un outil très important
pour le chef de projet comme pour l’équipe toute entière. Outil de médiation, de coordination et de responsabilisation, il permet de partager une représentation commune du scénario de déroulement du projet jusqu’à son bon terme ; il permet à chacun de savoir qui attend le produit de son travail et de mieux accepter les efforts demandés pour respecter les délais.
1 D’où la boutade de F. Brooks qui, dans le « mythe du mois x homme », fustige la règle du mois x homme en affirmant que s’il faut 9 mois à une femme pour faire un enfant, inutile de penser à demander à 9 femmes de le faire en un mois ! Plus sérieusement, il estime que la mise en parallèle des tâches implique davantage de coordination, que celle-ci prend du temps, qu’elle est fréquemment sous-estimée et qu’il s’agit là de la principale raison du non respect des délais d’un projet
informatique. De même, si une tâche prend du retard, y affecter davantage de personnel peut s’avérer contre-productif si les développeurs travaillant déjà à cette tâche doivent passer leur temps à informer les nouveaux venus plutôt qu’à rattraper leur retard.
Un logiciel de planification permet d’identifier le chemin critique du projet, soit, pour un scénario
défini, l’ensemble des tâches pour lesquelles tout retard se traduit par une durée totale du projet plus longue que prévu. La réalisation de ces tâches doit être surveillée de près !
La planification ne doit surtout pas conduire à « ossifier » le pilotage du projet et conduire le CP à
refuser, au moment de la réalisation, tout écart par rapport au planifié. Il est normal que le scénario ne se déroule pas totalement comme prévu ! Le planning permet de repérer les écarts significatifs au plus tôt, de réfléchir aux raisons de cet écart (mauvaise prévision, réalisation d’un risque, d’un impondérable ?) et de réévaluer le meilleur scénario pour « rectifier le tir » (voir schéma ci-dessous).
Source : P. Mangold, « Gestion de projet informatique, Eyrolles
La coûtenance consiste à comparer le coût
direct du projet budgété (celui produit par la planification initiale effectuée sous logiciel de planification de projet) à celui réellement supporté par le MOE et d’interpréter le surcoût qui en résulte (ou l’économie réalisée). Il est en effet important de différencier l’insuffisance de productivité des développeurs d’un problème de planification. Si le coût global d’un projet ne se limite pas au coût direct (il faut lui ajouter une quote-part de frais fixes, des frais généraux), il est, pour l’essentiel, variable (proportionnel au temps). Cela signifie que pour maîtriser le coût du projet, il faut contrôler son coût direct puisqu’il est hypersensible à la durée du projet (surcoût des heures supplémentaires majorées).
2. Compléments :
Planification et cahiers des charges
La planification ne peut être faite qu’après rédaction des cahiers des charges utilisateur/réalisateur, même si ceux-ci sont susceptibles d’être révisés au cours du temps (leur révision impliquant, le cas échéant, une re-planification).
Il n’existe pas de « mode d’emploi » généraliste pour la rédaction d’un « bon » cahier des charges.
Le cahier des charges utilisateur traduit en langage « naturel » les fonctions attendues par l’utilisateur de l’application informatique en projet.
Sa rédaction exige du temps : c’est en principe au maître d’ouvrage de le rédiger. Mais en pratique, un dialogue soutenu avec le MOE et le CP est souvent nécessaire. Il s’agit d’aboutir à une même représentation de l’application à réaliser. Pour cela, le MOE aidera son client à expliciter ses besoins. Il y a par exemple un saut qualitatif
important entre « je veux mieux connaître mes clients » et « je veux, à partir des ventes, enregistrées à partir de mon progiciel de facturation, identifier des profils de clients afin de développer une politique tarifaire et une politique d’offres commerciales individualisée (en fonction de leurs achats antérieurs).Et j’ai besoin d’une
application CRM pour cela (CRM : application logicielle de Customer Relationship Management - du management de la relation client).
La méthode classique « QQOQCPC » d’analyse de problème est souvent la plus simple à mettre en œuvre.
Elle consiste à répondre aux questions suivantes :
Quoi ? Quel est le résultat attendu ?
Quand ? A quelle date ?
Où ? …peut-on voir ce résultat ?
Qui ? …se charge d’obtenir ce résultat ?
Comment ? Avec quelles ressources humaines, matérielles, quelles sont les
compétences exigées ?
Pourquoi ? Quel problème sera résolu ?
Combien ? …cela va coûter ?
Gestion des priorités En cas de conflit entre ces questions dans quel ordre de priorité faut- il les traiter ?
Scott Berkun2, par exemple, propose la démarche suivante :
- énoncer un besoin, c’est s’efforcer de répondre à la question : que doit faire ou permettre le produit (l’application logicielle) ?
- formuler la fonctionnalité correspondante : comment l’utilisateur doit s’y prendre ? - puis la spécification correspondante : Quel travail faudra-t-il réaliser pour cela ?
- alors il est possible de constituer la liste des tâches à réaliser : Qui va le faire, avec quoi et en combien de temps ?
- sans oublier les jeux de tests et critères de tests ou quel doit être le comportement du code pour que les objectifs de qualité assignés soient atteints ?
Alors, la rédaction du cahier des charges réalisateur sera facilitée. Au MOE de choisir, parmi les différentes solutions possibles la solution la plus pertinente (en fonction des compétences disponibles, de la marge
escomptée…) et de l’expliciter en décrivant précisément ce qu’il va faire : création d’une base de données, de tel ou tel programme… en spécifiant les contraintes matérielles et logicielles du projet.
Il n’est pas forcément aisé, lors de l’étude des besoins, de différencier les enjeux des objectifs d’un projet.
L’exemple particulier qui suit montre que pour certains projets la différence peut être très importante : - clarifier les enjeux du projet Pourquoi ?
- clarifier les objectifs du projet Quoi ?
A priori, c’est au client ou MOA du projet de répondre à la 1ère question, soit, d’expliciter au prestataire ou MOE les raisons pour lesquelles ce projet est mis en œuvre ; mais il est important que le MOE sache « de quoi il retourne »
2 « L’art du management de projet » 0’Reilly, 2005
Ex : une SSII a pour mission d’implémenter un ERP comprenant des modules de facturation, de comptabilité et de paie dans le service comptable de son client. Un comité de pilotage est formé avec le chef de projet (informaticien de la SSII) le chef comptable de l’entreprise cliente et 3 salariés du service comptable chargés à l’issue du projet de former leurs collègues. Le chef de projet n’est pas satisfait de la 1ère entrevue. Seul le chef comptable s’est exprimé ; aucun des salariés, futurs utilisateurs n’a souhaité s’exprimer. La raison sera révélée après des entretiens téléphoniques informels avec le chef comptable et l’un des salariés du comité. Le premier ne veut pas informatiser en tant que tel son service de gestion. Pour lui ce projet est une opportunité de remise à plat des processus de gestion comme de l’organisation du travail. Il a des comptes à rendre à la DG de l’entreprise et se doit d’améliorer la productivité de son service. La salariée contactée lui avoue ses craintes : pour elle et la plupart de ses collègues, l’avenir apparaît incertain : leurs méthodes de travail sont chamboulées et elle a peur de « scier la branche sur laquelle elle est assise ». Par conséquent elle n’a pas le cœur à l’ouvrage.
Finalement, le projet aboutira. Mais il aura fallu que le chef de projet aborde la question avec le chef du service comptable. Celui-ci, lors de la deuxième réunion, assura l’ensemble des salariés que la direction n’avait aucunement l’intention de supprimer des emplois mais qu’il était stratégique, à ses yeux, de moderniser et ainsi, de rendre plus fiables les SIC. En outre, le travail ultérieur de chacun s’en trouverait revalorisé puisque la maîtrise de PGI devenait indispensable à tout gestionnaire.
Par contre, la clarification des objectifs doit être construite de concert. Le MOA doit être en mesure de décrire ce qu’il veut – les fonctionnalités attendues du logiciel – mais c’est au MOE de vérifier qu’il est en mesure de les réaliser (moyens humains, matériels et logiciels, possibilités de sous-traitance…) et les deux parties doivent s’assurer qu’elles se font bien la même représentation de ces fonctionnalités. En outre, lorsque les fonctionnalités demandées sont trop ambitieuses en nombre, il s’agit de les prioriser (version 1 pour telle date, version 2 pour telle autre…).
Il existe plusieurs méthodes d’évaluation de la durée des tâches composant le projet. Une méthode empirique (dite des tiers) consiste à dire que pour une heure de programmation, il faut prévoir une heure en amont d’analyse et de conception et une heure en aval de test et de documentation. Pour autant, cette règle ne permet pas de dire combien de temps prendra la programmation d’une instruction ni, a fortiori, d’un module logiciel ! Des méthodes analytiques existent (voir cours de C. Nicolle) : méthode COCOMO3, méthode des points fonctionnels4, … mais attention ! une étude effectuée par C. Morley révèle des écarts de temps prévisionnel extrêmement importants lorsqu’elles sont appliquées au même programme, sans que l’on puisse a priori dire laquelle de ces méthodes est la plus pertinente5 !
La gestion des risques doit être menée en parallèle de la planification : elle repose sur une démarche simple : - repérer les risques d’erreurs probables : panne d’ordinateur, maladie d’un développeur, rendez-vous retardé
par le client… susceptible de retarder le projet, de le rendre plus coûteux…
- envisager une parade : prévoir du personnel de remplacement, souscrire un contrat de maintenance, d’assurance…
- ou/et prévoir une marge de temps et dans le budget (provision).
Cette gestion s’améliore avec l’expérience. Pour bien faire, il est donc très important de consacrer du temps, en fin de projet, à en faire le bilan, avant de passer au suivant afin de ne pas réitérer les mêmes erreurs.
Du point de vue financier, le seuil de rentabilité reste l’indicateur prévisionnel le plus courant pour apprécier le risque (de perte financière) lié au projet.
En outre, c’est l’un des critères les plus importants de l’infogérance (lorsque la direction du projet envisage de sous-traiter une partie des travaux).
3 Cocomo : Constructive Cost Model, de B.W.Boehm, 1981, méthode qui évalue la charge du projet (en j x homme) en fonction du nombre de lignes de programme source testées et de la complexité du projet, une formule permettant de convertir la charge en durée.
4 Méthode proposée par Alan Albrecht d’IBM en 1979, la charge étant estimée à partir de l’étendue et la complexité des fonctions attendues par le client.
5 Pour une présentation de cette étude : C. Morley, Management d’un projet SI », Dunod pp 45-65
La coûtenance peut également être utile pour un prestataire, dans sa relation avec son client à fixer le prix d’une prestation et à définir un échéancier de règlement lui permettant d’éviter tout problème de trésorerie. Le cas Infosoft propose cette étude.
Enfin, en amont de la planification, le directeur de projets d’une SSII par exemple, évaluera la rentabilité financière en tant que telle d’un projet afin de décider si oui ou non la société doit réaliser le projet. Le principal indicateur de rentabilité est la valeur actuelle nette (VAN). Son calcul repose sur l’actualisation.
En effet, un projet, comme un investissement, peut exiger de la part de la SSII qu’elle avance de lourdes sommes au départ pour préparer le projet, tandis qu’elle ne percevra le fruit de cet engagement qu’une fois la prestation réalisée.
Il en va de même pour une entreprise qui demande à son service informatique de moderniser ses services : les gains de productivité ne seront perçus qu’une fois
l’informatisation des services achevée, le personnel dûment formé et après quelques semaines de mise en route !
Aussi, la VAN mesure la valeur aujourd’hui des retours sur investissement obtenus demain :
VAN = - I + i=1 à n [FNTi / (1 + )i] Avec I, l’investissement initial
FNT = le flux net de trésorerie (le gain d’une période) le taux d’actualisation ou coût du risque encouru estimé par le prestataire ou la société
La VAN représente donc ce que aujourd’hui l’entreprise estime gagner de la réalisation de son projet net de la valeur initialement dépensée. Aissi, si elle est positive, alors le projet est rentable. Dans le cas contraire, le projet doit être rejeté (sauf considération commerciale ou professionnelle).
Bien entendu, la décision dépend du taux d’actualisation retenu ; plus celui-ci est élevé et plus la VAN est faible (plus le risque est élevé donc plus la préférence pour le présent est forte et plus la valeur présente d’un flux éloigné dans le temps est faible).
évolution de la VAN en fonction du taux d'actualisation
-400 -200 0 200 400 600 800 1 000
8% 9% 10
% 11
% 12
% 13
% 14
% 15
% 16
% 17
% 18
% 19
% 20
% 21
% 22
% 23
% 24
% 25
% 26
% 27
% 28
% 29
% 30
% taux d'actualisation
VAN
Si les surfaces hachurées situées au dessus de la courbe des dépenses sont égales à celles situées au dessous, le versement de l'acompte de x % en t0, de y % en t1 et de z % en t2 permet au vendeur de ne jamais être en découvert : le versement effectué à la fin du projet, au temps t représente en général le profit du vendeur. Il faut, évidement, que les acomptes x, y, z, soient encaissés effectivement aux temps t0, t1, t2, pour que le compte soit juste, et par conséquent, que la facturation tienne compte du délai de règlement : l’établissement de l'échéancier de facturation est un exercice délicat, où doivent intervenir les exécutants, les estimateurs et les comptables.
Remarque : Le taux d’actualisation pour lequel la VAN est nulle est appelé taux interne de rentabilité (TIR).
Dans l’exemple ci-dessus, il vaut 24,6 %6. Il est supérieur au taux attendu de 12% et permet d’apprécier le différentiel de rentabilité attendu par rapport à d’autres projets analogues.
En conclusion, il ne faut cependant pas exagérer l’importance des critères financiers :
- il est rare de refuser un projet (et donc un contrat avec un client !) pour une rentabilité qui n’est connue qu’expost et sur le long terme !
- En outre, les évaluations qui précèdent ne reposent, par définition, que sur les flux (FNT) mesurables : or, les effets bénéfiques de nature qualitative ne sont pas pris en compte : ainsi, chaque projet réalisé, rentable ou non, est une expérience acquise qui, au moins pour partie, améliore l’efficacité des projets ultérieurs dès lors que l’entreprise sait capitaliser ses savoir-faire (effet d’apprentissage).
6
fonction TRI d’un tableur tel que excel.
Université de Bourgogne / 2004-2005 / IUT Dijon / Département informatique / IQ2
Nom : Prénom :
Groupe :
Devoir surveillé du / /05
Durée 1 heure
Toute documentation autorisée
Contexte : A partir du cahier des charges fonctionnelles, un projet de réalisation d’un logiciel de gestion de stock par la SSII Infosoft pour son client, la société de transport Translog SAS est estimé à 107 jours- homme.
Le chef de projet d’Infosoft prépare la planification et la coûtenance du projet.
Question 1. Qui est Maître d’ouvrage, qui est Maître d’œuvre du projet ? ( / 1) Maître d’ouvrage : ________________ Maître d’œuvre : __________________
Question 2. S’agit-il d’un contrat en régie ou au forfait ? ( / 1) _____________________________________________________________________
I. Planification
Le chef de projet a préparé, sous MS Project la planification suivante :
Tableau 1
N° Nom de la tâche Durée Coût f ixe Début Fin Noms ressources
1 début 0 jour 0,00 € Mer 01/06/05 Mer 01/06/05
2 études 30 jours 0,00 € Mer 01/06/05 Mar 12/07/05
3 étude préalable 10 jours 160,00 € Mer 01/06/05 Mar 14/06/05 chef de projet 4 étude détaillée 5 jours 40,00 € Mer 15/06/05 Mar 21/06/05 ingénieur conception 5 étude technique 15 jours 200,00 € Mer 22/06/05 Mar 12/07/05 ingénieur conception 6 développement 37 jours 0,00 € Mer 13/07/05 Jeu 01/09/05
7 dév eloppement-lot1 25 jours 400,00 € Mer 13/07/05 Mar 16/08/05 dév eloppeur 1 8 test-lot1 10 jours 250,00 € Mer 17/08/05 Mar 30/08/05 dév eloppeur 1 9 dév eloppement-lot2 20 jours 300,00 € Mer 13/07/05 Mar 09/08/05 dév eloppeur 2
10 test lot2 5 jours 200,00 € Mer 10/08/05 Mar 16/08/05 dév eloppeur 2
11 intégration 2 jours 100,00 € Mer 31/08/05 Jeu 01/09/05 dév eloppeur 1;dév eloppeur 2 12 liv raison-mise en œuv re 7 jours 100,00 € Ven 02/09/05 Lun 12/09/05 chef de projet
13 qualif ication 8 jours 50,00 € Mar 13/09/05 Jeu 22/09/05 ingénieur conception
14 f in 0 jour 0,00 € Jeu 22/09/05 Jeu 22/09/05
01/06
chef de projet
ingénieur conception
ingénieur conception
développeur 1 développeur 1 développeur 2
développeur 2
développeur 1;développeur 2 chef de projet
ingénieur conception 22/09
13 20 27 04 11 18 25 01 08 15 22 29 05 12 19 26 03 10 17 24 31 07
Jui 05 Jul 05 Aoû 05 Sep 05 Oct 05 Nov 05
Tableau 2. Gantt correspondant
N° Nom de la tâche 1 début 2 études
3 étude préalable 4 étude détaillée 5 étude technique 6 développement 7 dév eloppement-lot1 8 test-lot1 9 dév eloppement-lot2 10 test lot2 11 intégration 12 liv raison-mise en œuv re 13 qualif ication
14 f in
01/06
chef de projet
ingénieur conception
ingénieur conception
développeur 1 développeur 1 développeur 2
développeur 2
développeur 1;développeur 2 chef de projet
ingénieur conception 22/09
23 30 06 13 20 27 04 11 18 25 01 08 15 22 29 05 12 19 26 03 10 17 24 31 07 14 21 28
Mai 05 Jui 05 Jul 05 Aoû 05 Sep 05 Oct 05 Nov 05
Question 3. Identifiez le chemin critique (l’ensemble des tâches critiques dans leur ordre
chronologique) et les tâches non critiques (en évaluant la marge de temps libre sur chacune d’entre
elles) ( / 3)
Note : Il n’est pas nécessaire de présenter un organigramme des tâches (un PERT) mais il faut par contre justifier votre réponse et pour cela expliquer ce qu’est une tâche critique.
Réponse :
Question 4. La planification repose sur l’hypothèse d’une équipe fondée sur deux développeurs.
Quelle serait la date de fin de projet si l’équipe n’en comportait qu’un seul ? (…. / 1)
Note : la planification repose sur un calendrier standard (jours travaillés du lundi au vendredi inclus, 7 h par jour).
Réponse :
II. Coûtenance
Le chef de projet prépare également un tableau d’évaluation du coût du projet qui servira de base de négociation du prix de vente hors taxes du projet avec le client.
Pour simplifier, seul le coût direct du projet est évalué. Les charges relatives à la rémunération du directeur d’agence, de la gestionnaire et du commercial, ainsi que celles relatives aux locaux ne sont pas imputées.
Habituellement, le taux de marge appliqué avant négociation est de 40% du prix de vente
Tableau 3 Coût direct et variable du projet
Question 5. A l’aide des tableaux 1 et 3, évaluez le prix de vente Hors Taxes du projet, en
complétant le tableau 4 suivant (page 4). (…. / 3)
Question 6. La marge calculée ci-dessus représente-t-elle la marge bénéficiaire dégagée par
l’entreprise au titre de ce projet ? Pourquoi ? (… / 1 )
Tableau 4
Intervenants Chef de Ingénieur Dév. Dév. Total
Coût fixe
Coût globa
l
Projet Conception 1 2
phases du projet études
étude préalable étude détaillée étude technique développement développement-lot1 test-lot1
développement-lot2 test lot2
intégration
livraison-mise en œuvre qualification
Total Général
coût global
marge de l'entreprise :
Prix de vente minimum
du projet :
A faire sur Infosoft.xls ---
Le chef de projet a également préparé le budget de trésorerie simplifié du projet afin de négocier avec le client un échéancier de paiement de sorte que le besoin de financement soit nul tout au long du projet.
Tableau 5
échéancier décaissement
s encaissement
s solde solde
cumulé
études 1-juin
étude préalable 14-juin 7 096,00 €
étude détaillée 21-juin 3 024,00 €
étude technique 12-juil. 9 120,00 €
développement 13-juil.
développement-lot1 16-août 8 990,00 €
test-lot1 30-août 3 650,00 €
développement-lot2 9-août 7 180,00 €
test lot2 16-août 1 870,00 €
intégration 1-sept. 1 460,00 €
livraison-mise en œuvre 12-sept. 4 960,00 €
qualification 22-sept. 4 830,00 €
fin 23-sept.
Question 7. Proposez un échéancier de paiement en 4 fois (le solde de tout compte étant versé le 23 septembre) assurant à la société infosoft un besoin de financement nul tout au long du projet.
(…. / 3)
Note : toute solution satisfaisant cette contrainte est admise ; il suffit de compléter le tableau 5 (page 4).
Le chef de projet a également effectué une courte évaluation de la rentabilité du projet : Tableau 6
Evaluation du seuil de rentabilité, du point mort et de la marge de sécurité
CF (coût fixe) 1800
CV (coût variable) 51100,00
CA (chiffre d'affaires hors taxes) 88166,67
MCV (marge sur coût variable) 37066,67 42,04%
SR (seuil de rentabilité en €)
durée totale en jour 82
point mort 52 13-août
marge de sécurité en % du CA 4,86%
marge de sécurité en J 30
Tableau 7
Evaluation de la valeur actuelle nette (VAN)
échéancier FNT
FNT actualisés
à 7%
1-juin 22041,6667 22 041,67 € 14-juin -7096 -7 077,35 € 21-juin -3024 -3 012,09 € 12-juil. -9120 -9 068,72 € 13-juil. 22041,6667 21 913,62 € 16-août -8990 -8 897,55 € 30-août -3650 -3 605,68 € 9-août -7180 -7 115,52 € 16-août -1870 -1 850,77 € 1-sept. 22041,6667 21 794,51 € 12-sept. -4960 -4 893,33 € 22-sept. -4830 -4 756,13 € 23-sept. 22041,6667 21 700,50 €
37 173,15 € =VAN à 7%
Question 8. Interprétez les principaux résultats des tableaux ci-dessus, en donnant la signification : (…. / 4)
- du seuil de rentabilité :
- du point mort :
- de la marge de sécurité (en % du CA ou en jours) :
- de la valeur actuelle nette ou VAN (à 7 %)
III. Suivi du projet
Le client ayant donné son accord, le projet a démarré le 01 juin comme prévu. Le chef de projet décide de
faire le point au 31 juillet.
Tableau 8 Suivi au 31 juillet
N° Nom de la tâche Début réel Fin réelle % achev é Durée réelle Durée restante Coût réel
1 début NC NC 0% 0 jour 0 jour 0,00 €
2 études Mer 01/06/05 Mar 12/07/05 100% 30 jours 0 jour 19 500,00 €
3 étude préalable Mer 01/06/05 Mer 15/06/05 100% 11 jours 0 jour 7 860,00 €
4 étude détaillée Jeu 16/06/05 Mar 21/06/05 100% 4 jours 0 jour 2 440,00 €
5 étude technique Mer 22/06/05 Mar 12/07/05 100% 15 jours 0 jour 9 200,00 €
6 développement Mer 13/07/05 NC 39% 15,36 jours 23,64 jours 9 469,00 €
7 dév eloppement-lot1 Mer 13/07/05 NC 48% 13 jours 14 jours 4 742,00 €
8 test-lot1 NC NC 0% 0 jour 10 jours 0,00 €
9 dév eloppement-lot2 Mer 13/07/05 NC 59% 13 jours 9 jours 4 727,00 €
10 test lot2 NC NC 0% 0 jour 5 jours 0,00 €
11 intégration NC NC 0% 0 jour 2 jours 0,00 €
12 liv raison-mise en œuv re NC NC 0% 0 jour 7 jours 0,00 €
13 qualif ication NC NC 0% 0 jour 8 jours 0,00 €
14 f in NC NC 0% 0 jour 0 jour 0,00 €
01/06
100%
100%
100%
100%
39% 48%
0% 59%
0% 0%
0% 0%
26/09 23 30 06 13 20 27 04 11 18 25 01 08 15 22 29 05 12 19 26 03 10 17
Mai 05 Jui 05 Jul 05 Aoû 05 Sep 05 Oct 05
Tableau 9. Gantt correspondant
N° Nom de la tâche Début réel
1 début NC
2 études Mer 01/06/05
3 étude préalable Mer 01/06/05 4 étude détaillée Jeu 16/06/05 5 étude technique Mer 22/06/05 6 développement Mer 13/07/05 7 dév eloppement-lot1 Mer 13/07/05
8 test-lot1 NC
9 dév eloppement-lot2 Mer 13/07/05
10 test lot2 NC
11 intégration NC
12 liv raison-mise en œuv re NC
13 qualif ication NC
14 f in NC
01/06
100%
100%
100%
100%
39%
48%
0%
59%
0%
0%
0%
0%
26/09
23 30 06 13 20 27 04 11 18 25 01 08 15 22 29 05 12 19 26 03 10 17 24 31 07 14 21 28 05 12 19 26 02 09 16 23 30 06 13 20 27 06
Mai 05 Jui 05 Jul 05 Aoû 05 Sep 05 Oct 05 Nov 05 Déc 05 Jan 06 Fév 06 Mar 06
Tableau 10. Audit des coûts coûtenance au 31
juillet (en €) CBTP CBTE CRTE VS VC phases
chef de projet 7000,00 7000,00 7860,00 0,00 -860,00 ét. Préalable et livraison ingénieur conception 3000,00 3000,00 2440,00 0,00 560,00 ét. Détaillée
9000,00 9000,00 9200,00 0,00 -200,00 ét. Tech. Et qualif.
développeur 1 4550,00 4212,92 4742,00 -337,08 -529,08 dév. Et test lot 1, intégration développeur 2 4550,00 4136,33 4727,00 -413,67 -590,67 dév. Et test lot 2, intégration totaux 28100,00 27349,25 28969,00 -750,75 -1619,75
Avec CBTP : coût budgété du travail prévu
CBTE : coût budgété du travail effectué (réel) CRTE : coût réel du travail effectué (ou réel)
VS : CBTE - CBTP ou écart de planning (si <0 = retard) - value schedule - VC : CBTE - CRTE ou écart de performance (si <0 = mauvaise performance ou surconsommation du temps par rapport à ce qui était planifié) - value cost -
