La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Gestion de Projet 3 – Planification et Gestion du Changement Préparé par : Gérard Battarel Pour : lUniversité René Descartes Octobre 2006 © Copyright 2004.

Présentations similaires


Présentation au sujet: "Gestion de Projet 3 – Planification et Gestion du Changement Préparé par : Gérard Battarel Pour : lUniversité René Descartes Octobre 2006 © Copyright 2004."— Transcription de la présentation:

1 Gestion de Projet 3 – Planification et Gestion du Changement Préparé par : Gérard Battarel Pour : lUniversité René Descartes Octobre 2006 © Copyright 2004 Gérard Battarel - Reproduction interdite sans autorisation de lauteur

2 2 Objectifs Savoir construire un plan de projet Savoir construire un plan de projet Aborder les problèmes destimation Aborder les problèmes destimation Aborder la gestion du risque Aborder la gestion du risque Savoir déterminer un chemin critique Savoir déterminer un chemin critique Comprendre les problèmes de la gestion du changement Comprendre les problèmes de la gestion du changement

3 3 Les domaines de connaissances de la gestion de projet Planification Planification Gestion du périmètre Gestion du périmètre Gestion des ressources humaines Gestion des ressources humaines Gestion du temps et des coûts Gestion du temps et des coûts Gestion de la qualité Gestion de la qualité Gestion de la communication Gestion de la communication Contractualisation et sous-traitance Contractualisation et sous-traitance

4 4 Planification et gestion de projet Objectif : construire une représentation du déroulement du projet qui va servir de guide au déroulement réel Objectif : construire une représentation du déroulement du projet qui va servir de guide au déroulement réel Challenge : un projet est unique et imprévisible, mais son existence est liée à la définition dun budget et dun calendrier Challenge : un projet est unique et imprévisible, mais son existence est liée à la définition dun budget et dun calendrier

5 5 Rôle du chef de projet Choisir la méthode Choisir la méthode Établir le plan selon la méthode Établir le plan selon la méthode –Savoir jusquoù aller dans le détail –Obtenir des estimations –Défendre les estimations et faire admettre le plan par tous Faire exécuter le plan Faire exécuter le plan Savoir quand remettre le plan existant en cause Savoir quand remettre le plan existant en cause

6 1- ESTIMATION Problématique Établissement dun plan global : méthodes descendantes

7 7 Planification Objet : construire un plan de projet indiquant la charge, la durée et le coût du projet et leur déploiement dans le temps, afin de : Objet : construire un plan de projet indiquant la charge, la durée et le coût du projet et leur déploiement dans le temps, afin de : –Connaître les ressources nécessaires au projet –Les mobiliser en temps voulu –Avoir un guide durant le déroulement

8 8 Sur quoi sappuie la planification Une découpe du projet en activités découlant dune méthode (choix méthodologique) Une découpe du projet en activités découlant dune méthode (choix méthodologique) Une détermination de la charge et des ressources nécessaires à lexécution de ces activités Une détermination de la charge et des ressources nécessaires à lexécution de ces activités La détermination dun chemin critique dont on déduit la durée du projet ou de ses phases La détermination dun chemin critique dont on déduit la durée du projet ou de ses phases Une évaluation du contexte du projet, traduite en termes de risques et de coûts associés Une évaluation du contexte du projet, traduite en termes de risques et de coûts associés

9 9 Le challenge de la planification 1. Un projet est unique et ne se déroule jamais comme prévu 2. Les informations nécessaires à la planification ne sont jamais disponibles au démarrage du projet 3. Le sponsor veut connaître dès le début le coût et la durée du projet

10 10 Comment aborder ce challenge ? Sappuyer sur les techniques qui vont être présentées Sappuyer sur les techniques qui vont être présentées Établir au départ une estimation globale dune situation « neutre » qui sera affinée et contextualisée progressivement Établir au départ une estimation globale dune situation « neutre » qui sera affinée et contextualisée progressivement Faire vivre le plan de projet Faire vivre le plan de projet Communiquer avec prudence Communiquer avec prudence

11 11 Deux approches Descendante (top down) : part dune vision macro du projet, et se fonde sur des métriques de projets similaires Descendante (top down) : part dune vision macro du projet, et se fonde sur des métriques de projets similaires Ascendante (bottom up) : part dune vision analytique du projet, et intègre les estimations de chacune des activités Ascendante (bottom up) : part dune vision analytique du projet, et intègre les estimations de chacune des activités

12 12 Ascendance ou descendance ? Méthode descendante Méthode descendante –Suppose quil existe des projets « similaires » –Suppose que des métriques adéquates sont connues pour ces projets –Ne peut fournir quune charge (ou un coût), pas une durée

13 13 Ascendance ou descendance ? Méthode ascendante : Méthode ascendante : –Suppose que les activités (et leurs dépendances) soient connues –Suppose que lon soit en mesure de les estimer –Fournit un plan de projet complet (charge, durée, coûts)

14 14 Charge et durée Charge = (temps * nb de ressources) Charge = (temps * nb de ressources) Quantité de travail exprimée en h*mois ou en unités dœuvre Coût = (temps * nb de ressources * coût unitaire dune ressource) Coût = (temps * nb de ressources * coût unitaire dune ressource)

15 Méthodes descendantes destimation COCOMO Points de fonctions

16 16 Méthodes descendantes : conditions dapplication Disposer dun modèle de complexité dun projet Disposer dun modèle de complexité dun projet Avoir une base de données de projets similaires traités selon la même méthode Avoir une base de données de projets similaires traités selon la même méthode

17 COCOMO

18 18 Modèle de complexité COCOMO 81 Conditions dapplication et limites : Base : Nombre de lignes de code source (KIS) Base : Nombre de lignes de code source (KIS) Choix dune catégorie fonction de dépendances plus au moins fortes des programmes aux contraintes de lenvironnement : types S, P et E Choix dune catégorie fonction de dépendances plus au moins fortes des programmes aux contraintes de lenvironnement : types S, P et E

19 19 Modèle de complexité COCOMO 81 Trois modèles : Trois modèles : –De base : établit des équations de relation effort-temps-nombre de lignes de code –Intermédiaire : affine le modèle de base pour leffort seulement (facteurs de coût) –Détaillé : ajustement des facteurs de coût

20 20 Modèle COCOMO 81 Les catégories de projets Les catégories de projets –S : spécifications stables et détaillées –P : classe de problèmes dont les critères de résolution varient selon lusager Complexité polynomiale Complexité polynomiale –E : répondent à des stimuli aléatoires de lenvironnement Complexité exponentielle Complexité exponentielle

21 21 Modèle COCOMO 81 Les phases de construction Modèle de planification (cycle en V) : 1. Expression du besoin 2. Développement 2.1 Conception générale Conception détaillée Codage & tests unitaires 2.3 Tests et intégration 3. Exploitation et support

22 22 Modèle COCOMO 81 Relations effort, durée, taille –EFF = a x KIS b –TDV = 2,5 x EFF c Paramètres par typologie (selon Boehm) Typeabc S2,41,050,38 P3,01,120,35 E3,61,200,32 Effectif moyen = EFF/TDV Productivité moyenne = KIS/EFF

23 23 Modèle COCOMO 81 Effort par phase (1/2) Leffort est donné en % du développement TypePhase 32 KIS 64 KIS 128 KIS S Définition du besoin Conception générale Réalisation Conception tech. Conception tech. Développement Développement Tests et intégration P Définition du besoin Conception générale Réalisation Conception tech. Conception tech. Développement Développement Tests et intégration

24 24 Modèle COCOMO 81 Effort par phase (1/2) Leffort est donné en % du développement TypePhase 32 KIS 64 KIS 128 KIS E Définition du besoin Conception générale Réalisation Conception tech. Conception tech. Développement Développement Tests et intégration

25 25 Modèle COCOMO 81 Durée par phase (1/2) La durée est donné en % du développement TypePhase 32 KIS 64 KIS 128 KIS S Définition du besoin Conception générale Réalisation Tests et intégration P Définition du besoin Conception générale Réalisation Tests et intégration

26 26 Modèle COCOMO 81 Durée par phase (1/2) La durée est donné en % du développement TypePhase 32 KIS 64 KIS 128 KIS E Définition du besoin Conception générale Réalisation Tests et intégration

27 27 Modèle COCOMO 81 Les limites : 1. Une application est le plus souvent un assemblage S,P,E 2. La reprise de composants existants nest pas prise en compte, ni lutilisation de progiciels 3. La notion de KIS doit être précisée –Commentaires –Style de programmation –Classe de langage utilisée Pour plus de détails sur 1 & 3, voir Coûts et durée des projets informatiques, J. Printz et al, Hermès Science 2002

28 28 Modèle COCOMO 81 Facteurs de coût Principe : Les estimations « » du développement (phase 2) sont pondérées par des facteurs dont on fait le produit. Exemple : Estimation = 100 Architecte expérimenté = 0,9 Programmation débutants = 1,2 Planning très tendu = 1,1 Estimation corrigée = 100 x 0,9 x 1,2 x 1,1 = 118,8

29 29 Modèle COCOMO 81 Facteurs de coût Difficulté de lapplication A1 = Contraintes de lapplication A2 = Base de données A3 = Algorithmes complexes Expériences / maturité du personnel R1 = Architecte R2 = Domaine applicatif connu R3 = Programmeurs R4 = Langages Attributs du projet P1 = Pratiques de programmation P2 = Outils logiciels P3 = Plannings

30 30 Modèle COCOMO 81 Facteurs de coût Facteur Très bas BasMoyenElevé Très élevé A A A R R R R41,141,0710,95 P11,241,1010,910,82 P21,241,1010,910,83 P31,231,0811,041,10

31 31 COCOMO 81 Facteurs dajustement par phase Les facteurs de coût ne sappliquent pas uniformément au cours du projet : un coefficient dajustement est nécessaire Exemple : Architectes (facteur R1) Phase/niveau Très bas Bas Moyen Elevé Très élevé

32 32 COCOMO II Objectif : Améliorer le COCOMO 81 en prenant en compte : prenant en compte : Une architecture de processus (itérative) mieux adaptée que le cycle en V Une architecture de processus (itérative) mieux adaptée que le cycle en V Lajustement des paramètres aux nouvelles pratiques et nouveaux types de projets Lajustement des paramètres aux nouvelles pratiques et nouveaux types de projets

33 33 COCOMO II Périmètre : 5 types de pratiques 1. Solutions pour lutilisateur final : cest lusager qui développe (hors modèle) 2. Développement dinfrastructures systèmes distribués et middleware 3. Génération et adaptions dapplications progiciels de gestion de grande taille (ERP) 4. Composition assemblage dapplications développement à partir de progiciels et composants distants (EAI, IAI) 5. Intégration de systèmes = systèmes complexes exigeants, comportant une grande part de développement spécifique.

34 34 COCOMO II - Cycle de référence Faisabilité Maquettes Définition Prototypes Architecture stabilisée Développement Cycles : V1 – Exploitation V2 – Exploitation Vn - Exploitation Utilisation des Points de fonction Deux jeux de facteurs : - Estimation initiale (6) - Post architecture (16)

35 35 COCOMO - Conclusion Complexité de COCOMO II Complexité de COCOMO II Centré sur le développement : ninclut pas certains facteurs de coût liés à la MOA Centré sur le développement : ninclut pas certains facteurs de coût liés à la MOA Subjectivité de certains paramètres Subjectivité de certains paramètres Approche ingénieur (KIS) dans COCOMO 81 Approche ingénieur (KIS) dans COCOMO 81

36 36 Ce quil faut en retenir Utilisation possible avec des précautions (analyse fonctionnelle non incluse) Utilisation possible avec des précautions (analyse fonctionnelle non incluse) Possibilité dutilisation a posteriori pour construire une base de références Possibilité dutilisation a posteriori pour construire une base de références Outil de contrôle de vraisemblance Outil de contrôle de vraisemblance Utilisation des facteurs de coût en analyse des risques Utilisation des facteurs de coût en analyse des risques

37 37 COCOMO Pour plus dinformations Coûts et durée des projets informatiques - J. Printz et al, Hermès Sciences, 2001 Coûts et durée des projets informatiques - J. Printz et al, Hermès Sciences, 2001 Software engineering economics. B. Boehm, Prentice Hall, 1981 Software engineering economics. B. Boehm, Prentice Hall, 1981 Software cost estimation with COCOMO II - B. Boehm et al, Prentice Hall, 2000 Software cost estimation with COCOMO II - B. Boehm et al, Prentice Hall, 2000 Estimating software costs - Capers Jones, McGraw Hill, 1998 Estimating software costs - Capers Jones, McGraw Hill, 1998

38 Points de fonction

39 39 Les points de fonction (PF) Part dun point de vue de lutilisateur (indépendant des choix de réalisation) Part dun point de vue de lutilisateur (indépendant des choix de réalisation) Mesure la taille fonctionnelle = mesure du service rendu Mesure la taille fonctionnelle = mesure du service rendu

40 40 Les points de fonction (PF) Périmètre dutilisation : Utilisable dès le début du projet Utilisable dès le début du projet Permet de comparer des projets Permet de comparer des projets Un des facteurs dune mesure destimation Un des facteurs dune mesure destimation Origine : Allan Albrecht (IBM, 1979) Origine : Allan Albrecht (IBM, 1979) Limites : Ne mesure pas la qualité Ne mesure pas la qualité Ne mesure pas les évolutions techniques ou ergonomiques Ne mesure pas les évolutions techniques ou ergonomiques Pas applicable aux très petits projets (<100 PF) Pas applicable aux très petits projets (<100 PF)

41 41 Les points de fonction Trois mesures : Simplifiée : en début de projet Simplifiée : en début de projet Brute : après les specs détaillées Brute : après les specs détaillées Nette : inclut les aspects non fonctionnels Nette : inclut les aspects non fonctionnels Cinq étapes : 1. Quel est le contexte ? 2. Les composants 3. Pondération des composants 4. Influence des aspects non fonctionnels 5. Calcul du nombre de PF net

42 42 Les points de fonction Étape 1 - Le contexte Types de projets : nouveau produit, sous-projet, évolution, progiciel Types de projets : nouveau produit, sous-projet, évolution, progiciel Utilisateur(s) Utilisateur(s) Périmètre : fonctions, données internes et externes, échanges de données Périmètre : fonctions, données internes et externes, échanges de données

43 43 Les points de fonction Étape 2 - Les composants Groupes de données (GD) Groupes de données (GD) –Niveau conceptuel (client, facture) –Internes (GDI) –Externes (GDE) Fonctions : processus élémentaires, indépendants, visibles de lutilisateur Fonctions : processus élémentaires, indépendants, visibles de lutilisateur

44 44 Les points de fonction Étape 2 - Les composants fonctions Les entrées (ENT) modifient les GDI ou le fonctionnement de lapplication, et font lobjet dun traitement non interruptible Les entrées (ENT) modifient les GDI ou le fonctionnement de lapplication, et font lobjet dun traitement non interruptible Ex : Saisie pour traitement Les sorties (SOR) : extraient et traitent des données avant restitution Les sorties (SOR) : extraient et traitent des données avant restitution Ex : Impression, rapport Les interrogations (INT) : extraction sans traitement Les interrogations (INT) : extraction sans traitement Ex : Visualisation, aide en ligne

45 45 Les points de fonction Étape 3 - Pondération Groupe de données : sous ensemble logique (SD) et données élémentaires (DE) Groupe de données : sous ensemble logique (SD) et données élémentaires (DE) Complexité des GDI et GDE Complexité des GDI et GDE DESD >50 1FaibleFaibleMoyen 2-5FaibleMoyenElevé >5MoyenElevéElevé Ex de SD : en tête de facture, ligne de commandeFaibleMoyenÉlevéGDI71015 GDE5710 Pondération

46 46 Les points de fonction Étape 3 - Pondération ENT : SOR ou INT : ENT : SOR ou INT : DEGD >19 0-1FaibleFaibleMoyen 2-3FaibleMoyenElevé >3MoyenElevéElevéDEGD FaibleFaibleMoyen 2FaibleMoyenElevé >2MoyenElevéElevé Pondération :FaibleMoyenElevéENT346 INT346 SOR457

47 47 Les points de fonction Étape 3 - Pondération Taille fonctionnelle PF Brut = PF des composants Données Fonctions

48 48 Les points de fonction Etape 4 - Ajustements Se rapprochent des facteurs de coût COCOMO 14 paramètres évalués sur une échelle = pas dinfluence ; 3 = influence moyenne Ajustement (AJ) = ( influences) / ,65

49 49 Les points de fonction Etape 4 - Ajustements Transmission de données Transmission de données Système distribué Système distribué Performances Performances Utilisation intensive Utilisation intensive Taux de transaction Taux de transaction Saisie interactive Saisie interactive Importance de lergonomie Importance de lergonomie Mises à jour en temps réel Mises à jour en temps réel Complexité des traitements Complexité des traitements Réutilisation Réutilisation Facilité dinstallation Facilité dinstallation Facilité dexploitation Facilité dexploitation Portabilité Portabilité Flexibilité Flexibilité

50 50 Les points de fonction - Exemple DonnéesGDDEComplx.PF Dossier client GDI6>50E15 FactureGDI420-50M10 Table Libellés GDI1 < 20 f7 Base Clients GDE10 > 50 E10 Fonctions F1 - Établir facture ENT > 2 > 15 E6 F2 - Modifier facture ENT > E6 F3 - Visualiser impayés INT21-4f3 F4 - Imprimer Facture SOR1>19M5 Total62

51 51 Les points de fonction Étape 5 - Calcul du PF net Étape optionnelle PF net = PF brut x Ajustement (AJ)

52 52 Les points de fonction Calcul de la taille dune évolution : PF évo = taille de lévolution PF add = taille des ajouts PF sup = taille des suppressions PF mod = Taille des modifications AJav = Ajustement avant le projet AJav = ajustement après le projet PF évo = (PF add + PF mod) x AJap + PF sup x AJav

53 53 Variante : La méthode MkII FPA Part des transactions logiques élémentaires qui franchissent les limites de lapplication (cas dusage externes) Part des transactions logiques élémentaires qui franchissent les limites de lapplication (cas dusage externes) On identifie les GD comme auparavant. Les transactions ont 3 composantes : entrée, traitement, sortie On identifie les GD comme auparavant. Les transactions ont 3 composantes : entrée, traitement, sortie La complexité est définie à partir du nombre de domaines élémentaires en entrée (DE) et en sortie (DS) et du nombre de groupes de données intervenant dans le traitement (DT) La complexité est définie à partir du nombre de domaines élémentaires en entrée (DE) et en sortie (DS) et du nombre de groupes de données intervenant dans le traitement (DT)

54 54 Passage des points de fonction à lestimation Fait appel à plusieurs paramètres : Taille du projet Taille du projet Environnement de réalisation Environnement de réalisation Contraintes techniques Contraintes techniques Objectifs de qualité Objectifs de qualité Problème : Paramètres très variables dune entreprise à lautre Paramètres très variables dune entreprise à lautre Bases statistiques inexistantes ou peu fiables Bases statistiques inexistantes ou peu fiables

55 55 Passage des points de fonction à lestimation Une solution : Se constituer sa base à partir de projets passés et la faire vivre Se constituer sa base à partir de projets passés et la faire vivre Utiliser la base pour déterminer la productivité Utiliser la base pour déterminer la productivité –Déterminer un « delivery rate » = PF produits/personne/mois Valeur type = projet Java : 0,25 à 0,5 PF / h x jour

56 56 Application des points de fonction Contractualisation Contractualisation Évaluation des évolutions Évaluation des évolutions Estimations ultérieures Estimations ultérieures Mesure de la qualité Mesure de la qualité

57 57 Que faire si la base de connaissances nexiste pas ? Trouver des experts Trouver des experts Définir des phases avec des points de go / no go Définir des phases avec des points de go / no go Prototyper et évaluer Prototyper et évaluer

58 58 Que faire face à lincertitude ? 4x 2x 1.5x 1.25x 1.0x 0.8x 0.67x 0.5x 0.25x 1.6x 1.25x 1.15x 1.25x 1.0x 0.9x 0.85x 0.25x 0.8x Source : Rapid Development (McConnell 1996) CoûtDurée Fin Specs initiales Specs détaillées Conception détaillée

59 59 Estimation par des experts Utiliser au moins 3 experts Utiliser au moins 3 experts Méthode Delphi et formule du PERT : Valeur estimée = (min + 4*moy + max) / 6 Méthode Delphi et formule du PERT : Valeur estimée = (min + 4*moy + max) / 6

60 60 Méthode Delphi Obtenir des estimations indépendantes Obtenir des estimations indépendantes En cas de divergence, rassembler les experts pour rechercher un consensus En cas de divergence, rassembler les experts pour rechercher un consensus Faire une moyenne pondérée sur lensemble des valeurs résultantes Faire une moyenne pondérée sur lensemble des valeurs résultantes

61 Exercice sur lestimation par des experts

62 62 Plan de projet global Objectif : déterminer les dates des échéances principales (milestone, ou jalon) du projet Objectif : déterminer les dates des échéances principales (milestone, ou jalon) du projet Les échéances correspondent à des livrables significatifs pour la maîtrise douvrage Les échéances correspondent à des livrables significatifs pour la maîtrise douvrage La communication doit saccompagner dune explicitation des hypothèses délaboration La communication doit saccompagner dune explicitation des hypothèses délaboration

63 63 Plan global Hypothèses délaboration Hypothèses délaboration Par phase : Par phase : –Date de démarrage –Livrables –Durée –Coût

64 2- Planification détaillée Estimation ascendante - tâches Construction du chemin critique Plan détaillé Lissage des ressources

65 65 Limites du plan de projet global Approximation : Approximation : –Ignore les ressources réellement affectées au projet –Ignore les dépendances avec dautres projets ou événements externes –Fait des hypothèses sur le déroulement du projet Cette approximation peut suffire dans un premier temps pour déterminer une fenêtre de vraisemblance, mais il faut lui ajouter un plan détaillé, au moins sur le court terme (1 semaine à 1 mois)

66 66 Plan de projet détaillé La construction du plan détaillé repose sur une approche ascendante : –Détermination des tâches –Détermination des dépendances –Détermination des ressources –Estimation des durées –Détermination du chemin critique

67 67 Approche de la planification ascendante Partir du processus de réalisation (méthode) pour estimer Partir du processus de réalisation (méthode) pour estimer Le plan de repose pas sur le produit, mais sur les étapes de sa construction Le plan de repose pas sur le produit, mais sur les étapes de sa construction Phase Phase –Activité Tâche Tâche

68 68 Tâches Tâche : sous-ensemble dune activité à laquelle on peut associer : Tâche : sous-ensemble dune activité à laquelle on peut associer : –Des ressources –Des résultats –Une durée dexécution Exemples : Exemples : –Réunion –Construction dun mur –Validation dun document livré –Codage dune module logiciel

69 69 Décomposition en sous tâches Décomposition dun tâche en sous- ensembles : la tâche est terminée lorsque toutes les sous tâches le sont Décomposition dun tâche en sous- ensembles : la tâche est terminée lorsque toutes les sous tâches le sont Objectif : donner une visibilité de détail Objectif : donner une visibilité de détail Peut être héritée dune méthodologie Peut être héritée dune méthodologie Indispensable au chef de projet Indispensable au chef de projet Dangers : Dangers : –Omission –Détail excessif

70 70 Décomposition en sous tâches Exemple : Production dun document –Production dune première version Production des chapitres techniques Production des chapitres techniques Écriture du sommaire Écriture du sommaire Revue interne Revue interne Modifications Modifications –Révision par les utilisateurs –Prise en compte des remarques –Soumission pour approbation

71 71 Sur quoi sappuie la planification détaillée Une découpe du projet en tâches découlant dune méthode (choix méthodologique) Une découpe du projet en tâches découlant dune méthode (choix méthodologique) Une détermination de la charge et des ressources nécessaires à lexécution de ces tâches Une détermination de la charge et des ressources nécessaires à lexécution de ces tâches La détermination dun chemin critique dont on déduit la durée du projet et de ses phases La détermination dun chemin critique dont on déduit la durée du projet et de ses phases Une évaluation du contexte du projet, traduite en termes de risques et de coûts associés Une évaluation du contexte du projet, traduite en termes de risques et de coûts associés

72 72 Quelques postulats Postulat n° 1 : Quelles que soient les ressources affectées à une activité, il existe une durée minimale dexécution Postulat n° 1 : Quelles que soient les ressources affectées à une activité, il existe une durée minimale dexécution Postulat n° 2 : Réduire la durée dune activité en augmente la charge ; lallonger excessivement également Postulat n° 2 : Réduire la durée dune activité en augmente la charge ; lallonger excessivement également

73 73 Quelques postulats Postulat n° 3 : Toute ressource supplémentaire affectée en dehors du chemin critique ne réduit pas la durée Postulat n° 3 : Toute ressource supplémentaire affectée en dehors du chemin critique ne réduit pas la durée Postulat n° 4 : Tous les coûts ne sont pas égaux ; certains sont des investissements dont il faut apprécier le retour (roi) Postulat n° 4 : Tous les coûts ne sont pas égaux ; certains sont des investissements dont il faut apprécier le retour (roi)

74 74 Les facteurs qui influencent Le temps disponible Le temps disponible Le budget Le budget Les fonctionnalités attendues Les fonctionnalités attendues La qualité attendue La qualité attendue Ces facteurs interagissent (cf. quadrature du chef de projet) Ils nont pas la même valeur pour tous les projets, ni dans un même projet pour tous les interlocuteurs

75 75 La gestion de projet, art de léquilibre fonctions qualité temps coût

76 76 Les facteurs qui influencent Temps : certains projets sont (vraiment) bornés dans le temps Temps : certains projets sont (vraiment) bornés dans le temps Budget : il doit intégrer les effets dinvestissement et les coûts sur la totalité du cycle de vie Budget : il doit intégrer les effets dinvestissement et les coûts sur la totalité du cycle de vie Fonctionnalités : sont-elles toutes nécessaires ? Fonctionnalités : sont-elles toutes nécessaires ? Qualité : règle logarithmique des coûts Qualité : règle logarithmique des coûts Il est essentiel pour le chef de projet de savoir quels paramètres sont réellement importants pour le projet

77 77 La qualité est un investissement payant… Si un défaut dun système informatique est détecté en analyse avec un coût de résolution de 1 unité, sa détection pendant la phase de programmation coûtera 10 unités, sa détection pendant les tests dintégration coûtera 100 unités, sa détection en production coûtera 1000 unités Analyse Tests Coût de résolution Échelle logarithmique

78 78 Le facteur temps Notion destimation à Notion destimation à Source : Rapid Development (McConnell 1996) Date de fin Fin daprès les estimations optimistes de développeurs La courbe de probabilité de livrer en un temps donné

79 79 Estimation Se placer dans des conditions « moyennes » Se placer dans des conditions « moyennes » –Disponibilité des utilisateurs –Disponibilité des ressources –Motivation des équipes –Expérience du chef de projet –Durée des journées de travail –Précision des besoins –Connaissance des technologies utilisées –Délais dapprobation des livrables –Délais liés au test –…

80 80 Estimation par des experts Utiliser au moins 3 experts Utiliser au moins 3 experts Utiliser la méthode Delphi en cas de divergence, ou la formule du PERT : (min + 4*moy + max) / 6 Utiliser la méthode Delphi en cas de divergence, ou la formule du PERT : (min + 4*moy + max) / 6 Si aucun accord ne peut être obtenu, repenser la méthodologie Si aucun accord ne peut être obtenu, repenser la méthodologie –Introduire une phase préliminaire réalisant tous les travaux qui permettront de préciser les estimations (ex : prototype)

81 81 La pression du planning Les programmeurs ont tendance à sous- estimer le temps nécessaire à une activité de 20 à 30% en moyenne Les programmeurs ont tendance à sous- estimer le temps nécessaire à une activité de 20 à 30% en moyenne Effet dune annonce optimiste : Effet dune annonce optimiste : –Tout chiffre donné est une parole donnée –Oblige à augmenter la « pression du planning » –Perte de crédibilité du plan de projet Effet dune annonce pessimiste : Effet dune annonce pessimiste : –Inacceptable en environnement concurrentiel –Effet négatif sur lénergie de léquipe –Ne marche pas deux fois de suite

82 82 La pression du planning Pression croissante Stress croissant Nombre derreurs croissant Coût et délai croissants

83 83 Que faire face à la pression du planning ? 1. Pour les projets réellement liés au temps, choisir une méthodologie de type RAD 2. Pour les autres, créer une attente réaliste, utiliser le pouvoir de négociation et affiner les estimations au fil du projet Un chef de projet doit refuser un projet quil estime infaisable

84 84 Prise en compte des risques Principe : appliquer un facteur de risque, par tâche ou groupe de tâches Principe : appliquer un facteur de risque, par tâche ou groupe de tâches Appliquer un facteur de risque arbitraire est une mauvaise pratique Appliquer un facteur de risque arbitraire est une mauvaise pratique –Appliquer un facteur avec discrimination (ex : activités de validation) –Effectuer une analyse des risques (voir la section Gestion des risques)

85 85 Passage de la charge au coût La charge obtenue par sommation des charges des activités ninclut pas les activités non directement productives : La charge obtenue par sommation des charges des activités ninclut pas les activités non directement productives : –Gestion de projet –Gestion de la qualité Le passage au coût suppose de connaître les ressources affectées. Une approximation consiste à avoir un coût unitaire moyen par type dactivité (ou globalement sur le projet) Le passage au coût suppose de connaître les ressources affectées. Une approximation consiste à avoir un coût unitaire moyen par type dactivité (ou globalement sur le projet) Ex : dans lexercice précédent, gestion = 500/j, autre = 350/j Ex : dans lexercice précédent, gestion = 500/j, autre = 350/j

86 86 Passage de la charge au coût Il faut ajouter aux coûts de production les coûts indirects affectés au projet : Il faut ajouter aux coûts de production les coûts indirects affectés au projet : –Formation –Outillage (ex : licences logiciel) –Consommables Les coûts de gestion, comme ceux des consommables, sont linéaires, et dépendent donc de la durée Les coûts de gestion, comme ceux des consommables, sont linéaires, et dépendent donc de la durée –Gestion : application dun % de la charge totale –Consommables : intégrer dans les coûts en personnel (notion de jour chargé)

87 87 Passage de la charge à la durée La charge ne permet pas destimer la durée La charge ne permet pas destimer la durée Elle permet un contrôle de vraisemblance ou une estimation grossière Elle permet un contrôle de vraisemblance ou une estimation grossière Pour les activités dune personne unique : charge = durée (si la personne est à temps plein) Pour les activités dune personne unique : charge = durée (si la personne est à temps plein) Pour les activités partageables : durée type = k *racine cubique de la charge. Ex : une charge de 9 h*m partageable peut être réalisée à 3,5 personnes sur 2,5 mois Pour les activités partageables : durée type = k *racine cubique de la charge. Ex : une charge de 9 h*m partageable peut être réalisée à 3,5 personnes sur 2,5 mois

88 88 Plan de projet global Objectif : déterminer les dates des échéances principales (milestone, ou jalon) du projet Objectif : déterminer les dates des échéances principales (milestone, ou jalon) du projet Les échéances correspondent à des livrables signifiants pour la maîtrise douvrage Les échéances correspondent à des livrables signifiants pour la maîtrise douvrage Les dates type sont établies selon un processus descendant Les dates type sont établies selon un processus descendant La communication doit saccompagner dune explicitation des hypothèses délaboration La communication doit saccompagner dune explicitation des hypothèses délaboration

89 3- Construction du chemin critique

90 90 Dépendances entre tâches Dépendance fin – début (FD) Une tâche ne peut démarrer que si celle dont elle dépend est terminée Une tâche ne peut démarrer que si celle dont elle dépend est terminée Exemple : Analyse dun cas dusage – Analyse des variantes Tâche A Tâche B

91 91 Introduction dun délai Délai positif (retard) : Délai positif (retard) : Ex: On admet quil faut 8 jours aux utilisateurs pour fournir leurs remarques Délai négatif (avance) : Ex : On admet que lécriture du sommaire peut démarrer 3 jours avant la fin des chapitres techniques Première version Prise en compte des remarques +8j Chapitres techniques Sommaire - 3j

92 92 Diagramme de dépendances Exemple : Production dun document : toutes les tâches sont séquentielles, et le document est approuvé par défaut après 8 jours Exemple : Production dun document : toutes les tâches sont séquentielles, et le document est approuvé par défaut après 8 jours 1 re version Révisions Remarques Approbation + 8j

93 93 Chemin critique Définition : Cest la suite de tâches dont un changement dans la durée conduit à un changement de la durée du projet Définition : Cest la suite de tâches dont un changement dans la durée conduit à un changement de la durée du projet Exemple : Exemple : Durée ?

94 94 Chemin critique Concept essentiel : le chemin critique détermine la durée du projet Tout raccourcissement dune tâche sur le chemin critique raccourcit le projet (toutes choses égales dailleurs) Lallongement dune tâche non critique ne rallonge pas nécessairement le projet

95 95 Détermination du chemin critique 1. Représenter les tâches et leurs dépendances 2. Déterminer pour chaque tâche la date de démarrage au plus tôt, en partant du début du projet 3. En partant de la fin du projet, déterminer pour chaque tâche la date de démarrage au plus tard (en fin de projet, plus tôt = plus tard) 4. Chemin critique = ensemble des tâches dont la date au plus tôt = la date au plus tard

96 96 Détermination du chemin critique – Démarrage au plus tôt Date de démarrage au plus tôt : Date de démarrage au plus tôt : Pour chaque dépendance incidente, calculer la date de démarrage au plus tôt = date au plus tôt à lorigine + durée de lactivité + délai Pour le nœud, retenir la valeur la plus élevée de démarrage au plus tôt Au plus tôt Au plus tard x A

97 97 Démarrage au plus tôt

98 98 Détermination du chemin critique – Démarrage au plus tard Date de démarrage au plus tard : Date de démarrage au plus tard : Pour chaque dépendance sortante, calculer la date de démarrage au plus tard à lextrémité - délai Pour le nœud, retenir la valeur la plus basse, lui retrancher la durée de lactivité x A

99 99 Démarrage au plus tard

100 100 Dépendance Début – Début (DD) Indique la simultanéité : la tâche dépendante peut démarrer dès que la tâche dont elle dépend a démarré Indique la simultanéité : la tâche dépendante peut démarrer dès que la tâche dont elle dépend a démarré Exemple : tests et correction Exemple : tests et correction Tests Corrections

101 101 Dépendance Fin – Fin (FF) Indique que les résultats doivent être produits simultanément (avec ou sans délai) Indique que les résultats doivent être produits simultanément (avec ou sans délai) Exemple : livraison dun logiciel et de sa documentation Exemple : livraison dun logiciel et de sa documentation Logiciel Documentation

102 102 Dépendance Début –Fin (DF) Très peu utilisée, elle indique que la tâche dépendante doit se terminer quand la tâche dont elle dépend commence Très peu utilisée, elle indique que la tâche dépendante doit se terminer quand la tâche dont elle dépend commence Correspond à une planification « à lenvers », dictée par un événement figé dans le temps. Correspond à une planification « à lenvers », dictée par un événement figé dans le temps. Ex : Préparation dune conférence : la date de la conférence impose la fin de la préparation Ex : Préparation dune conférence : la date de la conférence impose la fin de la préparation Conférence Préparation

103 103 Diagramme de Gantt Cest une autre représentation du diagramme de dépendances Cest une autre représentation du diagramme de dépendances Voir transparent suivant

104 104

105 105 Quel niveau de détail ? Le niveau de détail du plan est le résultat dun compromis : –Trop de planification nuit –Pas assez ne donne pas la visibilité souhaitée Le plan doit vivre et servir. Il faut distinguer : –Le niveau de détail requis par la construction du plan –Le niveau de détail requis par le suivi Règle : la granularité des tâches doit être telle que lavancement est mesurable

106 106 Exercice : chemin critique Préparation dun cours N°TâcheDurée Dépendanc e Délai 1 Définir les objectifs et l'audience 3 2 Rassembler les matériaux Rédiger un résumé et soumettre 21 4 Inclure les commentaires 33 5 Programmer et diffuser l'annonce 1 3, 4 6 Rédiger le support 2 2, 4 7 Créer la présentation 3 2, 4 8 Répéter - Modifier 17 9 Publier le support 16 10Présenter1 5, 8, 9 5 : +5

107 107 Exercice : chemin critique Dans lexercice précédent : - Que se devient le chemin critique si on admet un recouvrement suite à une modification de méthodologie : - 1 unité entre tâches 7 et unités entre tâches 2 et 7 ?

108 Prise en compte des contraintes Liées au temps Liées aux ressources

109 109 Passage à un plan réel Le plan reste théorique tant que lon ne connaît pas : Le plan reste théorique tant que lon ne connaît pas : –La date de démarrage effective du projet –La nature exacte des ressources –La disponibilité des ressources

110 110 Contraintes liées au temps Deux types : Deux types : –Calendrier du programme et de disponibilité des ressources –Dépendances liées au temps (et non à la durée) Ex : contrainte de marketing ou autre, date légale, événement (conférence) Ex : contrainte de marketing ou autre, date légale, événement (conférence) Dépendance par rapport à un autre projet Dépendance par rapport à un autre projet

111 111 Allocation de ressources La construction initiale du plan peut aboutir à une situation ingérable du point de vue ressources : La construction initiale du plan peut aboutir à une situation ingérable du point de vue ressources : –Ressources indisponibles ou en nombre insuffisant –Variations deffectifs ingérables –Gestion du temps partiel Le profil de charge du projet donne une représentation de lutilisation des ressources au fil du temps Le profil de charge du projet donne une représentation de lutilisation des ressources au fil du temps

112 112 Diagramme dutilisation des ressources (plan de charge) Les ressources nétant en général pas interchangeables, on aura besoin dun diagramme par type de ressource Les ressources nétant en général pas interchangeables, on aura besoin dun diagramme par type de ressource Voir transparents suivants

113 113

114 114

115 115 Lissage des ressources Objet : introduire les contraintes sur les ressources dans le plan Objet : introduire les contraintes sur les ressources dans le plan –Commence par les tâches du chemin critique –Continue avec les ressources les plus difficiles à trouver Peut amener à allonger le projet Peut amener à allonger le projet Comment lisser : Comment lisser : –Itérer entre PERT et diagramme dutilisation en incorporant les contraintes, et en positionnant au mieux les tâches non critiques

116 116 Exemple de lissage On considère le projet suivant, composé de 4 tâches, réalisées par deux types de ressources A et B, aux caractéristiques suivantes : On considère le projet suivant, composé de 4 tâches, réalisées par deux types de ressources A et B, aux caractéristiques suivantes : Déterminer le plan de charge et le PERT qui minimisent les changements deffectifs, et la durée. Discuter Déterminer le plan de charge et le PERT qui minimisent les changements deffectifs, et la durée. Discuter TâchesDuréeDépendance Charge type A Charge type B T13 36 T23T163 T32T136 T43T31.50

117 117 Comment réduire la durée ? 1. Augmenter le nombre de ressources 2. Introduire un délai négatif dans les dépendances 3. Investir 4. Revoir la méthodologie Tenter de réduire la durée conduit à revoir tout le processus de planification, et se traduit par une augmentation des coûts et/ou des risques

118 3 - Maintenance du plan détaillé

119 119 Évolution du plan Un plan est : Un plan est : –Un outil de communication –Le résultat dune négociation et dun engagement correspondant à une vision à un moment donné de la vie du projet Les circonstances de la vie du projet peuvent amener à changer les conditions Les circonstances de la vie du projet peuvent amener à changer les conditions Faut-il changer le plan ? Faut-il changer le plan ? –Trop de changement = perte de crédibilité –Pas de changement = perte de réalisme et de confiance

120 120 Sources dévolution du plan Ce qui fait évoluer le plan : Ce qui fait évoluer le plan : –Des décalages entre planification et réalité Charge Charge Problèmes humains Problèmes humains Problèmes techniques Problèmes techniques –Des changements irréversibles du fait du projet Indisponibilité de ressources Indisponibilité de ressources Tâches oubliées Tâches oubliées –Des changements irréversibles externes au projet Périmètre Périmètre Dépendances externes Dépendances externes

121 121 Évolution du plan Quand modifier le plan : Quand modifier le plan : –A chaque suivi interne, si nécessaire, pour affecter les ressources aux tâches Quand communiquer les changements : Quand communiquer les changements : –Suite à un changement irréversible significatif ayant un impact sur les dates clés –Intérêt à minimiser le nombre de changements

122 122 Prise en compte du changement Conduit à gérer deux plans : Conduit à gérer deux plans : –Plan de référence (baselined), modifié le moins souvent possible, avec un processus de modification formel –Plan courant, interne à léquipe, détaillé et à gérer la cohérence entre les deux plans (gestion du risque)

123 123 Évolution du chemin critique Travail = Effectif (capacité) x Durée Types de tâches Capacité fixe : une augmentation de la durée Capacité fixe : une augmentation de la durée augmente la charge de travail augmente la charge de travail Durée fixe : durée ou date de fin imposée Durée fixe : durée ou date de fin imposée Le type de tâche introduit des réactions différentes au changement

124 124 Évolution du chemin critique Les modifications du plan détaillé peuvent conduire le chemin critique à se reporter sur dautres tâches Les modifications du plan détaillé peuvent conduire le chemin critique à se reporter sur dautres tâches Le plan de référence ne doit être mis à jour que pour refléter les changements importants (événements, risques) Le plan de référence ne doit être mis à jour que pour refléter les changements importants (événements, risques) Le plan détaillé doit suivre la situation du projet de près Le plan détaillé doit suivre la situation du projet de près

125 125 Ce quil faut retenir La planification est un aspect essentiel dun projet : elle conditionne les attentes La planification est un aspect essentiel dun projet : elle conditionne les attentes La planification nest pas une science exacte, mais cest une activité rigoureuse La planification nest pas une science exacte, mais cest une activité rigoureuse La dimension communication est essentielle La dimension communication est essentielle Trop de planning tue le planning (et le chef de projet !) Trop de planning tue le planning (et le chef de projet !)

126 126 Application Création dun plan détaillé avec : Création dun plan détaillé avec : –Création dun plan global –Constitution du PERT –Dépendances de diverses sortes –Affectation de facteurs de risque –Disponibilité limitée des ressources


Télécharger ppt "Gestion de Projet 3 – Planification et Gestion du Changement Préparé par : Gérard Battarel Pour : lUniversité René Descartes Octobre 2006 © Copyright 2004."

Présentations similaires


Annonces Google