Gestion de Projets

1. SÉMINAIRE Gestion de Projets Septembre 2012 Intervenant: Kesner Pharel

2. PLANIFICATION ET GESTION DE PROJETS DÉFINIR ET ORGANISER LE PROJET PLANIFIER LE PROJET SUIVRE ET GÉRER LE PROJET 1.1 ÉTABLIR l’ORGANISATION DU PROJET 3.1 COLLECT STATUS 2.1 DÉVELOPPER LA STRUCTURE DE RÉPARTITION DU TRAVAIL 3.2 PLANIFIER ET PRENDRE DES ACTIONS CORRECTRICES 2.2 DÉVELOPPER LE PLAN 1.2 DÉFINIR LES PARAMÈTRES DU PROJET 1.3 PLANIFIER LE CADRE DU PROJET 2.3 ANALYSER LES RESSOURCES 3.3 FERMER (CLOSE OUT) LE PROJET 1.4 RASSEMBLER LES DOCUMENTS DE DÉFINITION DU PROJET 2.4 OPTIMISER LES ARBITRAGES 2.5 ÉLABORER UN PLAN DE GESTION DES RISQUES Gestion de Projets HBR - Octobre 1997

3. Les Origines de la Gestion de Projets • Le travail était scientifiquement étudié, d’abord, par Frederick Taylor (1856-1915), qui était le premier à considérer l’établissement du processus. • Il a fallu, toutefois, attendre la décennie 1950 pour voir plusieurs techniques de gestion de projets regroupées dans un seul et cohérent système. • Le Département de la Défense des Etats-Unis a été le premier à réaliser cet énorme et complexe effort, avec le développement du missile Polaris. • Les techniques, qui ont inclus le chart de Henry Gantt, créé pour gérer la logistique de l’Armée américaine, étaient essentielles pour gérer les interrelations de comment le travail entre plusieurs experts serait réalisé, ainsi que la gestion du temps. • Au centre de cet effort était littéralement un projet “war room” (salle de guerre), qui a révélé d’importants charts de Programme d’Évaluation de Techniques de Revue, connu sous l’acronyme anglais PERT (Program Evaluation Review Techniques) HBR - Octobre 1997

4. Les industries de l’automobile et du cinéma ont emboîté le pas après l’Armée américaine, ainsi que les organisations de construction privées et publiques. • Toutes ces industries ont partagé le besoin de créer des produits et services uniques, et ils ont découvert que les techniques de gestion de projets ont aidé des équipes de différentes fonctions dans une organisation à définir, gérer et exécuter le travail nécessaire pour atteindre les objectifs. HBR - Octobre 1997

5. HBR - Octobre 1997

6. Qui supporte l’équipe ? A qui doit-elle faire des rapports? HBR - Octobre 1997

7. La détermination du directeur du projet est le • début officiel de la plupart des projets. Les • meilleurs directeurs de projet sont : • De bons motivateurs et des leaders. Ils doivent se • comporter comme des entraîneurs et des enseignants • au sein de l’équipe. • “Big picture-oriented”. • Communicateurs efficaces. • Bons organisateurs. • Orientés vers les objectifs. • Bonne connaissance des procédures de gestion de • projets et engagement à les respecter. HBR - Octobre 1997

8. Le directeur de projet n’est pas obligé d’être un spécialiste technique. • En fait, la spécialisation pourrait constituer un obstacle si l’expert se • concentre sur le contenu du projet particulièrement et néglige la • gestion des processus du projet. • Le directeur du projet doit s’assurer que le processus de gestion du projet • soit exécuté. • Il doit : • S’assurer que chaque membre de l’équipe comprenne et exécute les • tâches assignées. • S’assurer que chaque membre de l’équipe comprenne et accepte leurs • responsabilités. • Incite les membres à exécuter le plan adopté par l’équipe. • Faire des ajustements dans le plan, si nécessaire. • Garder le dossier du projet. • Arbitrer et résoudre les conflits. • Ệtre toujours au courant de l’état d’avancement du projet et maintenir les • membres au courant de la situation. • Reporter les problèmes dans un journal de bord. HBR - Octobre 1997

9. Le directeur de projet devrait être officiellement • nommé, par écrit, avec une description complète du • rôle particulier et des responsabilités spécifiques. • Par exemple, l'annonce par l’équipe dirigeante devrait • clairement établir si le directeur de projet a l’autorité de • prendre des décisions au cas où il y aurait des conflits • entre des membres de l’équipe ou s’il devrait obtenir • l’assistance d’autres instances ayant l’autorité • nécessaire. HBR - Octobre 1997

10. Liste de l’équipe de projet HBR - Octobre 1997

11. Actions clés pour Établir l’Organisation du • Projet • Nommer, par écrit, un directeur de projet. • Décrire, par écrit, le rôle du directeur de projet, son • niveau d’autorité et ses responsabilités. • Identifier les membres de l’équipe, avec leur rôle et • leurs responsabilités. • Créer et publier la liste des membres. HBR - Octobre 1997

12. 1.2 Définir les paramètres du Projet • L’un des plus importants éléments d’un plan de projet représente les objectifs du • projet et les produits et services à livrer. • La raison de la définition des paramètres du projet est dans le but de s’assurer que • le « bon » projet est en train d’être réalisé. • Le « bon » projet est défini en termes des résultats attendus, le temps et les • ressources. • Ces données sont placées dans l’Énoncé des objectifs du projet (EOP) (Project • Objective Statement), ce qui constitue la mission du projet, ainsi que les principaux • produits et services livrables. Ceci inclut le puissant processus « Ce qu’Est / Ce • que N’est pas ». • Ces données établissent les objectifs du projet. Mais ces objectifs ne peuvent être • finalisés jusqu’à ce que le projet complètement détaillé, incluant le plan de gestion • de risque, sont terminés, puisque le plan détaillé fournit de substantielles • informations sur la faisabilité d’atteinte des objectifs. • L’objectif fixe avec ces données s’est d’établir les buts du projet. Mais ces buts ne • devraient pas être finalises avant le plan complet détaillé qui devrait aussi inclure • la gestion des risques. Le plan devrait fournir les détails concernant la faisabilité • du projet et l’accomplissement des objectifs. HBR - Octobre 1997

13. HBR - Octobre 1997

14. HBR - Octobre 1997

15. HBR - Octobre 1997

16. 1.3 PLANIFIER LE CADRE DU PROJET HBR - Octobre 1997

17. Comment les membres de l’équipe communiquent entre eux (e-mail – téléphone – etc…) ? • Les accords entre les membres sont-ils enregistré à l’écrit et gardés dans les dossiers du projet? HBR - Octobre 1997

18. Il y a une variété de procédures opérationnelles possibles, mais quelques-unes sont particulièrement importantes pour la plupart des projets. Ce sont: • Les rencontres et leur gestion. • La gestion des problèmes • L’entretien et l’emmagasinage des dossiers du projet. • Les processus de communication. HBR - Octobre 1997

19. Formulaire de suivi HBR - Octobre 1997

20. Principales Actions pour Planifier le Cadre du Projet • Écrire les procédures de gestion des rencontres et s’entendre sur leur tenue. • Gérer les problèmes de façon agressive en utilisant un journal de bord formel. • Désigner le responsable et l’endroit de garder le dossier du projet • Définir et écrire la stratégie de communication. HBR - Octobre 1997

21. 1.4. Rassembler le Document de Définition du Projet • Une fois que le projet est organisé, les paramètres définis, et le cadre spécifié, l’information de ces étapes est combinée dans un Document de Définition du Projet (DDP). • Le Document de Définition du Projet (DDP) devient le document de référence de la Définition et l’Organisation de l’information et est utilisé au cours de l’exécution du projet comme un instrument de référence qui facilite la compréhension et aide à la prise de décision et au suivi. HBR - Octobre 1997

22. 2. Planifier le Projet • 2.1 Développer la Structure de la Répartitition du Travail (Work Breakdown Structure) • La plus importance source de retards dans l’exécution d’un projet représente des activités qui sont oubliées ou omises par inadvertence. • Pour être crédible, un plan du projet doit présenter chaque tâche nécessaire pour atteindre l’objectif, pas seulement une portion. • L’objectif de la Structure de la Répartition du Travail est d’identifier systématiquement tout le travail réclamé pour l’exécution du projet. HBR - Octobre 1997

23. Plan du Projet Close-out le projet Se préparer pour la diffusion Développer et faire des Tests Développer les spécifications et la conception Développer les Spécifications Externes Déterminer les Objectifs du Projet Préparer la finalisation du projet Développer les plans de support Développer le Projet Pilote Développer l’analyse financière Fermeture définitive Identifier les sites de Beta test Obtenir l’Approbation des Specs Externes Planifier le Cadre du Projet Développer des plans de qualité Développer WBS Calendrier & Ressources Mettre à jour la documentation Préparer l’analyse financière Réviser et Approuver le Plan du Projet Préparer les spécifications internes Se préparer au lancement du produit QA des pilotes avant l’envoi pour les tests Envoi des Beta tests Superviser les Beta tests Modifier les pilotes en fonctions des tests Software Driver Project HBR - Octobre 1997

24. HBR - Octobre 1997

25. 2.2Développer le Calendrier • La question centrale pour la plupart de projets est « Quand est-ce que le projet prendra fin? » • La finalité de l’étape de « Développement du Calendrier» est d’embarquer dans un processus systématique pour créer le calendrier du projet, puisque les calendriers développés utilisant un tel processus sont beaucoup plus prévisibles et crédibles. • Ils font la promotion d’une gestion efficace, en éclairant des décisions tactiques et spécifiques concernant les tâches, la séquence et le temps nécessaires pour atteindre les objectifs fixés. HBR - Octobre 1997

26. Questions clés pour Développer le • Calendrier • Est-ce que toutes les « relations de dépendance » • ont été identifiées? • Est-ce que les nouvelles tâches identifiées ont été • ajoutées au plan? • Un diagramme de réseau a-t-il été créé? • Des durées de temps on-t-elles été assignées aux • tâches de niveau inférieur ? • Des estimations pour les tâches les plus longues et • ambigues ont-elles été revues par l’équipe? • Un diagramme de Gantt a-t-il été créé? HBR - Octobre 1997

27. Pendant qu’il existe plusieurs types de relations logiques entre les tâches, on peut citer les plus communes: - Finish-Start - Start-Start - Start-Start avec un certain retard. HBR - Octobre 1997

28. HBR - Octobre 1997

29. Plusieurs Types de Performance • (Milestones) : • Le début et la fin d’un projet • L'accomplissement des principaux biens et • services livrables. • Revues formelles • Évènements importants comme les • présentations ou les salons. • Dépendances de biens et services livrables à • des organisations en dehors l’environnement • du projet. HBR - Octobre 1997

30. HBR - Octobre 1997

31. HBR - Octobre 1997

32. Actions clés pour Développer le Calendrier. • Utiliser les post-its du WBS (message) pour • créer un diagramme de dépendance pour les • tâches au niveau inférieur. • Faire une approximation rapide de la durée • des tâches (en heures). • Créer un diagramme de Gantt montrant le • calendrier. HBR - Octobre 1997

33. 2.3-Analyser les Ressources • - « Si seulement j’avais plus de ressources !», est le cri • traditionnel d’un directeur de projet frustré. • Assez souvent, malgré l’ajout de ressources • additionnelles, le problème reste entier. • Le fait d’ajouter des ressources améliore rarement la • performance du projet. • Les gestionnaires de projet doivent analyser • systématiquement leurs besoins en ressources. • Le but de l’étape Analyse des ressources est de fournir • aux managers de meilleures informations sur la situation • réelle des ressources, par conséquent facilitant la prise • de décisions de façon efficace concernant les trois • paramètres. HBR - Octobre 1997

34. Questions Clés pour Analyser les Ressources • Est-ce qu’une seule ressource supporte un poids • disproportionné de la charge de travail? • Y a-t-il des ressources sous-utilisées? • Y a-t-il des ressources affectées à des activités • parallèles? Y a-t-il d’autres ressources disponibles • pour le projet ? • Les personnes responsables de certaines tâches • ont-elles les compétences nécessaires pour les • exécuter? • Action clé pour Analyser les Ressources • Analyser le diagramme de Gantt pour les modèles de • ressources. HBR - Octobre 1997

35. 2.4 - Optimiser les Compromis • La principale raison qui justifie le fait de s’adonner à la • gestion de projets, est de générer de meilleures • données pour la prise de décisions. • Cependant, les données présentent typiquement des • choix qui réclament toujours une décision difficile. • Dans une bonne gestion de projets, il est presque • toujours nécessaire d’abandonner quelque chose que • l’on souhaiterait faire, de façon à obtenir un résultat • optimal. • Le but de l’étape d’Optimisation est de formaliser et de • légitimer le processus de prise de décisions. HBR - Octobre 1997

36. Questions clés pour Optimiser les • Compromis • Respectez-vous l’Énoncé des Objectifs du Projet? • Pouvez-vous réduire la portée ? • Pouvez-vous modifier la séquence ? • Pouvez-vous réassigner ou obtenir plus de • ressources ? • Y-a-t-il un autre moyen pour mieux travailler • et de façon plus intelligente pour atteindre • les mêmes résultats? HBR - Octobre 1997

37. Actions clés pour Optimiser les Compromis • Analyser le plan d'ensemble du projet. • Créer quelques « Et Si » scénarii. • Prenez des décisions de compromis. HBR - Octobre 1997

38. 2.5-Développer un Plan de Gestion de • Risques • C’est un truisme que tout type de projet implique • des risques. • Mais de façon générale, les responsables en • charge d’un projet tendent à minimiser les risques. • L’objectif de l’étape Développer un Plan de • Gestion de Risques est d’attirer l’attention sur les • risques du projet et la nécessité de les gérer. HBR - Octobre 1997

39. Questions Clés pour Développer un Plan de Gestion • de Risques. • Les principaux risques confrontés par le projet ont-ils été • identifiés? • Ont-ils été classés par ordre de priorités ? • Des actions ont-elle été prises pour réduire la probabilité • de l’émergence de risques ? • Y a-t-il un plan de contingence au cas où le risque devrait • arriver ? • Comment saurez-vous si le risque est arrivé ? • Qui est responsable de la gestion des risques au niveau • du projet ? HBR - Octobre 1997

40. Actions Clés pour Développer un • Plan de Gestion de Risques • Identifier et prioriser les risques du projet. • Créer un plan de gestion de risques qui inclut les • actions préventives et les plans de contingence. • Assigner quelqu’un pour gérer les risques du • projet. HBR - Octobre 1997

41. Suivi et Gestion du Projet • 3.1 « Colllect Status »  • 3.2 - Planifier et prendre des Actions Appropriées • Faire le suivi, de façon continue, une fois que le projet • a démarré, représente un plus grand défi que le • développement du plan initial du projet. • Le but des étapes du Suivi et de la Gestion consiste à • concentrer l'attention du directeur de projet et de • l'équipe sur les secteurs qui offrent les meilleures • informations sur l'avancement du projet. • Grâce à la disponibilité de bonnes informations, le • directeur de projet et l'équipe peuvent prendre de • meilleures décisions face aux changements • dynamiques qui se produisent dans tous les projets. HBR - Octobre 1997

42. Questions clés pour le « Collect • Status » • Combien de fois procédera-t-on au « Collect • Status » ? • Comment se fera-t-il ? • Quelle information sera rapportée ? • Quelles décisions prendra-t-on ? • Comment communiquera-t-on les décisions • et les actions ? HBR - Octobre 1997

43. La planification du «  Collect • status » inclut : • Les tâches ont-elles démarré à l’heure • prévue ? • Sinon, pourquoi et qu’est-ce qui peut être fait • pour les faire démarrer ? • Les tâches qui devaient se terminer à une • certaine période, ont-elles été exécutées ? • Sinon, pourquoi et qu’est-ce qui peut être fait • pour les faire démarrer. HBR - Octobre 1997

44. Quel est l’état de chaque problème non • encore résolu? • Qu’est-ce qui peut être fait pour les résoudre? • Y a-t-il d’autres problèmes non résolus? • Les risques incluent : • Quel est l’état du risque ? • Y a-t-il de nouveaux risques en vue ? HBR - Octobre 1997

45. Actions Clés pour le «  Collect status » et • la Prise de Mesures Préventives. • Déterminer à quelle fréquence le « collect status » • sera effectué. • Déterminer la façon dont il sera réalisé (e-mail, • réunion, etc.) • Analyser l’impact des états sur le projet. • Prendre des mesures d’adaptation. HBR - Octobre 1997

46. 3.3- Finalisation(Close-out) du Projet • On apprend beaucoup au cours du déroulement • d'un projet et si on prend bien en compte les • informations, ceci permettra la réussite des projets. • L'objectif de l’étape de Clôture du projet est de • tirer des leçons et des réflexions, afin d'améliorer • les performances futures. HBR - Octobre 1997

47. Questions Clés pour la finalisation • (Close-out) du Projet • Quels aspects de la gestion du projet avaient été considérés efficaces ? • Quels sont les aspects qui peuvent être améliorés ? • Comment peuvent-ils être améliorés? • Tous les documents sont-ils disponibles ? • Les principales leçons apprises sont-elles bien notées dans le dossier du projet ? • Comment seront-elles utilisées dans de futurs projets ? • Est-ce que le document du projet est conservé quelque part ? • Comment allez-vous reconnaître les personnes qui ont donné des résultats positifs et les féliciter publiquement? HBR - Octobre 1997

48. Les activités typiques dans le cadre de la • fin d’un projet incluent : • Évaluation des pratiques qui ont favorisé l'efficacité • du projet. • Évaluation des pratiques qui n’ont pas été aussi • efficaces que l’on espérait. • Développer de possibles améliorations de processus • pour de futurs projets. • Reconnaître publiquement la contribution des • personnes qui ont donné une bonne performance. • Compléter le document du projet. • Placer le dossier dans les archives. • Célébrer la fin du projet. HBR - Octobre 1997

49. Actions clés pour la finalisation du projet • Procéder a un compte-rendu formel. • Compléter les documents et archiver le • dossier. • Reconnaître et récompenser les membres • de l’équipe pour leurs contributions. • Célébrer la finalisation du projet. HBR - Octobre 1997

50. Merci HBR - Octobre 1997