UNIVERSITÉ LAVAL Conception et implantation d’applications objet (IFT-22766) Concepts de base en gestion de projet Automne 2004 Renaud Champagne Renaud Champagne

1 Objectifs de cette session Donner une vue d’ensemble d’une bonne démarche de gestion de projet informatique Introduire l’auditoire aux concepts de base les plus importants supportant une telle démarche Préparer le groupe à appliquer quelques-uns de ces concepts aux simulations de projets prévues dans le cours

2 Agenda  Un bref tour de table Un cadre de gestion de projet L’organisation d’un projet L’estimation d’un projet Quoi d’autre?

3 Un bref tour de table D’où je viens et ce que j’ai fait À propos de l’auditoire Expérience moyenne Les attentes par rapport à cette session

4 Agenda Un bref tour de table  Un cadre de gestion de projet L’organisation d’un projet L’estimation d’un projet Quoi d’autre?

5 La gestion de projet L’ensemble des actions / décisions requises de l’équipe de gestion du projet pour assurer que les résultats attendus du projet (la solution à un problème d’affaires) soient livrés avec succès par les autres membres de l’équipe de projet. Résultats: Complets Acceptés Livrés à temps Dans les limites budgétaires allouées

6 La vue d’ensemble

7 Organiser le projet

8 Confirmer la démarche du projet Couvre la démarche de développement et la démarche de gestion de projet Des contraintes de départ sont normalement imposées Méthodes et standards de l’organisation Sémantique Outils Ce processus a pour but de: Évaluer les forces et les faiblesses des démarches anticipées Identifier les ajustements / correctifs souhaitables Appliquer ces ajustements / correctifs

9 Évaluer les besoins en environnements Activité souvent initiée trop tard Les correctifs à appliquer à ce niveau peuvent être longs et coûteux Recommandation: initier un projet parallèle On parle ici d’outillage, d’équipements et de logiciels Alignement à faire avec les démarches du projet Couvre les principaux environnements: De développement De gestion De gestion de configuration

10 Planifier le projet

11 Créer les plans de référence Normalement fait l’objet d’une approbation formelle Un plan de référence est un plan “approuvé” Implique habituellement des changements significatifs Changements dans les enveloppes budgétaires Changements dans le calendrier du projet Changement dans la stratégie de déploiement (structure / contenu des livraisons) Des changements qui ne sont pas faits au niveau des “feuilles de temps” Sont peu fréquents (1 ou 2 fois par année …)

12 Suivre / ajuster les plans Processus de gestion des plans individuels Saisie des “feuilles de temps” Possibilité de revoir les prévisions aux niveau des activités Habituellement fait sur un cycle hebdomadaire Implication du Bureau de Soutien à la Gestion Point d’entrée de toutes les données de contrôle de bas du projet Ne modifie pas les plans « approuvés » (dits de référence)

13 Suivre le déroulement du projet

14 Les niveaux de suivi Plusieurs niveaux de suivi Individuel Chef d’équipe Chef de projet Comité de direction La majorité des processus de suivi s’appliquent à chacun des niveaux

15 Suivre la progression des travaux Le processus de contrôle de base le plus important Permet d’aller chercher une lecture sur les points suivants État d’avancement des travaux La progression depuis la dernière rencontre de suivi Les impacts sur la planification Les problèmes rencontrés par l’équipe Aussi une occasion d’informer et de donner des directives Au niveau individuel, ce processus est l’occasion de réévaluer la charge de travail pour compléter les activités en cours Permet de dégager les impacts sur les plans Cette notion est une des composantes majeure de tout le système de métrique servant à mesurer l’état de santé d’un projet

16 Gérer les environnements Contrôle du contenu des différents environnements supportant le projet Migration de composantes entre environnements Contrôle de registres importants supportant l’ensemble du projet Demandes de changements Points en suspens Défauts et incidents Risques

17 Communiquer l’état du projet Production des différents rapports donnant une synthèse de l’état des travaux Avancement et progression depuis le dernier rapport Problèmes, demandes de changements, points en suspens, etc. Vise principalement les niveaux suivants Rapport du chef d’équipe au chef de projet Rapport du chef de projet au comité de direction Les documents produits peuvent être utilisés dans les rencontres de “Suivi de la progression des travaux”

18 Agenda Un bref tour de table Un cadre de gestion de projet  L’organisation d’un projet L’estimation d’un projet Quoi d’autre?

19 Les problèmes d’organisation les plus courants Sous-estimation des efforts à mettre au niveau des environnements et des processus Concernant les individus (la suite de notre discussion) Positionnement des utilisateurs / clients L’équipe d’architecture Le concept de comité de direction de projet Des rôles qui ne sont pas clairs De mauvaises décisions d’assignations dans les rôles clés Des structures inutilement complexes

20 Les trois perspectives Chef de projet Architecte de solution Usagers / clients BesoinsRessources Solution Qualité

21 Le comité de direction du projet Membres: Usager responsable supportant le projet (propriétaire de la solution livrée par le projet) Les responsables des unités d’affaires concernées par le projet Représentants des principaux partenaires Responsabilités: Approuver les orientations du projet Fixer les limites budgétaires et de calendrier Assigner les ressources clés du projet

22 Le pilote usager Rôle: Représente l’usager responsable supportant le projet Représente la communauté des usagers / clients Gère l’équipe d’usagers participant au projet Responsabilités: Exprimer les besoins d’affaires Approuver les livrables perceptibles aux usagers Recevoir la solution développée par l’équipe informatique et l’implanter dans le milieu des utilisateurs Contrôler l’évolution et le bon fonctionnement de la solution livrée

23 Le chef de projet Rôle: Gère l’équipe de construction de la solution d’affaires Agit en tant que partenaire du pilote usager Responsabilité: Livrer la solution d’affaires à l’intérieur des limites budgétaires prescrites, dans les délais et au niveau de qualité attendus

24 Les équipes de construction Membres: Analystes Programmeurs Usagers Responsabilités: Construire les diverses composantes de la solution Vérifier le bon fonctionnement des composantes construites

25 L’architecture – de quoi s’agit-il? La conception de haut niveau de la solution Au niveau conceptuel / fonctionnel plutôt que physique Travail concernant différents aspects de la solution Technologie Organisation Processus d’affaires Structures de données Systèmes En gardant à l’esprit que du travail de « conception » se fait à tous les niveaux

26 Les architectes Rôles qui évoluent dans le cycle de développement de la solution Leadership / gestionnaire Produisent des livrables à certains moments Rôle de support / contrôle de qualité à d’autres moments Profils et domaines d’expertise variés Alignés sur les différents aspects de l’architecture de la solution Les assignations doivent être faites en fonction des forces / faiblesses des ressources disponibles sur le projet

27 Une structure de projet générique Chef d’équipe de construction Partie X du système Chef d’équipe de construction Partie Y du système Équipe de support à la gestion Équipe d’architecture De projet Chef d’équipe intégration et support implantation Chef d’équipe de construction des services communs - Analystes - Programmeurs - Usagers - Analystes - Programmeurs - Usagers - Analystes - Programmeurs - Analystes - Programmeurs - Usagers Comité de direction de projet Chef de projet Pilote usager Groupe d’architecture corporatif Gestion du portefeuille de projets corporatifs

28 Quelques questions concernant la structure de projet Qui va assumer les rôles clés? Comment relier la structure de projet et la structure opérationnelle de l’entreprise? Comment tenir compte des structures informelles existantes? Comment implanter la structure de projet? ?

29 Quand doit-on soulever ces questions? Pour la structure de haut niveau: Au tout début du mandat Pour les équipes de construction: Au début de la phase de développement appropriée Au début des travaux de la livraison concernée Le plus tôt possible dans tous les cas!

30 L’importance de la structure de projet Impact majeur sur la productivité et le climat Doit assurer une couverture complète des tâches à accomplir La structure de projet n’est pas une fin en soi Une fois la structure et les individus en place, il est très difficile de revenir en arrière Il est toujours préférable d’influencer les décisions plutôt que de se faire imposer des choix

31 Quelques règles de base Minimiser le nombre de participants à haut niveau Minimiser le nombre de niveaux Minimiser les liens externes Objectifs: Efficacité Efficience Autonomie Sur une fondation solide

32 Facteurs à considérer lors de la mise en place de la structure de projet Les unités d’affaires touchées par le projet Les standards en place (incluant la sémantique) Les besoins d’assistance d’équipes externes Les forces en présence Le potentiel des ressources versus l’expérience disponible Contraintes particulières

33 Agenda Un bref tour de table Un cadre de gestion de projet L’organisation d’un projet  L’estimation d’un projet Quoi d’autre?

34 Les problèmes typiques en estimation Estimation « organisée » pour respecter les limites de budget ou de calendrier Pas d’estimation de la « taille » de la solution à construire Confusion entre le concept de « coût » et le concept « d’unité monétaire » Estimation appuyée sur des hypothèses non documentées Trop d’estimations faites au « pifomètre » Mauvaise calibration de modèle d’estimation

35 Estimation de quoi exactement? Ressources Humaines (effort et coût) Matérielles Logicielles etc. La “taille” de la solution “prévue” Dates / calendrier Risques Bénéfices

36 Ressources humaines: lesquelles? Personnel des équipes de construction Analystes Programmeurs Personnel des équipes de soutien Gestionnaires Architectes Personnel de soutien technique Personnel de soutien administratif Personnel de l’équipe “usagers”

37 Autres types d’estimation ayant des incidences sur les coûts Acquisition d’équipements / logiciels Coûts d’utilisation d’équipements / logiciels Espace plancher Fournitures de bureau Dépenses de déplacement Frais financiers

38 Estimation des ressources humaines: quelques caractéristiques Estimation de la charge de travail (les efforts en j-p ou h-p) Estimation des coûts (unité monétaire) Estimation faite par spécialité Une zone grise: les participants externes Le personnel “usager”: un ratio

39 Estimation de la charge de travail: techniques et outils Approche appuyée sur le volume de lignes de code Approche faisant appel au concept de “points de fonction” Modèle bien connu : COCOMO La majorité des outils d’estimation souffre de la même faiblesse: ils assument que vous connaissez la taille de la solution à construire

40 L’estimation: au coeur du processus de planification Allocation des ressources Gestion des plans Estimation Définition du processus de livraison

41 Une approche pour l’estimation des coûts en ressources humaines L’utilisation de “barèmes d’estimation” Approche mixte: empirique et statistique Utilisable pour évaluer les coûts liés aux efforts des équipes de construction Tire profit du concept de “bien livrable” Prend en compte le découpage de la solution en “multiples composantes” Évalue d’abord la “taille” sur une base de composante Dérive la charge de travail par composante en fonction de la taille anticipée Fournit une ventilation de la charge totale de travail Évite de confondre effort et durée

42 Le concept de “barèmes d’estimation” Grille d’estimation de la taille Liste de critères pour distinguer différents niveaux de taille Valeurs pour établir le niveau de taille pour chaque critère Grille d’estimation des efforts Alignée avec la grille d’estimation de la taille Fournit une estimation des efforts de développement (charge de travail) Ventilation des efforts par “groupe de livrables” et “catégorie de ressources humaines”

43 Sélection / construction de “barèmes d’estimation” Doit être ajusté à la démarche de développement utilisée dans le projet Certains concepts dans les méthodes les plus récentes représentent un défi Quelques décisions de base importantes Le choix de “l’unité de base” sur laquelle sera appliquée le barème (la notion de “composante”) Décision sur la portée et le découpage de estimations d’efforts Le calibrage est une opération essentielle et délicate La grille d’estimation de taille est normalement plus stable que la grille d’estimation des efforts Exemples de facteurs d’ajustements: expérience / technologie …

44 Des exemples “d’unité de base” possible pour des barèmes d’estimation Barèmes globaux (estimations de haut niveau) Phases du processus de développement Points de fonction Barèmes s’appuyant sur les résultats de la modélisation des traitements Composante fonctionnelle (Cas d’utilisation, transaction d’affaire, etc.) Composante d’essai Programme Barèmes s’appuyant sur les résultats de la modélisation des données Base de données Domaine de données Un essai: le parallèle avec la construction de résidences

45 Barème appuyé sur une composante fonctionnelle : un bon choix! Pourquoi? Un point de référence stable / solide – même face à l’évolution technologique Possibilité d’établir des rapports entre les étapes du processus de développement Composante significative dans le processus de développement (particulièrement pour l’usager) Les avantages Permet de dégager des estimations relativement fiables tôt dans le processus de développement Bonne couverture du processus de développement Facilite l’estimation de la charge de travail par type de ressources

46 Estimation des efforts de soutien Un ratio (%) de la charge de travail totale du projet Une provision pour des demandes de changement Soutien divers (architecture, technique, administratif) La gestion de projet Autres efforts à prévoir: mise en place des environnements, formation, … La participation des usagers Facteurs ayant tendance à augmenter ces efforts de soutien La grosseur de l’équipe de projet Un environnement de développement incomplet Expérience limitée sur la plate forme technologique utilisée Expérience de projet limitée de l’équipe Faible connaissance du domaine d’affaires

47 Agenda Un bref tour de table Un cadre de gestion de projet L’organisation d’un projet L’estimation d’un projet  Quoi d’autre?

48 Quelques autres concepts importants La gestion de configuration La notion de structure des activités (WBS) Système de métriques La gestion des risques

49 La suite du cours Session sur la gestion des risques Leurs projets en simulation …quels concepts peuvent-ils utiliser … Les rôles et responsabilités Quelques aspects de la démarche d’estimation