Intervenant: Kesner Pharel

Présentation au sujet: "Intervenant: Kesner Pharel"— Transcription de la présentation:

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

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

3 Les Origines de la Gestion de Projets
Le travail était scientifiquement étudié, d’abord, par Frederick Taylor ( ), 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 1. Définir et Organiser le Projet 1.1 Établir l’Organisation du Projet
Questions clés pour établir l’organisation de l’équipe Qui est le directeur du projet ? Quelles sont les responsabilités du directeur de projet? Dans quels domaines le directeur de projet possède l’autorité de décision? Est-ce qu’on a distribué un document écrit concernant les responsabilités et l’autorité du directeur du projet à tous les membres de l’équipe? Quels sont les membres de l’équipe? Quelle est l’expertise de chaque membre de l’équipe? Est-ce que chacun des membres de l’équipe responsable de tâches spécifiques a été identifié? Quelles sont les responsabilités de l’équipe? Est-ce que la liste de l’équipe a été complétée ? HBR - Octobre 1997

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

7 début officiel de la plupart des projets. Les
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 concentre sur le contenu du projet particulièrement et néglige la
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 Numéros de Téléphone et FAX
Nom et titre Rôle(s) Organisation Numéros de Téléphone et FAX Adresse Lieu/Adresse Postale 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 Questions Clés pour définir les paramètres En quoi consiste le projet?
Quand est-ce que le projet sera terminé (date)? Quelles ressources seront allouées au projet? Est-ce qu’il existe un énoncé de projet clair et concis de 25 mots ou moins? Quels sont les principaux produits ou services livrables ou résultats du projet? Est-ce qu’il existe une liste détaillée pour chaque produit ou service livrable ou résultat? Est-ce qu’il existe un document écrit du processus «Est / N’est pas » pour chaque bien livrable? Y-a-t-il une date d’échéance pour chaque bien livrable? HBR - Octobre 1997

14 Développement d’un produit Exécution des commandes Marketing
« Est » « N’est pas » Développement d’un produit Exécution des commandes Marketing Service à la Clientèle Plan stratégique Simulation informatisée HBR - Octobre 1997

15 Actions Clés pour Définir les Paramètres du Projet
Écrire un énoncé de l'objectif du projet. Liste des résultats à obtenir. Créer une liste « Est /N’est pas » pour chaque résultat à obtenir. HBR - Octobre 1997

16 1.3 PLANIFIER LE CADRE DU PROJET
Questions Clés pour Planifier le Cadre du Projet L’équipe a-t-elle spécifié quand les membres doivent se rencontrer, qui devra être présent et quels sont les sujets qui seront discutés ? Les règlements concernant la participation ont-ils été établis ? Les directives concernant la participation sont-elles établies? Tous les problèmes sont-ils reportés dans un journal de bord ? Le journal de bord est-il régulièrement mis a jour et revu avec les membres de l’équipe? Quelles sont les procédures à adopter en cas de litiges ou de conflits ? Y-a-t-il une procédure spéciale mise en place pour les problèmes non résolus ? Qui détient les dossiers du projet? Où conserve-t-on les dossiers 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 Les rencontres et leur gestion. La gestion des problèmes
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 Problèmes Date Origine Description et Impact
Responsable Date d’Echéance Statut ou Résolution 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 Software Driver Project
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éterminer les Objectifs du Projet Planifier le Cadre du Projet Développer WBS Calendrier & Ressources Réviser et Approuver le Plan du Projet Développer les Spécifications Externes Obtenir l’Approbation des Specs Externes Préparer l’analyse financière Préparer les spécifications internes Développer le Projet Pilote Identifier les sites de Beta test Développer des plans de qualité QA des pilotes avant l’envoi pour les tests Superviser les Beta tests Modifier les pilotes en fonctions des tests Développer les plans de support Développer l’analyse financière Mettre à jour la documentation Se préparer au lancement du produit Préparer la finalisation du projet Fermeture définitive Envoi des Beta tests HBR - Octobre 1997

24 Questions Clés pour la Structure de Répartition du Travail
Est-ce que toutes les tâches sont identifiées ? Est-ce que les tâches souvent oubliées comme la planification du projet, les cycles d’approbation, le testing, l’impression, etc. sont inclues ? Combien de temps cela prendra pour exécuter les tâches ? Heures ? Jours ? Semaines ? Est-ce que les tâches au niveau le plus bas ont été allouées ? Une tâche ou plusieurs par personne ? HBR - Octobre 1997

25 2.2 Dé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 - Start-Start avec un certain retard.
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 Compromis Questions clés pour Optimiser les
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 Créer quelques « Et Si » scénarii. Prenez des décisions de compromis.
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 Identifier et prioriser les risques du projet.
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 Status » Questions clés pour le « Collect
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 ? 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é ( , 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