• Save
Project Management Introduction (4/5) for Gobelins students
Upcoming SlideShare
Loading in...5
×
 

Project Management Introduction (4/5) for Gobelins students

on

  • 16,137 views

Introduction to (digital) Project Management for multimedia students in Gobelins (Paris, France)

Introduction to (digital) Project Management for multimedia students in Gobelins (Paris, France)

This is the 4/5 support document.

Statistics

Views

Total Views
16,137
Views on SlideShare
6,111
Embed Views
10,026

Actions

Likes
22
Downloads
0
Comments
0

16 Embeds 10,026

http://www.superfiction.net 9031
http://superfiction.net 792
http://www.conseilsmarketing.com 153
http://www.slideshare.net 18
http://127.0.0.1 8
http://www.netvibes.com 6
http://en.www.superfiction.net.systranlinks.net 4
http://meltwaternews.com 3
http://www.linkedin.com 3
https://www.linkedin.com 2
http://translate.googleusercontent.com 1
http://www.superfiction.net.systranlinks.net 1
http://sledit.en.www.superfiction.net.systranlinks.net 1
http://sledit.www.superfiction.net.systranlinks.net 1
http://theoldreader.com 1
http://127.0.0.1:8795 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Project Management Introduction (4/5) for Gobelins students Project Management Introduction (4/5) for Gobelins students Presentation Transcript

  • INTRODUCTION A LA GESTION DE PROJET (4/5)
  • Séances planifiées : - Mercredi 16/12 - Vendredi 22/01 - Vendredi 05/02 - Lundi 15/03 - Mercredi 31/03
  • SYNTHESE du cours précédent
    • Le plan de charge
    SYNTHESE : dimensionner le projet
    • Le plan de charge
      • Charge de travail du CP selon les phases du projet
        • Cadrage  lister les tâches
        • Conception  lister les tâches + 15/20% de l’élongation
        • Production  de 20/30% jusqu’à 80/100% (rare) de la charge de production
        • Recette  70/80% de l’élongation
    SYNTHESE : dimensionner le projet
    • Le plan de charge
      • Charge de travail du CP selon les types de projet
        • Projet peu risqué  15/20% de la charge de prod.
        • Projet classique  25/30% de la charge de prod.
        • Projet complexe  entre 30 et 100% de la charge de prod.
      • On sous-estime souvent le temps que l’on estime nécessaire pour réaliser des tâches.
    SYNTHESE : dimensionner le projet
    • Le plan de charge
      • Charge vs. Durée
    SYNTHESE : dimensionner le projet
      • Par CHARGE (ou TRAVAIL), on entend la somme de travail nécessaire (tous profils confondus) pour traiter une tâche. La charge s’exprime généralement en heures.
      • Par DURÉE (ou ÉLONGATION), on entend le temps nécessaire à l’accomplissement de cette tâche. La durée s’exprime généralement en jours.
    • Formaliser un devis
    SYNTHESE : dimensionner le projet
    • Formaliser un devis
      • En avant-vente  estimation budgétaire (car périmètre souvent mouvant)
        • faire le budget avec des % pour les différentes phases
        • rapide, enveloppe budgétaire respectée… mais nécessite de l’expérience
      • En démarrage projet  budget descriptif (car périmètre plus précis)
        • lister les tâches et le temps nécessaire
        • plus long, risque de dépassement de l’enveloppe globale mais plus précis
    SYNTHESE : dimensionner le projet
  • Formaliser un devis SYNTHESE : dimensionner le projet
    • Pour dimensionner son projet;
    • Pour contractualiser / officialiser la relation commerciale;
    • Pour détailler la prestation et ses livrables;
    • Pour préciser ce qui est hors scope;
    • Pour lister les prestations optionnelles
    • Pour définir un calendrier / des échéances
    • Pour détailler les modalités de paiement
  • Formaliser un devis SYNTHESE : dimensionner le projet Qui ? Le Chef de projet, le Directeur de Clientèle, le Commercial… Quand ? En Appel d’Offres mais plus généralement en début de projet, quand le scope est relativement clair. Qui valide? Le Dir. de projet et/ou la Direction
  • Suivre l’avancement des heures  le « Follow Up » SYNTHESE : piloter le projet
  • Suivre l’avancement des heures  le « Follow Up » SYNTHESE : piloter le projet Basé sur le plan de charge , le Follow Up reprend toutes les tâches détaillées et les charges associées.
  • Suivre l’avancement des heures  le « Follow Up » SYNTHESE : piloter le projet Il permet de réévaluer le RAF (« Reste A Faire ») du projet. Ainsi, on pourra comparer : L’avancement réel vs. L’avancement théorique Sans document de suivi des heures, difficile de dire avec exactitude où en est le projet, sur quelle tâche / partie l’équipe est en avance, en retard, combien d’heures de travail il reste à produire...
  • Suivre l’avancement des heures  le « Follow Up » SYNTHESE : piloter le projet
    • Pour le mettre à jour, il faut renseigner :
    • Une seule fois, dès sa mise en place :
      • le temps prévisionnel (ou temps initial / planifié) : c’est le temps estimé (et vendu au client) pour réaliser la/les différentes tâches. Ce chiffre ne bouge JAMAIS.
  • Suivre l’avancement des heures  le « Follow Up » SYNTHESE : piloter le projet
    • Pour le mettre à jour, il faut renseigner :
    • Une seule fois, dès sa mise en place :
      • le temps prévisionnel (ou temps initial / planifié) : c’est le temps estimé (et vendu au client) pour réaliser la/les différentes tâches. Ce chiffre ne bouge JAMAIS.
    • Et à chaque mise à jour (1 x/ semaine)
      • le réalisé (ou temps passé) : le temps passé à travailler la tâche en question. Chaque semaine il est censé évoluer.
      • la réévaluation (ou le Reste A Faire – To Be Done) : c’est une requalification du temps prévisionnel  Cela correspond au temps nécessaire pour terminer la/les tâche(s). Chaque semaine il est censé diminuer
  • Suivre l’avancement des heures  le « Follow Up » SYNTHESE : piloter le projet
    • Avancement Théorique
      • Se calcule automatiquement grâce à la Charge Initiale et au Réalisé
      • C’est l’avancement idéal que l’on doit suivre pour mener à bien le projet
    • Avancement Réel
      • Se calcule grâce à la RÉESTIMATION que fait le Chef de Projet entre le Réalisé et le Reste A Faire
      • Il doit être le reflet de la réalité , même si c’est en la défaveur du projet
  • Suivre l’avancement des heures  le « Follow Up » SYNTHESE : piloter le projet Reste A Faire Réel vs. Reste A Faire Théorique Ex : sur une tâche Créa initialement planifiée à 80h (2 semaines), le DA a déjà passé 40h la 1ère semaine. Il a donc passé la moitié du temps qui était prévu et son RAF théorique est donc de 40h pour la 2nde semaine (80h - 40h) Pour autant, est-ce qu’il est bien à la moitié de son travail ?
  • Suivre l’avancement des points en suspens  « Issue List » SYNTHESE : piloter le projet
  • Suivre l’avancement des points en suspens  « Issue List » SYNTHESE : piloter le projet Quand ? beaucoup de questions sont posées et/ou encore ouvertes et des réponses structurantes doivent être apportées. Quoi ? Questions listées et abordées par le CP à chaque réunion avec le client. Comment ? Sujet, Question, Affectation, Criticité, Statut, Date de clôture
  • Suivre l’avancement des tâches  « TIDE » (Task - Issue - Decision - Event ») SYNTHESE : piloter le projet
  • SYNTHESE : piloter le projet Quand ? Tout au long du projet Quoi ? - Il centralise toutes les infos importantes du projet - Il sert de TODO LIST et d’HISTORIQUE projet Comment ? Sujet, Tâches, Problèmes, Décision, Event, Affectation / Responsable, Statut, Dates de clôture (planifiée / réelle) Suivre l’avancement des tâches  « TIDE » (Task - Issue - Decision - Event »)
  • Suivre l’avancement de la production  « Production Tracking » SYNTHESE : piloter le projet
  • SYNTHESE : piloter le projet Suivre l’avancement de la production 1  « Production Tracking » Quand ? Juste avant le démarrage de la phase de prod. Quoi ? offre un statut clair sur l’état général de la production à date. Comment ? Liste des pages, fonctionnalités, contenus… à produire + un statut associé (en cours, non démarré, validé client...) 1 « Production » au sens large : production graphique des templates, production des contenus éditoriaux, intégration HTML, développements IT...
  • SYNTHESE : piloter le projet Suivre l’avancement de la production 1  « Production Tracking »
    • Utile pour l’équipe projet:
    • visibilité / statut clair,
    • Reste A Produire,
    • nomenclature définie,
    • versions validées…
    • Utile pour le client :
    • visibilité / statut clair
    • éléments qu’il doit valider,
  • Suivre l’avancement des livrables  « Deliverables Tracking » SYNTHESE : piloter le projet
  • SYNTHESE : piloter le projet Suivre l’avancement des livrables  « Deliverables Tracking » Quand ? Au démarrage du projet Quoi ? offre un statut clair sur le statut des différents livrables Comment ? Liste des livrables, Statut associé (en cours, non démarré, validé client...), Personne qui valide, détail des réserves, Date de validation
  • SYNTHESE : piloter le projet Livrable Applicable = A valider par le client (Ex : le concept graphique, les wireframes etc…) Livrable de Référence = Nécessaire de le produire pour le projet MAIS n’est pas à valider par le client (Ex : la documentation d’installation des environnements, les Cahiers de Recette etc…) Suivre l’avancement des livrables  « Deliverables Tracking »
  • SYNTHESE : piloter le projet PV d’approbation  Pour valider les livrables un par un PV de recette définitive  Pour valider le projet dans son ensemble et acter la mise en production Suivre l’avancement des livrables  Le « PV » (Procès Verbal)
  • des questions ?
  • ET AUJOURD’HUI…
    • PILOTER LE PROJET
    • Gérer les risques
    • - Gérer les changements
    • Construire son dashboard
    • PLANIFIER LE PROJET
    • Le planning projet
  • PILOTER le projet
  • GÉRER les risques
  • Gérer les risques
    • Qu’est-ce qu’un risque ?
      • C’est la prise en compte d'une exposition à un danger, un préjudice ou autre événement dommageable, inhérent à une situation ou une activité.
      • Le risque est défini par la probabilité de survenue de cet événement et par l'ampleur de ses conséquences.
      • Ex : le changement de Direction Marketing qui survient juste après l’Appel d’Offres est un risque important car le projet peut être remis en cause par la nouvelle Direction qui voudra imposer sa vision du projet (et peut-être ses prestataires)
      • Un risque qui survient n’est plus un risque : c’est un problème.
  • Gérer les risques
    • La notion d’incertitude
      • … Le risque est défini par «  la probabilité de survenue…  »
      • Rien n’est sûr
      • Lié à l’avenir et au facteur humains
  • Gérer les risques
    • Un projet sans risques n’existe pas.
      • Tout projet en comporte un ou plusieurs, aussi mineurs soient-ils.
      • Ils faut les identifier en début de projet (lors de la réunion de « kick off ») et tenter de les anticiper tout au long du projet.
      • Des risques non identifiés au démarrage du projet peuvent apparaître en cours de projet.
  • Gérer les risques
    • Un projet sans risques n’existe pas.
      • Il est donc très important pour le Chef de Projet de :
        • les identifier,
        • qualifier leur impact s’ils se transforment en problème,
        • proposer des plans d'actions pour les gérer au mieux.
  • Gérer les risques
    • Que permet la gestion des risques ?
        • éviter d’éventuels problèmes : si les risques sont énoncés et partagés avec le client, des plans d’action peuvent être mis en œuvre ;
        • avoir une vision à plus long terme du projet: en se focalisant pas uniquement sur aujourd’hui mais sur des situations probables de demain
  • Gérer les risques
    • Quatre manières de gérer les risques
        • 1. La prévention du risque : on prend des mesures pour limiter l’apparition de l’événement.
        • 2. l’acceptation du risque : un risque n’a pas toujours des conséquences désastreuses. Si c’est le cas, il peut être accepté , tout comme les conséquences qui s’en suivent.
        • 3. La réduction du risque : rechercher les facteurs de risque
        • 4. Le transfert du risque : lorsque l'entreprise sous-traite l'activité à risque (sous-traitance, co-traitance…)
  • Gérer les risques
    • Le document :
      •  le « Risk Management »
  • Gérer les risques
    • Les éléments à renseigner (1/2):
        • description : permet de détailler le risque en question (ex : risque de non validation de la maquette graphique)
        • conséquences: que se passe-t-il si le risque se transforme en problème ? (ex : retard de la phase d'intégration)
        • probabilité : quel est le pourcentage pour que ce risque se transforme en problème ? Remarque : un risque dont la probabilité est de 100% n’est plus un risque, c’est devenu un problème ;-)
        • impact : sur une échelle de 1 à 10, quel serait la gravité de ce risque ? (1 = faible, 10 = fort)
  • Gérer les risques
    • Les éléments à renseigner (2/2):
        • exposition au risque : c’est la multiplication de la probabilité par l’impact divisé par 100 (exemple avec une probabilité de 80% et un impact de 5 sur 10 : (80x5)/100)
        • statut : si le risque est toujours réel, il est ouvert, et s’il n’est plus d’actualité, il est clos.
        • plan d’action : c’est ici que l’on liste la ou les solutions à mettre en œuvre pour faire baisser le risque (ex: organiser des réunions de validation Créa toutes les semaines avec la Dir. Marketing)
        • commentaires
  • Gérer les risques
    • Le document :
      •  le « Risk Management »
    • Complétez le document
    • d’après votre projet
  • GÉRER les changements
  • Gérer les changements
    • L’acceptation du changement
        • Tout projet évolue dans le temps, et des décisions qui ont été prises en amont peuvent être remises en cause :
        • par le client;
        • pour des enjeux techniques, fonctionnels…;
        • parce que le périmètre projet évolue;
        • suite à des changements de contexte;
        • etc…
  • Gérer les changements
    • L’acceptation du changement
        • A l’issue de la Phase de Conception , le périmètre du projet a été fixé (et non figé) et des livrables ont été rédigés et validés par le client.
        • C’est sur ce périmètre validé que se sont engagés le Chef de Projet et l’équipe projet pour réaliser le planning.
  • Gérer les changements
    • L’acceptation du changement
        • Si le client demande des changements
        • fonctionnels (ex : rajout d’une nouvelle fonctionnalité…)
        • techniques (ex : mise en place d’un référentiel…)
        • graphiques (changements sur la Home Page…)
        • qui sont en dehors du scope prévu…
        • alors que ces éléments ont été démarrés / développés / validés, cette (nouvelle) demande doit faire l’objet d’une « demande de changement »
        •  On parle alors de « Change Request » (CHR)
  • Gérer les changements
    • Le document :
      • le formulaire de
      • « Change Request  » (CHR)
  • Gérer les changements L’acceptation du changement La « Change Request » (CHR) est qualifiée par l’équipe projet au niveau des impacts COUT et PLANNING liés à la prise en compte de cette nouvelle demande. Une fois la demande précisée, le Chef de Projet évalue la charge de travail nécessaire pour chacun des profils pour réaliser cette tâche. En ressortent un coût additionnel et un délai (supplémentaire ou non) pour réaliser cette tâche. Il appartient ensuite au client de l’accepter, de la refuser, ou de la prévoir pour une prochaine version du site.
  • Gérer les changements
    • Le process
    • le client fait part de sa demande de changement au Chef de Projet,
    •  si ce dernier a suffisamment d’information, il qualifie la demande :
      • - description détaillée de la demande,
      • - quelle est la charge de travail par profil à fournir pour traiter la demande ?
      • - quel en est le coût ?
      • quel est l’impact de la demande concernant l’élongation du planning ? etc...
      • Toutes ces infos permettront au client de prioriser les demandes à mettre en œuvre en fonction des impacts de chacune,
  • Gérer les changements
    • Le process
    • le Chef de Projet doit envoyer la CHR au client et attend un retour de ce dernier quant à l'acceptation ou non des impacts liés à cette demande :
      • - si les impacts sont acceptés par le client, le Chef de Projet devra en alerter son équipe. Cette dernière devra intégrer les nouveaux développements dans le planning et mettre à jour les spécifications,
      • - si les impacts ne sont pas acceptés par le client, la demande peut être annulée, différée, rediscutée, revue à la baisse… mais les modifications ne sont donc pas prises en compte pour le moment.
  • Gérer les changements
    • Pourquoi faire des Change Request ?
      • parce que la demande de changement a des impacts en terme de charge de travail et de planning (de fait, elle a un coût que le client devra assumer)
      • parce que c’est du travail supplémentaire qui modifie le périmètre (et peut-être le planning) initial,
      • parce que la demande peut remettre en cause tout ou partie du travail effectué à ce jour et que le client doit en être informé,
      • parce qu’elle permet de décrire le nouveau fonctionnement souhaité par le client (ce qui permettra de mettre à jour les spécifications)
  • Gérer les changements
    • Pourquoi faire des Change Request ?
      • cela permet de valider les décalages du planning et les coûts liés à ces demandes si le client valide la Change Request
      • pour conserver une trace écrite de toutes les demandes supplémentaires qu’a faites le client.
      • Plus d’infos : http://www.superfiction.net/blog/index.php?2008/06/06/259-les-outils-indispensables-de-la-gestion-de-projet-3-5-le-formulaire-de-change-request
  • Gérer les changements
    • Les erreurs / oublis les plus fréquents :
      • identifier quand il est nécessaire de refaire un peu de conception (même en plein milieu d’une phase de production…)
      • penser à la mise à jour de tous les documents précédemment produits :
        • spécifications fonctionnelles à rétro-documenter
        • cahiers de tests à compléter
        • planning à remettre à jour
      • penser que toutes les demandes ont un impact planning = FAUX. Certaines demandes ne sont pas sur le chemin critique du projet, d’autres peuvent être parallélisées etc…
  • Gérer les changements
    • Le document :
      • le formulaire de
      • « Change Request  » (CHR)
    • Complétez le document
    • en inventant une nouvelle demande / fonctionnalité
  • Gérer les changements
    • Pour les centraliser :
      • Le « Change Request Follow up  »
  • Gérer les changements
      • On reporte :
        • Le n° de la CHR
        • Un résumé de la demande
        • La charge additionnelle (en heures)
        • L’impact planning (en jours)
        • Le coût additionnel
        • Les dates (de la demande, de validation, de MAJ des specs)
        • Le statut (validée, refusée, différée)
    • Pour les centraliser :
      • Le « Change Request Follow up  »
  • CONSTRUIRE son dashboard
  • Construire son dashboard
    • Une grande partie des documents présentés peuvent être agrégés au sein d’un même document intitulé « dashboard ».
    • Ainsi, ce dashboard regrouperait :
      • le follow up (suivi des heures)
      • le TIDE (Task Issue Decision Event)
      • le Deliverables follow up
      • le Risk Management
      • le Change Request follow up
      • le Prod. Tracking (Creative, Intregration, Flash, IT…)
  • Construire son dashboard
    • Ainsi, vous avez 3 documents à utiliser pour piloter votre projet :
    • 1/ le Flash Report
    • 2/ le Dashboard
    • (qui regroupe 7 documents)
    • 3/ Le Planning
  • PLANIFIER le projet
  • LE PLANNING
  • Le planning
    • Il est l’outil indispensable qui permettra de mener à bien le projet
        • Tout projet est lié +/- fortement à un calendrier :
        • démarrage prévu à telle date;
        • fin prévue à telle date;
        • réception des éléments à telle date;
        • etc…
        • Sans planning, il n’y a pas de pilotage projet possible, car tout projet s’inscrit dans le temps.
  • Le planning
    • Il est le seul document projet qui contient :
        • - les tâches identifiées;
        • - l’ordonnancement de ces tâches;
        • - les ressources nécessaires;
        • - la charge de travail associée;
        • - les livrables à produire;
        • - les jalons à placer;
        • - les dates de livraison et de validation à respecter;
        •  Bref, une vision commune du projet à partager entre l’agence, les autres prestataires et le client.
  • Le planning
    • Pourquoi faire un planning ?
        • Pour définir des priorités et un ordonnancement à suivre;
        • Pour identifier les dates clés du projet;
        • Pour donner de la visibilité au client ;
        • Pour coordonner les différentes ressources;
        • Pour organiser au mieux le travail de toutes les ressources ; - Pour que tout le monde ait les mêmes objectifs et pour tendre collectivement vers ces objectifs ;
  • Le planning
      • Mise en place :
        • au démarrage du projet
      • Fréquence de mise à jour :
        • Hebdomadaire
      • Destinataires :
        • l’équipe projet
        • le client
      • Responsable :
        • Le chef de projet
  • Le planning
    • Quelques questions à se poser avant…
    • Comment va se dérouler mon projet ?
    • Quelle est l’organisation la plus optimale pour mon projet ?
    • Quelles tâches / ressources puis-je paralléliser ?
    • - Quelles actions faire apparaître sur le planning ? (tâches, livrables, événements…)
    • - Quelle organisation adopter ? (phases, lotissements, ressources)
    • - Quel degré de précision / de granularité adopter ?
  • Le planning
    • Différents types de plannings :
        • Macro planning
        • Souvent utilisé en avant-vente ou en tout début de projet quand le périmètre n’est pas défini.
        • Ne fournit pas de dates (volontairement) et reste très approximatif (au mois, à la semaine…)
        • Exemple :
    M1 M2 M3 M4 M5 M6 Concept° X X Product° X X X X Recette X
  • Le planning
    • Différents types de plannings :
        • Planning détaillé
        • Mis en place quand le périmètre est fixé, il permet d’être précis au jour près et ce, sur plusieurs semaines / mois.
        • Exemple :
  • Le planning
    • Différents types de plannings :
        • Rétro-planning
        • C’est un planning inversé qui a été conçu en partant de la date de fin du projet puis en remontant dans le temps afin de positionner les jalons et de fixer la date de démarrage.
  • Le planning contraintes deadlines rétro-planning objectif client livrables affectation occupation ressources chemin critique validation macro / détaillé jalons lotissements tâches récapitulative échéances charge durée / élongation contingence découpage outils marge début / fin autres prestataires prédécesseur parallélisation
  • Le planning
    • Quelques outils
        • MS Excel
        • MS Project
        • Gantt Project
        • Basecamp
        • - Open Workbench
  • Le planning
    • Pourquoi ne pas utiliser Excel ?
      • Parce qu’Excel ne peut pas affecter de ressources sur des tâches
      • Parce qu’Excel ne comprend pas les notions de durée, d’élongation, de chemin critique…
      • Parce qu’Excel n’est pas adapté pour faire les mises à jour du planning
      • Parce qu’Excel n’est pas un outil de planification
      • contrairement à MS-PROJECT
  • Le planning
    • Sur MS-Project, avant de démarrer…
      • Définir la date de début (ou la date de fin pour un rétro-planning)
      • Définir le calendrier et les jours fériés
      • Définir les heures de travail
      • Afficher les informations «  Duration  » (durée) et «  Work  » (travail)
      • Renseigner le tableau des ressources
  • Le planning
    • Sur MS-Project, quand vous démarrez… (1/2)
      • D’abord, il faut lister toutes les tâches au kilomètre , sans indentation.
      • Une fois terminé, refaites une passe pour mettre les indentations et pour que la structure de votre planning apparaisse clairement.
      • Affectez les ressources (via la « resource sheet »)
      • Ensuite, ajoutez le nombre d’heures que vous avez vendues pour chacune des tâches. Et là, il faut faire la distinction entre les colonnes "Work" et "Duration" :
      • Plus d’infos : http :// www.superfiction.net/blog/index.php?2009/01/07/352-gestion-de-projet-quelques-conseils-pour-realiser-un-planning-avec-ms-project
  • Le planning
    • Sur MS-Project, quand vous démarrez… (2/2)
      • Utilisez le moins possible les dates fixes, utilisez justement la colonne "Duration" pour que les dates de début et/ou de fin se calent sur les dates que vous souhaitez.
      • Définissez les liens (interdépendances) entre les tâches. Pour créer ces interdépendances, utilisez les filtres automatiques pour n’afficher les ressources que les unes après les autres. Ainsi, vous pouvez lier les tâches de chaque ressource plus simplement entre elles.
      • Enfin, parce qu’on gère des ressources et pas des tâches, il faut veiller à ce que leur charge de travail quotidienne soit réaliste (qu’elle soit au mieux à 100%, mais il faut éviter les profils dont la charge dépasse les 100%...)
  • Le planning
    • Comment optimiser son planning ?
      • Mettre plus de ressources en parallèle : pour 160h de travail, 2 ressources en parallèle mettront 2 semaines pour terminer le travail, 4 ressources mettront 1 semaine.
      • Traiter plusieurs tâches en parallèles : peu risqué quand il n’y a pas d’interdépendances entre-elles.
      • Dédier des ressources sur le projet : une ressource disponible à 100% pour le projet sera plus efficace et plus rapide qu’une ressource disponible à 25%
      • Réduire le temps prévu pour les Allers / Retours (si le client est d’accord) ou bien réduire les buffers (si ce n’est pas trop risqué)
      • Prévoir un lotissement : sortir une v1 au scope + réduite qu’initialement , alors que la v2 sera la version complète…
  • Le planning
    • Un bon planning contient :
      • la liste des livrables (en plus des tâches)
      • les dates de livraison ET de validation
      • les dates / tâches qui concernent le client (envoi des éléments, validation des livrables…)
      • les dates / tâches qui concernant les autres prestataires (livraison des contenus à telle date…)
      • des jalons clairement identifiables
      • le même nombre d’heures que votre plan de charge ;-)
  • Le planning
    • Les pièges à éviter (1/2)
      • Ne pas renseigner l’ensemble des informations pour chacune des tâches et vérifier au fur et à mesure. Il vaut mieux lister toutes les tâches « au kilomètre » puis renseigner le travail, la durée, puis passer aux interdépendances et aux ressources.
      • Ne pas prendre de buffer : tout projet doit avoir des buffers. Démarrer un projet sans buffer est très risqué et nécessite un pilotage précis, dur, sans concession (et sans accident ou événement inpromptu…) Mettez donc entre les phases importantes des jours de buffer, pour absorber les retards de validation, les imprévus, les nouvelles demandes etc...
      • Ne pas prendre en compte les jours fériés et les jours de congés des ressources.
      • Confondre « Durée » et « Travail »
  • Le planning
    • Les pièges à éviter (2/2)
      • (Spécifique à MS-PROJECT ) : Utiliser des dates fixes : préférez varier avec la "duration" pour arriver aux dates que vous souhaitez, plutôt que d’imposer une date qui sera inscrite dans le marbre. Il est impensable de modifier à la main le changement de 50 dates parce qu’1 seule a été modifiée.
      • Affecter plusieurs ressources qui ont des charges différentes sur la même tâche. Exemple : tâche "création Fiche Produit" avec 4h de DA et 16h de Webdesigner. Vous aurez des problèmes pour lier cette tâche avec d’autres pour le DA par exemple, car dans la réalité il aura terminé au bout d’une ½ journée, mais dans votre planning il ne sera disponible qu’au bout de 2.5 jours (le total des 4+16h) Préférez donc faire 2 tâches
      • Sur les projets risqués, ne pas prendre de contingence.
  • Le planning
    • Quelques exemples
    • de planning
  • Le planning
    • Quelques exemples
    • de planning
  • Le planning
    • Quelques exemples
    • de planning
  • Le planning
    • Quelques exemples
    • de planning
  • Le planning avec MS-PROJECT
    • Faite le planning projet de votre Reste A Faire
  • Prochaine (et dernière) session
    • PLANIFIER LE PROJET
    • affecter des ressources
    • le chemin critique
    • présenter son planning
    • DEMARRER & CLOTURER UN PROJET
    • kick off meeting
    • post mortem
    • ORGANISER LE PROJET
    • Nomenclature des fichiers
    • Organisation des répertoires
    • GLOSSAIRE
    • Merci !
    • [email_address]