Informatique de Gestion 2009-2010
Modèle de Plan de Gestion de Projet
(version 1.00 – 14.09.2009)
Les textes en italique sont des explications et/ou des instructions qui devront être supprimées du document. Les textes en caractères droits, notamment les titres, doivent rester tels quels dans le document. Il est interdit d’altérer la structure du document, y compris la numérotation des sections. Toutes les informations décrites dans le présent modèle de Plan de Gestion de Projet (PGP) doivent être explicitées dans le PGP final produit par le groupe. Il faut se rappeler que le PGP est un document de gestion de projet. Il traite avant tout du projet et très peu du site Web à réaliser.
1. Introduction
1.1. Le Plan de Gestion de Projet
Le Plan de Gestion de Projet (PGP) est un document qui vise à rassurer le client quant à la qualité du travail qui sera effectué par l'équipe de projet en précisant comment le projet sera organisé, réalisé, suivi et évalué.
1.2. Le contexte du projet
Cette section est essentielle. L’ensemble de la section doit constituer une présentation du projet, accessible à toute personne intéressée, sans qu’une connaissance préalable du domaine ou qu’une compétence informatique particulière soit nécessaire pour se faire une idée globale des objectifs du projet, des parties en présence et des principaux résultats attendus. Il s’agit de produire un texte général le plus clair possible qui aborde les points suivants, pas forcément dans l’ordre indiqué ni de manière structurée, et seulement dans la mesure où ils sont pertinents. Á la fin de cette section, le lecteur doit avoir compris : Qui est le client et quel est son domaine d’activité (on identifiera le maître de l'ouvrage – le «sponsor» – du projet : ce doit être un responsable habilité à prendre toutes les décisions nécessaires à la bonne réalisation du projet). Quels sont les objectifs «business» du client (à ne pas confondre avec les objectifs du site, même si ces derniers doivent pouvoir être reliés aux premiers). Pour quelle(s) raison(s) le client souhaite un site Web et ce que ce site devra permettre de résoudre, en termes "business" et non techniques. Ce que seront les outputs principaux du projet Quelles sont les motivations du groupe dans le cadre du projet. Ce texte ne doit pas être très long. Les détails apparaîtront dans d'autres sections du PGP ou, ultérieurement, dans d'autres documents. Il est possible que certains éléments (par exemple les objectifs précis du site) n'apparaissent pas clairement au moment où l'on rédige le PGP. Cela doit être indiqué.
IDG 2009-2010, Modèle de PGP
Page 1
2. Les livrables du projet (Quoi?)
Il s'agit de décrire ce que l'équipe de projet va fournir au client et à l'encadrement (des documents, du logiciel, des services, etc.). Les livrables obligatoires sont cités dans les notes de cours mais il peut y en avoir d'autres en fonction du projet.
2.1. Livrables «business»
Ce sont les livrables qui contribuent à satisfaire les besoins du client. Exemples: le rapport d'analyse, le logiciel constituant le site, la mise en ligne du site, une séance de formation destinée au client.
2.2. Livrables de gestion
Ce sont les livrables destinés à aider la gestion et le contrôle du projet. Exemples: le PGP, les procès-verbaux de réunion, les rapports d’avancement.
3. Organisation et responsabilités (Qui?)
La liste de toutes les parties impliquées par le projet (équipe de projet, client, fournisseurs, encadrement, etc.), y compris la description du rôle qu’elles jouent (organisations interne – de l’équipe – et externe – vers le client et le professeur et les assistants) et des responsabilités qu’elles assument. Cette section ne comprend pas les coordonnées des personnes qui sont présentées en annexe.
3.1. L'équipe de projet
Tenir compte du fait qu'une personne peut avoir plusieurs rôles et qu'un rôle peut être assumé par plusieurs personnes.
3.2. Le client
Ce paragraphe comprend aussi la description des obligations du client en termes de ressources (ce qu’il va mettre à la disposition du projet – notamment le temps qu’il va y consacrer – et la manière dont ces ressources seront gérées) et d’activités. Attention: les obligations du client résultent d’un accord de celui-ci. Il faut être suffisamment précis pour que cette description soit utile. L’objectif essentiel est que le client soit au courant de ce qu’on attend de lui.
3.3. L'encadrement
Il s'agit du professeur et des assistants. Comme dans le cas du client, le rôle et les responsabilités du professeur et des assistants doivent faire l'objet d'un accord de ceux-ci. Cet accord peut être implicite quand la description du rôle et des responsabilités correspond à ce qui a été présenté au cours. Il faut une discussion préalable avec le professeur et/ou l'assistant dans tous les cas où le groupe souhaite quelque chose de particulier. On notera à ce sujet que l’assistant supervise le travail, généralement sur demande de l’équipe: il porte un regard personnel et tâche d’éviter de trop grandes divergences entre le travail réalisé et les attentes essentielles de l’équipe enseignante (professeur et assistants). L’assistant ne réalise pas le travail dont la valeur ajoutée, en termes d’adéquation de la méthodologie mise en œuvre et du produit réalisé aux besoins du client, est exclusivement fournie par le groupe.
IDG 2009-2010, Modèle de PGP
Page 2
3.4. Les fournisseurs
Il s'agit de tiers qui fournissent des biens ou des services au projet, soit directement à l'équipe, soit par l'intermédiaire du client. Exemple : un fournisseur d'accès Internet chez qui le site sera logé. Il ne faut citer que les fournisseurs importants. S'il n'y en a pas, on conserve la section avec l'indication «aucun» ou «non applicable».
4. Réalisation et gestion du projet (Comment?)
Cette section décrit comment le projet va être géré et réalisé.
4.1. Division en unités de travail
Division du travail en grands blocs, selon les jalons («milestones») les plus importants. On notera qu’une unité de travail (UT) est une tâche (ou un ensemble de tâches) à accomplir, pas une personne ! La découpe en UT est au choix du groupe. Exemples d’UT : Gestion de projet, Analyse, Design, Programmation et test, Mise en place du site. Voir le cours pour un exemple de découpe en UT. La découpe doit être faite de sorte que chaque tâche à accomplir soit décrite dans une UT. Les différentes UT sont identifiées par un nom et par un identificateur (par exemple UT1 – Gestion de projet). Il faut créer une sous-section numérotée 4.1.x (où x est le numéro de l'UT) pour chaque UT. 4.1.1. UT1 – Nom de l’unité de travail Description de l’unité et de l’objectif à atteindre En plus de la description générale de l'unité de travail et de l'objectif de cette unité de travail, la description comporte: Les conditions pour commencer le travail de cette unité (ressources, approbation d’un résultat antérieur, inputs, etc.) La description des outputs (identification, description de la nature, du support, du format, etc.). Il est faut veiller à la cohérence avec la section qui décrit les livrables du projet: tout livrable du projet doit être un output d'une (ou de plusieurs) unité de travail. Les conditions pour clôturer l’unité de travail Description des tâches et activités de l’unité de travail : Il s’agit de découper le travail à réaliser pour atteindre les objectifs de l’unité de travail en tâches et, si nécessaire, de découper les tâches en activités. Voir exemple dans les notes de cours. 4.1.2. U2 – Nom de l’unité de travail 4.1.3. U3 – Nom de l’unité de travail 4.1.4. etc.
IDG 2009-2010, Modèle de PGP
Page 3
4.2. Plan initial
Planning initial (lié aux unités de travail de la section précédente) à un niveau assez général. Pour chaque unité de travail, on précisera: une évaluation de la charge de travail les dates prévues de début et de fin Dans ce plan, il est important de mettre en évidence les dépendances entre les différentes unités de travail. Ce plan présente les intentions du groupe telles qu’elles existent au début du projet. C’est le planning que le groupe s’engage à essayer de tenir. Bien entendu, si nécessaire, il sera possible de le modifier ultérieurement.
4.3. Gestion de l'information relative à l'avancement des travaux
Description de : la manière dont le chef de projet récolte les informations sur l’avancement des travaux auprès des membres de l’équipe; la manière dont il transmet ces informations au client, à l’équipe et au professeur et aux assistants; le contenu et la fréquence des rapports internes et/ou externes; l’organisation et la fréquence des réunions internes et externes d’avancement. Remarques : Il faut prévoir un rapport d’avancement mensuel destiné au client, au professeur et aux assistants ; ce rapport doit couvrir un mois-calendrier et parvenir aux destinataires au plus tard le 7ème jour du mois suivant. Toutes les réunions formelles doivent faire l’objet d’un compte-rendu distribué à tous les participants (avec copie au professeur et aux assistants) endéans la semaine qui suit la réunion. Il faut prévoir des réunions internes au projet (hebdomadaires ?). Il faut prévoir des réunions régulières avec le client pour le tenir au courant de l’avancement du projet (mensuelles ?); ces réunions sont différentes des réunions de travail pendant lesquelles on discute du fond mais elles peuvent avoir lieu en même temps si les participants sont les mêmes. Il faut prévoir des réunions régulières avec le professeur et les assistants: voir notes de cours.
4.4. Gestion des problèmes et changements
Très court. Petite sous-section. Description d’une procédure de gestion des problèmes : Qui peut soulever un problème ? Quand et comment est-il pris en considération ? Qui est responsable de son suivi ? Dans quelles conditions est-ce que l’on clôture un problème ? Pendant la durée d’un projet, des changements peuvent être nécessaires (par exemple si les objectifs «business» sont modifiés ou précisés). La gestion des changements vise à éviter les changements non contrôlés (ceux-ci sont pénalisés lors de l'évaluation des travaux).
IDG 2009-2010, Modèle de PGP
Page 4
Description d’une procédure de gestion des changements. Circulation de l’information (y compris vers le professeur et les assistants !), les décisions à prendre, les responsabilités (l’accord des enseignants est requis pour un changement important), la manière d’assurer la visibilité et le suivi des changements.
4.5. Contrôle de la qualité
Très court. Petite sous-section. Il faut mettre en place quelques procédures simples de contrôle de la qualité. Par exemple, pour les documents qui sont produits par le projet (et en particulier pour ceux qui «sortent» du projet), on peut prévoir que quelqu’un d’autre que l’auteur du document le relise avant publication. Les activités de test du site doivent évidemment être prévues mais elles ne sont pas décrites ici : elles font parties des activités principales et sont décrites dans une des unités de travail.
4.6. Standards, règles et conventions
Identification et description des standards, règles et conventions utilisés pour tous les travaux sur le projet, tels que : standards de présentation des divers documents modèles de mise et page et de structure règles d’identification des documents Par exemple, ce qui suit est obligatoire : E-mail : le sujet doit commencer par l’identification du groupe (Gxx); le mail doit être signé et la signature doit comporter le nom, l’adresse e-mail et (si possible) un ou plusieurs numéros de téléphone et de fax ; le mail doit comporter une liste des annexes: titre, version et date du document, nom du fichier. Tout document doit comporter: l’identification du groupe et le nom du projet un titre, un numéro de version, une date la pagination, y compris le nombre total de pages
4.7. Techniques et outils, matériel et logiciel
Description des techniques et outils utilisés pendant le processus de développement. Très court. Faites éventuellement référence à des parties précises du cours. Liste du logiciel et du matériel utilisé sur le projet pour les divers travaux. Quel est le matériel utilisé pour faire quoi ? Quels sont les logiciels utilisés pour faire quoi ? Il est impératif de se mettre d’accord entre toutes les parties concernées et de se tenir aux accords pris. En ce qui concerne les rapports avec le professeur et les assistants, sauf accord préalable de dérogation, ce qui suit est obligatoire: Documents: compatibles Microsoft Word 2003, Excel 2003, PowerPoint 2003 Annexes des mails : compression au format Zip si volumineux (supérieur à 100K)
4.8. Sécurité
Très court. Petite sous-section. Description des mesures de sécurité telles que :
IDG 2009-2010, Modèle de PGP
Page 5
procédures de sauvegarde (back up) et de contrôle des virus règles de confidentialité responsabilités en ce qui concerne le matériel et le logiciel emprunté mesures de contrôle d’accès aux ordinateurs, aux locaux, etc. Cette section décrit les procédures relatives au projet et non les procédures relatives au site. Il s’agit de décrire ce que l’on a décidé de faire (ou ce qui est imposé) en matière de sécurité. C’est un thème à aborder éventuellement avec le client pour vérifier s’il a des exigences particulières. En ce qui concerne l’organisation interne du projet, il faut examiner en particulier les aspects «back up» et stockage.
5. Annexes
5.1. Terminologie
5.1.1. Abréviations Liste de toutes les abréviations utilisées dans le PGP 5.1.2. Définitions Définition de tous les termes (mais rien que ceux-ci) dont la signification peut être ambiguë ou mal comprise.
5.2. Documentation
Liste de tous les documents (comme une bibliographie) qui sont des inputs pour le projet au moment de sa mise en place. On donnera, si possible, le nom du document, son identification, sa version, sa date de publication.
5.3. Contacts
5.3.1. Équipe de projet Pour chaque membre du groupe, fournir les informations suivantes: Informations obligatoires Prénom et nom Année d'étude, orientation, statut particulier (tel que, par exemple, élève libre, étudiant Erasmus, etc.), numéro de carte d'étudiant Adresse e-mail Informations optionnelles Rôle(s) Contacts supplémentaires : adresse(s), téléphone(s), fax En ce qui concerne les rôles, il faut au moins identifier: le chef de projet et le suppléant ("backup") du chef de projet la personne responsable des contacts avec les enseignants et son suppléant
IDG 2009-2010, Modèle de PGP
Page 6
5.3.2. Client Identification précise du client et des personnes avec qui le groupe travaille pour le projet. Description des moyens de contact (adresse, téléphone, e-mail, etc.). 5.3.3. Encadrement Serge Boute 53 avenue du Général de Gaulle, 7000 Mons Tél. privé : +32 65 59 55 50 Tél. bureau : +32 2 708 23 75 GSM : +32 497 05 30 70 Fax : +32 65 31 52 28 E-mail : sboute@ulb.ac.be Jean-François Depoitre GSM : +32 496 57 43 08 E-mail : idg@depoitre.com Nicolas Gothelf Bureau U.L.B. : H4-253 Tél. bureau : +32 2 650 38 55 Fax: +32 2 650 44 75 E-mail : ngothelf@ulb.ac.be Frédéric Trauscht GSM : 0497 05 35 66 E-mail : idg@trauscht.com
IDG 2009-2010, Modèle de PGP
Page 7