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

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

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

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

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

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

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

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

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

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

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

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

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)

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)

Méthodes descendantes d’estimation COCOMO Points de fonctions

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

COCOMO

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

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

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

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

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

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

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

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

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

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

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 50-50 = 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

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

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

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

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

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.

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)

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

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

COCOMO Pour plus d’informations http://sunset.usc.edu/research/COCOMO81 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

Points de fonction

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

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)

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

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

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

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

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

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

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

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) /100 + 0,65

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

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

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

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

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)

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

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

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

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

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)

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

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

Exercice sur l’estimation par des experts

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

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

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

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)

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

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

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

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

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

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

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

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)

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

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

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

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

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)

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 …

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)

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

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

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

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)

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

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é)

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

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

3- Construction du chemin critique

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

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

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

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 ?

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

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

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

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

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

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

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

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

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

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

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

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

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 ?

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

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

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

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

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

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

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

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

3 - Maintenance du plan détaillé

É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

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

É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

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)

É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

É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

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 !)

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