METHODES DE CONDUITE DE PROJET

1. METHODES DE CONDUITE DE PROJET NSY115 Madame DELECLUSE Messieurs MOREL et RAYNAL CNAM – LILLE Lundi 08 Octobre 2007

2. En vue de produire un plan de travail daté, quantifié, nominatif. Planifier, c'est : • Identifier les tâches nécessaires à la réalisation du projet • Les ordonner logiquement dans le temps • Leurs affecter un responsable • Evaluer leur durée • Leurs allouer des ressources • Calculer les dates, • Calculer les marges, • Calculer les coûts,

3. Que faut-il planifier et à quel niveau de détail faut-il planifier ? • Les réponses varient selon les structures d'entreprises. De façon schématique, selon Mintzberg, la planification est : • maximale dans une "bureaucratie" • minimale dans une "adhocratie" 1 • Dans le domaine du projet informatique qui nous concerne, il nous faudra trouver un moyen terme, variable selon les époques du cycle de vie du projet. L'adhocratie est aujourd'hui associée au concept de Quasi-firme (le projet est une Quasi-firme) qui caractérise une entreprise : de structure légère autonome (avec des membres à compétences multiples) responsable (mise en pouvoir des membres) à réactivité élevée

4. Principes • Le Chef de Projet se bat pour que la réalisation respecte le planning • Il existe peu de tâches imprévisibles ..... • Il y a surtout des tâches imprévues. L'exhaustivité des études participera donc à la qualité des plannings • La planification se fait en principe par phases; elle est donc : • détaillée pour la phase immédiatement à venir • sommaire pour les phases ultérieures. • En théorie tous les sous-projets d'un projet se synchronisent en fin de phase.

5. Quelques "idées force" qui concernent la planification . • Il existe des plannings qui : • précèdent le projet, ce sont ceux qui dans la phase de définition du projet servent à : • Analyser, chiffrer • Prévoir, simuler, évaluer • Responsabiliser • Réagir • Lancer • Contrôler • le suivent pour : • Refléter le passé • Enregistrer • Comptabiliser Ce ne sont pas que des planning comptables; ils participent à la métrologie qui va enrichir nos bases de connaissances et permettre ainsi d'améliorer nos estimations futures.

6. Cycle de Développement de Solution Informatique (AFNOR) • Etudes Préalables • Exploration • Conception d'ensemble • Appréciation de la solution retenue • Conception détaillée • Conception du système de traitement de l'information • spécification fonctionnelle du système informatique • Etude organique générale • Réalisation • Etude organique détaillée • Programmation et tests • Validation technique • Mise en Oeuvre • Réception provisoire • Exploitation sous contrôle • Evaluation • Evaluation du système informatique • Evaluation du système de traitement de l'information

7. On ne peut définir le projet qu'avec un minimum de préalables dont une définition stable des composants de l'architecture technique de la solution (matériels et logiciels) et un choix de la stratégie de mise en oeuvre (versions successives ou non, installation pilote et déploiement, basculement unique, etc) • Analyser les besoins • Concevoir l'architecture fonctionnelle de solution • Concevoir l'architecture technique de solution • Valider l'architecture technique • Choisir les stratégies de mise en oeuvre • Bâtir l'Organigramme Technique (OT) • Estimer les charges et moyens • Planifier • Organiser • Formaliser la proposition

8. La démarche de planification • établir la base du projet • définir les conditions d'existence des tâches • estimer les tâches • bâtir le planning • gérer le planning

9. Besoin de représentation du planning adaptée aux acteurs • Le comité directeur (propriétaire du projet et membres) a besoin d'informations synthétiques sur les "dates clefs" du projet et sur les produits qui sont livrés à ces dates. • Le chef de projet a besoin d'une vision globale du projet qui va s'affiner au fur et à mesure du déroulement des étapes du cycle de gestion du projet. • Le responsable d'un sous-projet, d'un chantier ou d'un lot, ont besoin d'une vision détaillée des dépendances internes et externes du lot dont ils sont responsable. gestion du projet. • L'administrateur de projet à besoin d'une vision détaillée des dépendances internes et externes des différents lots pour gérer les différents contrats avec les "sous-traitants". • Les réalisateurs ont besoin de savoir quelles tâches ils , doivent réaliser, quand les commencer, quand les finir et de savoir qui réalise les tâches préalables et qui attend le résultat de leur travail.

10. Granulométrie du planning;Il faut découper les tâches jusqu'à ce qu'il n'y ait : • plus d'ambiguïté sur le responsable de la tâche (OBS) • pas de dépendances externes masquées avec d'autres tâches, autrement dit la tâche en cours n'a besoin du résultat d'aucune autre tâche en cours de réalisation • aucune autre tâche n'a besoin d'un résultat intermédiaire L'exemple ci-après montre l'impact de ces points de synchronisation masqués sur le planning si A n'est pas découpée ceci revient à dire que A ne peut être commencée qu'après la fin de B et que C ne peut être entreprise qu'après la fin de A. Le découpage plus fin de A, a permis d'augmenter le parallélisme et a mis en évidence des livraisons intermédiaires de produits qui masquent des points de synchronisation. Cette recherche est particulièrement importante en cas de stratégie d'intégration. Plus d'incertitude sur la durée, en général cette incertitude vient de dépendances intuitivement pressenties mais non formalisées. • Cette durée ne représente pas plus de 5% à 10% de la durée du projet. Ce qui revient à dire, la durée visée de nos projets étant de 12 à 18 mois, un découpage en tâches de durée idéalement de 10 jours travaillés et en aucun cas de plus d'un mois. Comme dans la conduite de projet nous préconisons une réunion de chantier chaque semaine une tâche de 10j ne serait en cours qu'au maximum pendant 2 points de contrôle. Nous évitons ainsi l'effet de tunnel et de devoir recourir aux questions du style pourcentage de réalisation de cette tâche. Une loi de Golub nous assure que l'on atteint rapidement 90% de réalisation et que l'on y reste définitivement.

11. vocabulaire • Une activité • regroupe plusieurs tâches donc elle n'est pas au plus bas niveau de la structure WBS. Ces tâches sont nommées "macro-tâches" ou "tâches mères". • Les tâches autonomes sont au plus bas niveau hiérarchique d'une branche du WBS. • Ces tâches sont appelées "Tâches atomiques" dans le cas où le niveau hiérarchique supérieur est appelé "macro-tâche". • Ces tâches sont appelées "Tâches filles" dans le cas où le niveau hiérarchique supérieur est appelé "tâche mère".

12. notion de tâche • Une tâche est une action requise pour contribuer à la fabrication d'un objet : • Elle peut être entièrement décrite • Elle est affectée à un responsable unique • Elle a une durée • Elle peut consommer des ressources • Elle dépend de certaines conditions de réalisation • Dans un projet il y a deux natures d'activités, donc de tâches 5 • les activités de production • les activités de supervision 5 Certains auteurs distinguent un 3 ème type les tâches de contrôle, contrôle qualité par exemple. En réalité ils considèrent que ces tâches sont des combinaisons de réalisation d'activité et de coordination des activités. On peut donc décomposer les tâches de contrôle dans nos deux types d'activités.

13. Qu'est-ce qu'un jalon? • C'est un événement clé d'un projet ou d'un sous-projet • visible de l'extérieur du projet • dont la réalisation est tangible (livraison d'un produit) • dont la date de réalisation est importante • Le "produit" livré peut être défini en termes de : • Contenu • Critères d'achèvement ou de réception • Date de fin de réalisation • Responsabilité

14. Pourquoi un Jalon? • Un jalon • C’est un événement facile à comprendre • Est représentatif de l'avancement (d'une partie) du projet • fournit une bonne base de contrôle • permet au management d'avoir une vue synthétique du projet • sa réalisation permet de mobiliser les énergies

15. Les principales phases d'une réalisation • Phase 1 : Etude préalable • Identification des besoins • Identification des moyens • Phase 2 : Spécifications • Architecture générale, spécifications, limites • Coûts, ressources, délais • Conception Fonctionnelle • Caractéristiques externes : fonctions • Revue de spécifications fonctionnelles, maquettes • Revue d'architecture du système • Phase 3 : Conception détaillée et Réalisation • spécifications détaillées informatiques • Revues de spécifications détaillées • Développement et tests • Analyse, programmation, tests, documentation • Système, réseaux, logiciels standards • Phase 4 : Installation et Exploitation • Installation et validation du système et de l'application • Mise en exploitation • Création, migration des données, formation • Phase 5 : Bilan du Projet

16. Les Produits à livrer par phase • 1) Phase 1: Etudes Préalables • Expression des besoins • Solution technique générale • Estimation des Hommes x mois de développement • Estimation des coûts Utilisateurs • Justification économique • Impacts sur existant • 2) Phase 2 : Spécifications • sp écifications fonctionnelles du système de gestion • Architecture générale du système • spécifications de sécurité et de reprise • spécifications de migration • Besoins en formation • Ebauche du contrat de service (performances, fiabilité) • Evaluation charges & ressources • Définition des moyens (matériels, logiciels, lignes,...) • Réception Maquettes • Plan de test • Plan de migration • Plan de déploiement • Plan de formation • Modes d'exploitation • Plan de revues et inspections • Projet de contrat de service • Commande des moyens • 3) Phase 3 : Réalisation et Tests • Modules & Programmes de l'application • Tests fonctionnels, tests d'intégration • Réception prototypes • Revues et inspections • Modules, Organisation de la formation • Manuels utilisateur • Contrat de service accepté • Document d'installation • Méthode de migration • 4) Phase 4 : Installation et Exploitation • Utilisateurs formés • Groupe Support Application formé • Liste de protection informatique • Documentation exploitation • Documentation utilisateurs • Contrat de service signé • Exécution d'exploitation sans défauts • Plan continuité testé/validé • Vérification de Service Régulier

17. Etablir la base du projet • Il s'agit de définir le référentiel du projet. Ce référentiel définira les bases de la gestion des changements et de la gestion de la configuration du projet. Le référentiel alimentera la "mémoire" du projet. • Analyser les besoins • S'assurer que l'on a bien compris les besoins du client • Valider l'Architecture Technique • S'assurer de l'adéquation de l'Architecture Technique Définie et des besoins client. • Choisir les stratégies de mise en oeuvre • Définir la ou les stratégies de mise en oeuvre de cette solution. • Bâtir l'Organigramme Technique • Découper la solution en sous-systèmes ou lots techniques.

18. Analyser les besoins • Il s'agit de s'assurer de la compréhension des besoins exprimés par le client ainsi que de l'environnement de la solution et du projet de mise en oeuvre de cette solution.

19. Stratégies de réalisation • Dans le domaine des projets informatiques les stratégies élémentaires sont limitées, elles sont combinables entre elles selon les "lots techniques" constitutifs du projet. Les principales stratégies de réalisation possibles sont décrites ci-après. • 1) Versions successives • Principe de mise en place par réalisation incrémentale dans l'ordre de priorité de mise à disposition des fonctions défini. Ceci suppose que la cible finale (dernière version) a été étudiée, sans aller trop loindans le détail, dès le début. De façon classique les priorités sont classées en • les fonctions indispensables (MUST HAVE); c'est à dire la reprise de l'existant plus les fonctionsnouvelles les plus "rentables" • les fonctions souhaitables (SHOULD HAVE) c'est à dire les fonctions qui permettent d'améliorer la rentabilité (traitement des cas d'exception les plus fréquents par exemple). • les fonctions luxueuses (NICE TO HAVE) c'est à dire les fonctions qui apportent du confort sansforcément améliorer la productivité. • L'intérêt d'une telle approche est de réaliser d'abord les fonctions les plus prioritaires et aussi de diminuer le temps de mise à disposition de ces fonctions, donc de commencer à rentabiliser la solution. • 2)découpage en phase • Stratégie classiquement utilisée en développement de logiciel. Le découpage diffère selon les méthodes : AFNOR, Ces découpages ont servi de base à l'établissement de statistiques de ventilation par phases, par activités ou par type d'acteur, des charges de travail de réalisation d'un projet. • 3)maquettage / prototypage • Une maquette sert à modéliser un dialogue mais ne produit rien, un prototype produit quelque chose d'utilisable. Dans le cas de prototypes enchaînés (spirale de Boehm, par exemple) li y a aussi de réalisation incrémentale. Mais à la différence de la stratégie de versions successives, on ne connaît pas la cible finale. C'est le cas dans la réalisation de solution innovatrice.

20. Cycles en V et W • En V Cycle dit de Goldberg. Cycle qui permet de s'assurer de la qualité du produit final et préconise 2équipes indépendantes pour la réalisation et la validation des produits. Par ailleurs pour diminuer le risques de défaut et leur coût de correction on mets en place, avant de passer à l'étape suivante de réalisation des revues d'inspection entre les deux équipes. • cycle en W Consiste à accoler deux cycles en V. Le premier cycle en V concerne la réalisation du prototype ou du pilote de la solution. Le deuxième cycle en V, après un temps d'utilisation du pilote, concerne la généralisation de la solution et le retrait de l'ancien système.

21. planification détaillée • Technique qui, à partir du dernier produit à livrer, remonte le réseau de dépendance entre tâches. Cette stratégie est utilisable chaque fois qu'il faut synchroniser un grand nombres de tâches et / ou d'intervenants; c'est en particulier le cas dans l'immobilier. • Cette technique de planification repose sur une méthode2 particulière d'étude des conditions d'existence des tâches lors de sessions structurées de planification. Cette méthode (sofilog) systématise la recherche du réseau de dépendance entre tâches, à partir des dernières tâches du projet. Elle est utilisée dans le cas de projets très complexes. Elle nécessite desanimateurs spécialistes de la méthode.

22. les 8 étapes d'élaboration de l'OT • 1)Identifier les sous-systèmes à livrer • Ne pas confondre, même s'il y a souvent correspondance, les sous- systèmes, les lots techniques et les plans 3. • 2) Faire la liste des produits à livrer • Faire abstraction des sous-systèmes que vous venez d'identifier et dresser la liste "en vrac" de tous lesproduits nécessaires. • 3) Regrouper par sous-système les produits identifiés • Trier et ventiler ces produits par nature ou domaine donc par sous-système. • 4) Enrichir l'arborescence • Par des produits intermédiaires, puis par les activités de fabrication, de contrôle et de supervision. • 5) Revoir l'organigramme technique • Vérifier que rien n'est oublier, qu'il n'y a pas de redondances inutiles, affiner le découpage, commencer àdéfinir des lots techniques, aussi autonomes ou indépendants que possible, dans les différents sous-systèmes. • 6) Terminer d'affecter les responsabilités • Affecter des responsabilités (OBS) pour chacun des éléments de l'OT. • 7) Présenter l'organigramme technique au client • Faire valider par le client, l'OT validé est un des éléments de base du référentiel du projet. • 8) Mettre à jour l'organigramme technique • Afin de refléter les discussions et négociations. A ce moment l'OT devient une des bases de référence du projet. 3)Un sous-système est un regroupement par nature ou domaine de produits ( application, système, réseau, etc) Un lot technique est un regroupement par responsabilité de réalisation et peut recouvrir une partie d'un sous-système ou plusieurssous-systèmes. Un plan est un regroupement d'activités par nature d'activités (donc éventuellement de compétences).

23. Définir les conditions d'existence des tâches • 1) Trouver le réseau de dépendance des tâches • 2) Définir les informations de contrôle et de pilotage des tâches • 3) Identifier les moyens nécessaires à la réalisation de la tâche. • La réalisation de ces activités se fait pendant les Sessions Spécialisés de Planification que nous allons décrire. En réalité lors de ces sessions on mène en parallèle les tâches nécessaires à la construction du planning : • enrichir l'organigramme technique • trouver les conditions d'existence des tâches • estimer leur charge de réalisation • bâtir le planning

24. Comment déterminer la taille des équipes? • Si nous connaissons la charge de réalisation nous en déduisons la durée minimale de réalisation par exemple • : • 144 h mois produits en 12 mois. • L'arithmétique nous permet de calculer, même si cela est sans signification réelle, un effectif moyen de emoy = ( 144 HMois : 12 mois) = 12 • Une approximation des lois de Rayleigh nous permet de trouver la taille maximum de l'équipe de réalisation (elle intervient au temps Td) . La taille maximum de l'équipe de développement, est : • Effectif maximum = 1,65 Effectif moyen • soit dans notre exemple • Effectif maximum = 1,65 x (144 HMois / 12 mois ) = 20 h • Il s'agit de l'équipe de "rameurs". • Qu'en est-il de la taille totale de l'équipe encadrement inclus; taille qui nous permet, dans les obligations clients d'écrire : "l'équipe comportera en période de pointe jusqu'à n personnes auxquelles vous devrez fournir un environnement d'accueil, ...Autrement dit de définir quel est le ratio personnel d'encadrement / personnel de réalisation considéré comme normal? Cela dépend de la nature des interventions. Le bon vieux ratio de 1 pour 10 qui existe depuis la cohorte des légions romaines puis la decurie, la centurie, ne s'applique pas à tous les domaines de réalisation. En ce qui concerne les projets de type informatique, si l'on veut que le personnel d'encadrement puisse : • prendre du recul afin d'anticiper les problèmes • jouer, pour ses collaborateurs, son rôle d'écran vis à vis des perturbations externes, afin de leur permettre de se consacrer exclusivement à leurs missions et tâches • le ratio appliqué varie entre 1/4 à 1/6 ; certaines SSII vont jusqu'à 1/8. Dans le cas de l'encadrement de débutants ou de projets novateurs le ratio de 1/4 est utilisé. Autrement dit la charge de supervision générée par un équipier varie de 15 à 25 %. L'existence d'un deuxième niveau de hiérarchie est fondé sur un ratio de 1/6, soit une charge de 15% par niveau hiérarchique supplémentaire. • Dans notre exemple si nous prenons un ratio moyen de 1/5 soit 20% nous avons besoin, au moment de la pointe d'effectif de l'équipe, de 4 responsables de groupes dont un assurant le leadership du projet.

25. Bâtir le Planning • Définir les calendriers du projet • Bâtir le planning • Bâtir le planning consiste à transformer le réseau de dépendance entre tâches en une représentation graphique. Dans un premier temps indépendamment des ressources. Pour ce faire nous disposons de 3 types de représentations : • 1) le réseau PERT • 2) le réseau des antécédents • 3) le diagramme de Gantt • Définir les ressources et leur disponibilité • Adapter le planning

26. le réseau PERT • Contrairement à ce que beaucoup croient le P de PERT ne signifie nullement planning; PERT = Program Evaluation and Review Technique. C'est une application, utilisée en recherche opérationnelle et en fabrication, des réseaux de Pétri. • Au départ les tâches ne comportaient aucune notion de durée, jusqu'au jour ou quelqu'un eu l'idée de représenter, sur du papier millimètré, les tâches proportionnellement à leur durée. C'est ce qu'à la fin des années 60 les puristes appelaient le "PERT amélioré" et que dorénavant on connaît sous le vocable de PERT. Les conventions et caractéristiques d'un réseau PERT sont les suivantes : • les tâches sont représentées par des flèches • les étapes représentées par des symboles, limitent le début et la fin de tâches • le réseau visualise les dépendances des tâches entre elles • Une étape ou converge plusieurs tâches ou dont diverge plusieurs tâches est un noeud du réseau de dépendance.

27. le réseau PERT • Cette représentation a pour avantages • de rendre la logique de dépendance évidente • de favoriser la recherche d'une solution en cas de dérapage • Elle présente quelques inconvénients(sinon elle serait la seule utilisée) et en particulier le fait que pour une représentation PERT "pure" les notions de durée et de dates ne sont pas représentées. Ce qui n'est plus vrai dans le PERT amélioré, mais dans ce cas la richesse d'informations portées sur le diagramme rend sa lecture ardue pour un non spécialiste. B2 C2 D5 E1 A1 G1 F7 2 B-2 C-2 3 5 3 06 1 0 PERT Amélioré 0 D-5 E-1 A-1 G-1 0 1 02 04 10 08 12 0 1 0 Marge Libre Nom Tâche - Durée Marge totale Fin + tard Fin + tôt Début + tard Début + tôt

28. Le réseau des antécédents B C 2 2 A D E G 5 1 1 1 F 7 • Les tâches sont représentées par des rectangles • Les dépendances sont représentées par les flèches reliant les tâches entre elles

29. Transformation PERT B2 C2 X1 D5 E1 F1 A1 Réseau des antécédents B C 2 2 A D E F 5 1 1 1

30. Définitions • Durée de la tâche : en appliquant les conditions normales de réalisation • Date de début au plus tôt : • date de fin au plus tôt de la tâche précédente la plus tardive dans le réseau de dépendance • Date de fin au plus tôt : • déduit de la date de début au plus tôt (ASAP) augmentée de la durée de la tâche. • Date de fin au plus tard : • c'est la date de début au plus tard de la tâche suivante la plus précoce dans les tâches aval de la tâche. • Date de début au plus tard : • elle se calcule comme la date de fin au plus tard de la tâche moins sa durée de réalisation • Marge totale : • fin au plus tard - fin au plus tôt = début au plus tard - début au plus tôt • Possibilité maximale qu'a une tâche de glisser sans mettre en cause la date de fin du projet. • Toutes les tâches d'une même branche ont la même marge • Marge libre : • début au plus tôt de la première tâche suivante - date de fin au plus tôt de la tâche • Possibilité qu'a une tâche de glisser sans impacter aucune autre tâche du projet • La marge libre est allouée à la dernière tâche d'une branche • Chemin critique : • Chemin le plus long en durée. Sa durée est la somme des durées des tâches par lesquelles il passe • Tâche critique : • toute tâche du chemin critique. Sa durée ne peut être modifiée sans impacter d'autant la durée totale du projet.

31. Marge libre • Possibilité qu'a une tâche de glisser sans impacter aucune autre tâche du projet • La marge libre est "allouée" à la dernière tâche d'une branche • La logique devient apparente • Le chemin critique est visible • Le Gantt devient vite difficile à lire 0 1 2 8 9 3 4 5 6 7 Branche A Marge libre B C D E F G Sur la figure ci-dessus les tâches sont calées au plus tôt.

32. Cas des tâches calées au plus tard (ALAP). 0 1 2 8 9 3 4 5 6 7 A B C D E F G Si B consomme la totalité de la marge de la branche B C, C n'a plus de marge.

33. Marge Totale • Marge totale : Possibilité maximale qu'a une tâche de glisser sans mettre en cause la date de fin du projet. • Toutes les tâches qui précèdent doivent finir au plus tôt • Toutes celles qui suivent démarrent au plus tard • Un seul gâteau à partager entre toutes les tâches.... • Toutes les tâches d'un chemin critique ont une marge totale identique minimum 0 1 2 8 9 3 4 5 6 7 A B C D E F G

34. Utilisation de la Marge Totale • Si B utilise la totalité de sa marge comme montré C et E deviennent critiques.... Il s'agit en fait de la Marge Totale du Projet. Elle est parfois appelée « Marge Partagée » 0 1 2 8 9 3 4 5 6 7 A B C D E F G