Gestion de Projet 3 – Planification et Gestion du Changement

Présentation au sujet: "Gestion de Projet 3 – Planification et Gestion du Changement"— Transcription de la présentation:

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

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

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

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 Challenge : un projet est unique et imprévisible, mais son existence est liée à la définition d’un budget et d’un calendrier

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

6 Problématique Établissement d’un plan global : méthodes descendantes
1- ESTIMATION Problématique Établissement d’un plan global : méthodes descendantes

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 : Connaître les ressources nécessaires au projet Les mobiliser en temps voulu Avoir un guide durant le déroulement

8 Sur quoi s’appuie la planification
Une découpe du projet en activités découlant d’une méthode (choix méthodologique) Une détermination de la charge et des ressources nécessaires à l’exécution de ces activités La détermination d’un 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

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

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

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

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

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

14 Charge et durée 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 d’une ressource)

15 Méthodes descendantes d’estimation
COCOMO Points de fonctions

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

17 COCOMO

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

19 Modèle de complexité COCOMO 81
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 l’effort seulement (facteurs de coût) Détaillé : ajustement des facteurs de coût

20 Modèle COCOMO 81 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 l’usager Complexité polynomiale E : répondent à des stimuli aléatoires de l’environnement Complexité exponentielle

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

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) Type a b c S 2,4 1,05 0,38 P 3,0 1,12 0,35 E 3,6 1,20 0,32 Effectif moyen = EFF/TDV Productivité moyenne = KIS/EFF

23 Modèle COCOMO 81 Effort par phase (1/2)
L’effort est donné en % du développement Type Phase 32 KIS 64 KIS 128 KIS S Définition du besoin Conception générale Réalisation Conception tech. Développement Tests et intégration 6 16 62 24 38 22 59 23 36 25 P 7 17 58 33 55 31 28 52 29

24 Modèle COCOMO 81 Effort par phase (1/2)
L’effort est donné en % du développement Type Phase 32 KIS 64 KIS 128 KIS E Définition du besoin Conception générale Réalisation Conception tech. Développement Tests et intégration 8 18 54 26 28 51 25 31 48 24 34

25 Modèle COCOMO 81 Durée par phase (1/2)
La durée est donné en % du développement Type Phase 32 KIS 64 KIS 128 KIS S Définition du besoin Conception générale Réalisation Tests et intégration 12 19 55 26 13 51 30 P 20 48 22 27 44 29 24 28 40

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

27 Modèle COCOMO 81 Les limites :
Une application est le plus souvent un assemblage S,P,E La reprise de composants existants n’est pas prise en compte, ni l’utilisation de progiciels 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 Modèle COCOMO 81 Facteurs de coût
Principe : Les estimations « 50-50 » 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 Modèle COCOMO 81 Facteurs de coût
Difficulté de l’application A1 = Contraintes de l’application 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 Modèle COCOMO 81 Facteurs de coût
Très bas Bas Moyen Elevé Très élevé A1 0.75 0.88 1 1.15 1.40 A2 0.94 1.08 1.16 A3 0.70 0.85 1.30 1.65 R1 1.46 1.19 0.86 0.71 R2 1.29 1.131 0.91 0.82 R3 1.42 1.17 R4 1,14 1,07 0,95 P1 1,24 1,10 0,91 0,82 P2 0,83 P3 1,23 1,08 1,04

31 COCOMO 81 Facteurs d’ajustement par phase
Les facteurs de coût ne s’appliquent pas uniformément au cours du projet : un coefficient d’ajustement est nécessaire Exemple : Architectes (facteur R1) Phase/niveau 2.1 2.2.1 2.2.2 2.3 Très bas 1.80 1.35 1.50 Bas 1.15 1.20 Moyen 1.00 Elevé 0.75 0.90 0.85 Très élevé 0.55 0.70

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

33 COCOMO II Périmètre : 5 types de pratiques
Solutions pour l’utilisateur final : c’est l’usager qui développe (hors modèle) Développement d’infrastructures systèmes distribués et middleware Génération et adaptions d’applications progiciels de gestion de grande taille (ERP) Composition assemblage d’applications développement à partir de progiciels et composants distants (EAI, IAI) Intégration de systèmes = systèmes complexes exigeants, comportant une grande part de développement spécifique.

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

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

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

37 COCOMO Pour plus d’informations
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 cost estimation with COCOMO II - B. Boehm et al, Prentice Hall, 2000 Estimating software costs - Capers Jones, McGraw Hill, 1998

38 Points de fonction

39 Les points de fonction (PF)
Part d’un point de vue de l’utilisateur (indépendant des choix de réalisation) Mesure la taille fonctionnelle = mesure du service rendu

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

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

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

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

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

45 Les points de fonction Étape 3 - Pondération
Groupe de données : sous ensemble logique (SD) et données élémentaires (DE) Complexité des GDI et GDE Ex de SD : en tête de facture, ligne de commande Pondération DE SD 1-19 20-50 >50 1 Faible Moyen 2-5 Elevé >5 Faible Moyen Élevé GDI 7 10 15 GDE 5

46 Les points de fonction Étape 3 - Pondération
ENT : SOR ou INT : DE GD 1-4 5-15 › 15 0-1 Faible Moyen 2 Elevé >2 DE GD 1-5 6-19 >19 0-1 Faible Moyen 2-3 Elevé >3 Pondération : Faible Moyen Elevé ENT 3 4 6 INT SOR 5 7

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

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

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

50 Les points de fonction - Exemple
Données GD DE Complx. PF Dossier client GDI 6 >50 E 15 Facture 4 20-50 M 10 Table Libellés 1 < 20 f 7 Base Clients GDE > 50 Fonctions F1 - Établir facture ENT > 2 > 15 F2 - Modifier facture 5-15 F3 - Visualiser impayés INT 2 1-4 3 F4 - Imprimer Facture SOR >19 5 Total 62

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

52 Les points de fonction Calcul de la taille d’une é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 Variante : La méthode MkII FPA
Part des transactions logiques élémentaires qui franchissent les limites de l’application (cas d’usage externes) 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)

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

55 Passage des points de fonction à l’estimation
Une solution : Se constituer sa base à partir de projets passés et la faire vivre 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 Application des points de fonction
Contractualisation Évaluation des évolutions Estimations ultérieures Mesure de la qualité

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

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

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

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

61 Exercice sur l’estimation par des experts

62 Plan de projet global 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 d’ouvrage La communication doit s’accompagner d’une explicitation des hypothèses d’élaboration

63 Plan global Hypothèses d’élaboration 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 Limites du plan de projet global
Approximation : Ignore les ressources réellement affectées au projet Ignore les dépendances avec d’autres 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 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 Approche de la planification ascendante
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 Phase Activité Tâche

68 Tâches Tâche : sous-ensemble d’une activité à laquelle on peut associer : Des ressources Des résultats Une durée d’exécution Exemples : Réunion Construction d’un mur Validation d’un document livré Codage d’une module logiciel

69 Décomposition en sous tâches
Décomposition d’un 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 Peut être héritée d’une méthodologie Indispensable au chef de projet Dangers : Omission Détail excessif

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

71 Sur quoi s’appuie la planification détaillée
Une découpe du projet en tâches découlant d’une méthode (choix méthodologique) Une détermination de la charge et des ressources nécessaires à l’exécution de ces tâches La détermination d’un 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

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

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° 4 : Tous les coûts ne sont pas égaux ; certains sont des investissements dont il faut apprécier le retour (roi)

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

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

76 Les facteurs qui influencent
Temps : certains projets sont (vraiment) bornés dans le temps Budget : il doit intégrer les effets d’investissement et les coûts sur la totalité du cycle de vie Fonctionnalités : sont-elles toutes nécessaires ? 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 La qualité est un investissement payant…
Coût de résolution Si un défaut d’un 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 d’intégration coûtera 100 unités, sa détection en production coûtera 1000 unités 1000 100 10 1 Échelle logarithmique Analyse Tests

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

79 Estimation 50-50 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 d’approbation des livrables Délais liés au test …

80 Estimation 50-50 par des 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 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 La pression du planning
Les programmeurs ont tendance à sous-estimer le temps nécessaire à une activité de 20 à 30% en moyenne Effet d’une 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 d’une annonce pessimiste : Inacceptable en environnement concurrentiel Effet négatif sur l’énergie de l’équipe Ne marche pas deux fois de suite

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

83 Que faire face à la pression du planning ?
Pour les projets réellement liés au temps, choisir une méthodologie de type RAD 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 qu’il estime infaisable

84 Prise en compte des risques
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 avec discrimination (ex : activités de validation) Effectuer une analyse des risques (voir la section Gestion des risques)

85 Passage de la charge au coût
La charge obtenue par sommation des charges des activités n’inclut 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 d’activité (ou globalement sur le projet) Ex : dans l’exercice précédent, gestion = 500€/j, autre = 350€/j

86 Passage de la charge au coût
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 Gestion : application d’un % de la charge totale Consommables : intégrer dans les coûts en personnel (notion de jour chargé)

87 Passage de la charge à la durée
La charge ne permet pas d’estimer la durée Elle permet un contrôle de vraisemblance ou une estimation grossière Pour les activités d’une 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

88 Plan de projet global 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 d’ouvrage Les dates type sont établies selon un processus descendant La communication doit s’accompagner d’une explicitation des hypothèses d’élaboration

89 3- Construction du chemin critique

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 Exemple : Analyse d’un cas d’usage – Analyse des variantes Tâche A Tâche B

91 Introduction d’un délai
Délai positif (retard) : Ex: On admet qu’il 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 +8j Première version Prise en compte des remarques Chapitres techniques Sommaire - 3j

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

93 Chemin critique Définition : C’est la suite de tâches dont un changement dans la durée conduit à un changement de la durée du projet Exemple : 6 4 2 4 6 6 Durée ?

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

95 Détermination du chemin critique
Représenter les tâches et leurs dépendances Déterminer pour chaque tâche la date de démarrage au plus tôt, en partant du début du projet 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) Chemin critique = ensemble des tâches dont la date au plus tôt = la date au plus tard

96 Détermination du chemin critique – 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 à l’origine + durée de l’activité + délai Pour le nœud, retenir la valeur la plus élevée de démarrage au plus tôt A Au plus tôt Au plus tard x

97 Démarrage au plus tôt 7 3 8 4 6 5 12

98 Détermination du chemin critique – 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 à l’extrémité - délai Pour le nœud, retenir la valeur la plus basse, lui retrancher la durée de l’activité A x

99 Démarrage au plus tard 12 10 3 9 4 5

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é Exemple : tests et correction Tests Corrections

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

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 Correspond à une planification « à l’envers », dictée par un événement figé dans le temps. Ex : Préparation d’une conférence : la date de la conférence impose la fin de la préparation Conférence Préparation

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

104

105 Quel niveau de détail ? Le niveau de détail du plan est le résultat d’un 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 l’avancement est mesurable

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

107 Exercice : chemin critique
Dans l’exercice 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 8 2 unités entre tâches 2 et 7 ?

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

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

110 Contraintes liées au temps
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) Dépendance par rapport à un autre projet

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

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

113

114

115 Lissage des ressources
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 Comment lisser : Itérer entre PERT et diagramme d’utilisation en incorporant les contraintes, et en positionnant au mieux les tâches non critiques

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 : Déterminer le plan de charge et le PERT qui minimisent les changements d’effectifs, et la durée. Discuter Tâches Durée Dépendance Charge type A Charge type B T1 3 6 T2 T3 2 T4 1.5

117 Comment réduire la durée ?
Augmenter le nombre de ressources Introduire un délai négatif dans les dépendances Investir 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 Évolution du plan Un plan est :
Un outil de communication Le résultat d’une négociation et d’un engagement correspondant à une vision à un moment donné de la vie du projet Les circonstances de la vie du projet peuvent amener à changer les conditions Faut-il changer le plan ? Trop de changement = perte de crédibilité Pas de changement = perte de réalisme et de confiance

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

121 Évolution du plan Quand modifier le plan :
A chaque suivi interne, si nécessaire, pour affecter les ressources aux tâches 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 Prise en compte du changement
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 Évolution du chemin critique
Travail = Effectif (capacité) x Durée Types de tâches Capacité fixe : une augmentation de la durée augmente la charge de travail 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 Évolution du chemin critique
Les modifications du plan détaillé peuvent conduire le chemin critique à se reporter sur d’autres 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 détaillé doit suivre la situation du projet de près

125 Ce qu’il faut retenir La planification est un aspect essentiel d‘un projet : elle conditionne les attentes La planification n’est pas une science exacte, mais c’est une activité rigoureuse La dimension communication est essentielle Trop de planning tue le planning (et le chef de projet !)

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